CHAPTER VAX PAGESWAPPER - April 1988 - Volume 9 Number 9 Editor's Workfile . . . . . . . . . . . . . . . VAX-3 Fastest SIR Response in History . . . . . . . . VAX-3 Get System Performance Information Service . . . VAX-5 The SIR Lobby . . . . . . . . . . . . . . . . VAX-26 LUG News . . . . . . . . . . . . . . . . . . . VAX-37 A New VMS System Management Architecture . . . VAX-38 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-59 Forms at the End System Improvement Request Submission Form . . VAX-105 VAX Systems SIG Spring 1988 SIR Ballot . . . . VAX-107 PAGESWAPPER - April 1988 - Volume 9 Number 9 To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. Articles for publication in the Pageswapper can be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters and the number of text lines per page should not exceed 48 (these limits are particularly important for sample commands, etc. where simple text justification will not produce a meaningful result). Please do not submit program source, as that is better distributed on the VAX SIG tape. Please do not submit "slides" from DECUS Symposia presentations (or other meetings) as they are generally a very incomplete treatment for those readers of the Pageswapper who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on such slides to get the content across to a wider audience than is able to attend. Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - April 1988 - Volume 9 Number 9 Editor's Workfile Editor's Workfile SIR Voting Time April 8 is the deadline for voting on the Spring 1988 System Improvement Request ballot. Even if you are reading this on April 1, the time is short. Dial-up contributors to the Pageswapper have been participating in a debate as to the relative merits of the various SIR's, and in this issue Jonathan Pinkley summarizes that discussion for the rest of our readers who have not had a chance to get their arm twisted for this ballot. If there is still time for you to vote, the form is in this issue, but you will have to go to the February issue for the text of SIR's (SIR voting can also be done on-line by those with Pageswapper submission accounts). Fastest SIR Response in History (before the vote) Digital Equipment Corporation 110 Spit Brook Road Nashua, NH 03062-2698 12 February 1988 Larry Kilgallen, Pageswapper Editor Box 81, MIT Station Cambridge, MA 02139-0901 Dear Larry, VAX-3 PAGESWAPPER - April 1988 - Volume 9 Number 9 Fastest SIR Response in History While reviewing the Spring 1988 SIRs published in the February edition of PAGESWAPPER, I discovered two that may not get voted into the top ten, but for which some response seems appropriate. The first is S88-24 -- Abstract: MOUNT/FOREIGN and uninitialized tapes. I believe that symptoms described in the SIR result from known bugs in the HSC microcode. I also believe that these bugs have been or are being corrected, and that new HSC microcode releases will eliminate the observed behavior. I attempted the described operations on both a non-HSC and an HSC tape drive here and found the MOUNT/FOREIGN command to work properly in both cases. (Of course, we are running the "latest and greatest" of everything here, which also means that I am not able to reproduce the environment in which the problem is being experienced.) It should also be noted that SIR-24 represents a bug report, and probably should be handled by means other than SIRs. The second SIR is S88-15 -- Abstract: DCL status enhancements. To the best of my knowledge, utilities such as DIFFERENCES already return useful status information in the $STATUS DCL variable. In the case of DIFFERENCES identical files produce a $STATUS that equals %x006C8009, and different files produce a $STATUS that equals %x006C8013. Personally, I would not check the exact status values, but rather note that a SUCCESS status is returned if the files are identical and an INFORMATIONAL status is returned if the files are different. Returning useful information in $STATUS is the expected behavior for all VMS utilities. In this respect, I believe that we are already doing that which SIR S88-15 requests. Of course there may be cases where the normal VMS standards are not being observed. I think customers who observe abnormal behavior, in the form of insufficient 'value" in $STATUS returns, should report those problems as the bugs that they are. Thanks, Ralph O. Weber Consultant Software Engineer VAX/VMS Operating System Development VAX-4 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service Get System Performance Information Service Frank J. Nagy Fermi National Accelerator Laboratory P. O. Box 500 Mail Stop 220 Batavia, IL 60510 Disclaimer The information in this document is subject to change without notice and should not be construed as a commitment by the author nor, certainly, by the Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The VMS MONITOR program gathers and displays information on the performance of a VAX/VMS system. MONITOR collects much of its information from the VMS Executive by means of a special Get System Performance Information service. The calling sequence for $GETSPI is described later in this document. $GETSPI is not implemented as part of the VMS Executive, but as an external system service in the manner of user-written system services. As such, the $GETSPI system service is implemented in the SPISHR.EXE shareable image found in SYS$SHARE: on the VMS system disk. Normally, this image is installed as a protected shareable image at system startup. To use this service, your program must link to this shared image with an explicit Linker command as shown: $ link myprogram,...,sys$input:/options... sys$share:spishr/shareable to link MYPROGRAM and other object modules with the SPISHR image. VAX-5 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service The $GETSPI service collects performance information based on an item list similar to the item lists used by the other get-information system services, such as $GETJPI or $GETSYI. The item codes used by $GETSPI are defined as constants for VAX C in a SPIDEF module for the LCLCDEF.TLB text library located in RDCS$LIB: at Fermilab (see the appendix for a listing of these constants). Most of the item codes return a longword value which is either the current level value (such as the current amount of free nonpaged pool) or the current counter value (such as the number of system page faults). Counters are converted to rates by requesting the performance information twice, subtracting the first value from the second and dividing by the time interval between collections. The SPI$_SYSTIME item code returns the current system time in standard VMS format (quadword) and may be included in an item with other performance information items to provide a time stamp marking the time when the items in the list were collected. Other items with units of time are returned in longwords as counts of 10 millisecond clock ticks. Several items (SPI$_DISK, SPI$_PROC and SPI$_SCS) return lists of structured information. Each list begins with a longword count which gives the number of items in the array of records which is the remainder of the list. The SPIDEF module defines struct's for VAX C for these items. The DiskRecord structure is returned by the SPI$_DISK item code for each disk device on the system. The information returned in the DiskRecord is: - Allocation class number. - Short form (four character) device name. - Unit number. - VAXCluster node name. - Volume name. - Count of I/O operations. - Queue length accumulator. The ProcRecord structure is returned by the SPI$_PROC item code for each process in the system. The information returned in the ProcRecord structure is: VAX-6 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service - Internal process identification (PID). - UIC of process owner. - Process' current state. - Process' priority. - Process' name. - Global page count. - Process page count. - Status vector from Process Control Block (PCB). Process is swapped out if PCB$V_RES bit is clear. - Direct I/O count. - Page fault count. - Accumulated CPU time in clock ticks. - Buffered I/O count. - Extended PID. - Event flag wait mask and MWAIT code. The SCSRecord structure is returned by the SPI$_SCS item code for each node in the cluster. The information returned in the SCSRecord structure is: - System node name. - Count of application datagrams sent. - Count of datagrams received. - Count of datagrams discarded. - Count of application messages sent. VAX-7 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service - Count of messages received. - Count of block Send Data's initiated. - KBytes sent via Send Data's. - Count of block Request Data's initiated. - KBytes received via Request Data's. - KBytes mapped for block transfers. - Times connection queued awaiting send credit. - Times connection queued awaiting buffer descriptor. Refer to the appendix or the source of the SPIDEF include module for the exact struct field declarations. The next section of this document is a description of the individual $GETSPI system service and its arguments. VAX-8 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service This service allows a process to request performance information about the system. This undocumented system service is used by the MONITOR utility and is implemented in the SPISHR.EXE shareable image found in SYS$SHARE:. Items are requested using an item descriptor list similar to that used by the other $GETxxx system services. An item descriptor has the format: +-----------------------------+ | Item Code | Buf. Length | +-----------------------------+ | Buffer Address | +-----------------------------+ | Address to return length | +-----------------------------+ Refer to the documentation on the Get System-Wide Information ($GETSYI) system service for more information on the arguments to $GETSPI (except for the item codes and the returned information). status = EXE_$GETSPI( efn, csidadr, nodename, itmlst, iosb, astadr, astprm ) status returns as VMS condition code: = SS$_NORMAL success = SS$_NOMORENODE a wildcard operation was requested, and $GETSPI has returned information about all available VAX nodes in the cluster. This is a success status. = SS$_NOSUCHNODE the specified VAX node does not exist or is not currently a member of the VAXCluster. = SS$_EXASTLM AST quota exceeded = SS$_ACCVIO itmlst can not be read by the calling access mode or the return buffer or return length word can not be written by the calling access mode. VAX-9 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SS$_BADPARAM an invalid item identifier was supplied efn number of the event flag to set when all of the requested data is valid. Passed by value. csidadr cluster system identification (csid) of the VAX node about which $GETSPI is to return performance information. The csid is a longword passed by reference. The initial value of the csid is $-1$ for a $GETSPI wildcard operation for all nodes in a VAXCluster (see $GETSYI documentation for more details). NOTE: UNUSED at the present time. nodename name of the VAX node about which $GETSPI is to return performance information. Passed by descriptor. NOTE: UNUSED at the present time. itmlst list of item descriptors. Passed by reference. The list is ended by a longword of 0. Most of the item codes return a single longword value; the exceptions are noted in the list below: = SPI$_ACCESS Number of file accesses = SPI$_ACCLCK Number of Access locks = SPI$_ALLOC Number of file extends = SPI$_ARRLOCPK Arriving local packets = SPI$_ARRTRAPK Arriving transit packets = SPI$_BIGHOLE Largest block in dynamic memory VAX-10 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_BLKAST Number of blocking ASTs = SPI$_BLKIN Blocking ASTs queued (incoming) = SPI$_BLKLOC Blocking ASTs queued (local) = SPI$_BLKOUT Blocking ASTs queued (outgoing) = SPI$_BUFFUNAVAIL System buffer unavailable = SPI$_BUFIO Count of buffered I/Os = SPI$_CEF Common event flag wait = SPI$_COLPG Collided page wait = SPI$_COM Computable = SPI$_COMO Outswapped and computable = SPI$_CUR Currently executing = SPI$_DEPLCKPK Departing local packets = SPI$_DEQ Number of DEQ's = SPI$_DEQIN Dequeues (incoming) = SPI$_DEQLOC Dequeues (local) = SPI$_DEQOUT Dequeues (outgoing) = SPI$_DGDISCARD SCS application datagrams discarded = SPI$_DGRCVD SCS application datagrams received = SPI$_DGSENT SCS application datagrams sent = SPI$_DIRDATA_HIT Count of Directory data cache hits = SPI$_DIRDATA_HITPCNT Percent of directory data cache hits VAX-11 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_DIRDATA_TRIES Count of Directory data cache attempts = SPI$_DIRDEL Directory deletes = SPI$_DIRFCB_HITPCNT Percent of directory block cache hits = SPI$_DIRFCB_HITS Count of Directory block cache hits = SPI$_DIRFCB_MISS Count of Directory block cache misses = SPI$_DIRFCB_TRIES Count of Directory block cache attempts = SPI$_DIRIN Directory operations (incoming) = SPI$_DIRINS Directory inserts = SPI$_DIRIO Count of direct I/Os = SPI$_DIRLOOK Directory lookups = SPI$_DIROUT Directory operations (outgoing) = SPI$_DISKRESPTIM Disk I/O response time = SPI$_DISKS All disk data. Returns a list which begins with a longword count of of the number of disk drives and then has an array of information records (one for each disk). = SPI$_DLCKFND Number of deadlocks found = SPI$_DLCKMSGS Deadlock detection messages (in out) = SPI$_DLCKSRCH Number of deadlock searches = SPI$_DYNINUSE Dynamic memory space in use = SPI$_DZROFLTS Demand zero faults VAX-12 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_ENQCVT Number of ENQ's (conversions) = SPI$_ENQCVTIN Lock conversion requests (incoming) = SPI$_ENQCVTLOC Lock conversion requests (local) = SPI$_ENQCVTOUT Lock conversion requests (outgoing) = SPI$_ENQNEW Number of ENQ's (new) = SPI$_ENQNEWIN New lock requests (incoming) = SPI$_ENQNEWLOC New lock requests (local) = SPI$_ENQNEWOUT New lock requests (outgoing) = SPI$_ENQNOTQD Number of ENQ's no queued = SPI$_ENQWAIT Number of ENQ's forced to wait = SPI$_EXTHIT Count of Extent cache hits = SPI$_EXTHITPCNT Percent of extent cache hits = SPI$_EXTMISS Count of Extent cache misses = SPI$_EXT_TRIES Count of Extent cache attempts = SPI$_FAULTS Page fault count = SPI$_FCPCACHE Number of FCP cache hits = SPI$_FCPCALLS Total FCP calls = SPI$_FCPCPU Number of CPU ticks used by FCP = SPI$_FCPCREATE Number of file creations = SPI$_FCPERASE Number of erase calls = SPI$_FCPFAULT Number of FCP page faults = SPI$_FCPHIT Number of window hits VAX-13 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_FCPREAD Number of disk reads by FCP = SPI$_FCPSPLIT Number of split transfers = SPI$_FCPTURN Number of window turns = SPI$_FCPWRITE Number of disk writes by FCP = SPI$_FIDHIT Count of File Id cache hits = SPI$_FIDHITPCNT Percent of file id cache hits = SPI$_FIDMISS Count of File Id cache misses = SPI$_FID_TRIES Count of File Id cache attempts = SPI$_FILHDR_HIT Count of File Header cache hits = SPI$_FILHDR_HITPCNT Percent of file header cache hits = SPI$_FILHDR_TRIES Count of File Header cache attempts = SPI$_FPG Fragmented paging wait = SPI$_FREFLTS Faults from free page list = SPI$_FRLIST Size of free page list = SPI$_GVALFLTS Global valid page faults = SPI$_HIB Hibernating = SPI$_HIBO Outswapped and hibernating = SPI$_HOLECNT Number of blocks in dynamic memory = SPI$_HOLESUM Total available dynamic memory = SPI$_INITDEFER Transmit initially deferred = SPI$_INTERNALBUFERR Receive internal buffer error VAX-14 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_IOAQUELEN Accurate disk I/O queue length = SPI$_IOQUELEN Disk I/O queue length = SPI$_IRPCNT Number of IRP packets available = SPI$_IRPINUSE Number of IRP packets in use = SPI$_ISWPCNT Total inswaps = SPI$_JDEXCNT Journal device extend count = SPI$_JDFQLEN Journal device force I/O queue length = SPI$_JDNQLEN Journal device normal I/O queue length = SPI$_JDWQLEN Journal device wait IRP queue length = SPI$_JNLBUFIO Journal buffered I/Os = SPI$_JNLBUFWR Journal buffer writes = SPI$_JNLCHNLS Journal channels assigned = SPI$_JNLDIRIO Journal direct I/Os = SPI$_JNLFORFL Force writes -- flushed = SPI$_JNLFORNL Force writes -- NULL operation = SPI$_JNLIOCNT Journal I/O operation count (for disks ) = SPI$_JNLJRNLS Active journals = SPI$_JNLWRTAI AI journal write operations = SPI$_JNLWRTAT AT journal write operations = SPI$_JNLWRTBI BI journal write operations = SPI$_JNLWRTFM Force modifier writes VAX-15 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_JNLWRTRU RU journal write operations = SPI$_JNLWRTSS Journal write ops to sec stg = SPI$_KBYTES KBytes/second = SPI$_KBYTMAPD SCS Kbytes mapped for block transfer = SPI$_KBYTREQD SCS KBytes received via request datas = SPI$_KBYTSENT SCS KBytes send via send datas = SPI$_LEF Local event flag wait = SPI$_LEFO Outswapped local event flag wait = SPI$_LOCBUFERR Receive local buffer error = SPI$_LOGNAM Logical name translations = SPI$_LRPCNT Number of LRP packets available = SPI$_LRPINUSE Number of LRP packets in use = SPI$_MBREADS Total mailbox reads = SPI$_MBWRITES Total mailbox writes = SPI$_MFYFLTS Faults from modified page list = SPI$_MKBYTES Multicast KBytes/second = SPI$_MODLIST SIze of modified page list = SPI$_MPACKETS Multicast packets/second = SPI$_MPACKETSIZE Multicast packet size (bytes) = SPI$_MSGRCVD SCS application messages received = SPI$_MSGSENT SCS application messages sent VAX-16 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_MULTICOLL Transmit multi collisions detected = SPI$_MWAIT Misc. wait = SPI$_NUMLOCKS Total locks = SPI$_NUMRES Total resources = SPI$_OPCNT Disk I/O operation count = SPI$_OPENS Number of file opens = SPI$_OTHSTAT OBSOLETE item, returns 0 = SPI$_PACKETS Ethernet packets/second = SPI$_PACKETSIZE Packets size (bytes) = SPI$_PCOMPAT Time in compatability mode in ticks = SPI$_PEXEC Time in executive mode in ticks = SPI$_PFW Page fault wait = SPI$_PIDLE Idle time in ticks = SPI$_PINTERRUPT Time on interrupt stack in ticks = SPI$_PKERNEL Time in kernel mode in ticks = SPI$_PREADIO Physical page read I/Os = SPI$_PREADS Page reads = SPI$_PROC Process information. Returns a list which begins with a longword count of of the number of processes on the system and then has an array of information records (one for each process). = SPI$_PROCS Process count for SYSTEM class = SPI$_PSUPER Time in supervisor mode in ticks VAX-17 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_PUSER Time in user mode in ticks = SPI$_PWRITES Page writes = SPI$_PWRITIO Physical page write I/Os = SPI$_QBDT_CNT SCS times connection queued for buffer descriptor = SPI$_QCR_CNT SCS times connection queued for send credit = SPI$_QUOHIT Count of Quota cache hits = SPI$_QUOHITPCNT Percent of quota cache hits = SPI$_QUOMISS Count of Quota cache misses = SPI$_QUO_TRIES Count of Quota cache attempts = SPI$_RCVBUFFL Receiver buffer failures = SPI$_REQDATS SCS block request datas initiated = SPI$_RUFABORT Count of RU abort operations = SPI$_RUFACTIV Active recovery units = SPI$_RUFCHNLS RU journal channels = SPI$_RUFJNLS Active RU journals = SPI$_RUFMARK Count of Mark IDs written = SPI$_RUFMRKRB Count of Mark ID rollbacks = SPI$_RUFREADS RU journal reads = SPI$_RUFWRTS RU journal writes = SPI$_RUFXTNDS RU journal extends = SPI$_SCOMPAT Time in compatability mode in ticks VAX-18 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_SCS All SCS information. Returns a list which begins with a longword count of of the number of systems in the cluster and then has an array of information records (one for each system). = SPI$_SEXEC Time in executive mode in ticks = SPI$_SIDLE Idle time in ticks = SPI$_SINGLECOLL Transmit single collision detected = SPI$_SINTERRUPT Time on interrupt stack in ticks = SPI$_SKERNEL Time in kernel mode in ticks = SPI$_SMALLCNT Number of blocks $<$ 32 bytes in size = SPI$_SMALLHOLE Smallest block in dynamic memory = SPI$_SNDATS SCS block send datas initiated = SPI$_SRPCNT Number of SRP packets available = SPI$_SRPINUSE Number of SRP packets in use = SPI$_SSUPER Time in supervisor mode in ticks = SPI$_STORAGMAP_HIT Count of Storage bitmap cache hits = SPI$_STORAGMAP_HITPCNT Percent of storage bitmap cache hits = SPI$_STORAGMAP_TRIES Count of Storage bitmap cache attempts = SPI$_SUSER Time in user mode in ticks = SPI$_SUSP Suspended = SPI$_SUSPO Outswapped and suspended VAX-19 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service = SPI$_SYNCHLCK Directory and file synch locks = SPI$_SYNCHWAIT Number of times XQP waited for a directory or file synch lock = SPI$_SYSFAULTS System page faults = SPI$_SYSTIME Current system time returned in a quadword in standard VMS time format = SPI$_TRCNGLOS Transit congestion loss = SPI$_VOLLCK Volume synchronization locks = SPI$_VOLWAIT Number of times XQP waited for volume lock = SPI$_WRTINPROG Faults from write-in-progress = SPI$_XQPCACHEWAIT Number of times XQP had to wait for free space in a cache iosb quadword I/O status block to receive final status. Passed by reference. astadr AST routine to be called when all of the requested data has been supplied. Passed by reference. astprm longword AST routine parameter. Passed by value. VAX-20 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service Declarations of information return struct's used by the SPI$_DISK, SPI$_PROC and SPI$_SCS items. struct DiskRecord { unsigned char allocclass; /* Allocation class */ char devname[4]; /* Device name */ unsigned short unitnum; /* Unit number */ char nodename[8]; /* Node name */ char volname[12]; /* Volume name */ unsigned long optcnt; /* Operation count */ unsigned long qcount; /* Queue length accumulator */ }; struct ProcRecord { unsigned long ipid; /* Internal PID */ unsigned long uic; /* UIC */ unsigned short state; /* State value */ unsigned char pri; /* Priority (negative value) */ struct { unsigned char count; /* Text length count */ char text[15]; } lname; /* Process name (counted string) unsigned short gpgcnt; /* Global page count */ unsigned short ppgcnt; /* Process page count */ unsigned long sts; /* PCB Status Vector */ unsigned long diocnt; /* Direct I/O count */ unsigned long pageflts; /* Page fault count */ unsigned long cputim; /* Accumulated CPU time (in ticks unsigned long biocnt; /* Buffered I/O count */ unsigned long epid; /* Extended PID */ unsigned long efwm; /* Event flag wait mask (for MWAI }; VAX-21 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service struct SCSRecord { char nodename[8]; /* System node name */ unsigned long dgsent; /* Application datagrams sent */ unsigned long dgrcvd; /* Application datagrams received unsigned long dgdiscard; /* Application datagrams discarde unsigned long msgsent; /* Application messages sent */ unsigned long msgrcvd; /* Application messages received unsigned long snddats; /* Block send datas initiated */ unsigned long kbytsent; /* KBytes send via send datas */ unsigned long reqdats; /* Block request datas initiated unsigned long kbytreqd; /* KBytes received via request da unsigned long kbytmapd; /* KBytes mapped for block transf unsigned long qcr_cnt; /* Times queued for send credit * unsigned long qbdt_cnt; /* Times queued for buffer descri }; Definitions of the item list codes: /* Primary CPU: */ #define SPI$_PINTERRUPT 0X001 #define SPI$_PKERNEL 0X002 #define SPI$_PEXEC 0X003 #define SPI$_PSUPER 0X004 #define SPI$_PUSER 0X005 #define SPI$_PCOMPAT 0X006 #define SPI$_PIDLE 0X007 /* Secondary CPU: */ #define SPI$_SINTERRUPT 0X008 #define SPI$_SKERNEL 0X009 #define SPI$_SEXEC 0X00A #define SPI$_SSUPER 0X00B #define SPI$_SUSER 0X00C #define SPI$_SCOMPAT 0X00D #define SPI$_SIDLE 0X00E #define SPI$_CPUBUSY 0X00F #define SPI$_COLPG 0X010 #define SPI$_MWAIT 0X011 #define SPI$_CEF 0X012 #define SPI$_PFW 0X013 #define SPI$_LEF 0X014 #define SPI$_LEFO 0X015 VAX-22 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service #define SPI$_HIB 0X016 #define SPI$_HIBO 0X017 #define SPI$_SUSP 0X018 #define SPI$_SUSPO 0X019 #define SPI$_FPG 0X01A #define SPI$_COM 0X01B #define SPI$_COMO 0X01C #define SPI$_CUR 0X01D #define SPI$_OTHSTAT 0X01E #define SPI$_PROCS 0X01F #define SPI$_PROC 0X020 #define SPI$_FRLIST 0X021 #define SPI$_MODLIST 0X022 #define SPI$_FAULTS 0X023 #define SPI$_PREADS 0X024 #define SPI$_PWRITES 0X025 #define SPI$_PWRITIO 0X026 #define SPI$_PREADIO 0X027 #define SPI$_GVALFLTS 0X028 #define SPI$_WRTINPROG 0X029 #define SPI$_FREFLTS 0X02A #define SPI$_MFYFLTS 0X02B #define SPI$_DZROFLTS 0X02C #define SPI$_SYSFAULTS 0X02D #define SPI$_LRPCNT 0X02E #define SPI$_LRPINUSE 0X02F #define SPI$_IRPCNT 0X030 #define SPI$_IRPINUSE 0X031 #define SPI$_SRPCNT 0X032 #define SPI$_SRPINUSE 0X033 #define SPI$_HOLECNT 0X034 #define SPI$_BIGHOLE 0X035 #define SPI$_SMALLHOLE 0X036 #define SPI$_HOLESUM 0X037 #define SPI$_DYNINUSE 0X038 #define SPI$_SMALLCNT 0X039 #define SPI$_ISWPCNT 0X03A #define SPI$_DIRIO 0X03B #define SPI$_BUFIO 0X03C #define SPI$_MBREADS 0X03D #define SPI$_MBWRITES 0X03E #define SPI$_LOGNAM 0X03F #define SPI$_ACCESS 0X040 #define SPI$_ALLOC 0X041 #define SPI$_FCPCALLS 0X042 #define SPI$_FCPCREATE 0X043 #define SPI$_FCPREAD 0X044 VAX-23 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service #define SPI$_FCPWRITE 0X045 #define SPI$_FCPCACHE 0X046 #define SPI$_VOLWAIT 0X047 #define SPI$_FCPCPU 0X048 #define SPI$_FCPTURN 0X049 #define SPI$_FCPHIT 0X04A #define SPI$_FCPSPLIT 0X04B #define SPI$_FCPFAULT 0X04C #define SPI$_FCPERASE 0X04D #define SPI$_OPENS 0X04E #define SPI$_ENQNEW 0X04F #define SPI$_ENQCVT 0X050 #define SPI$_DEQ 0X051 #define SPI$_BLKAST 0X052 #define SPI$_ENQWAIT 0X053 #define SPI$_ENQNOTQD 0X054 #define SPI$_DLCKSRCH 0X055 #define SPI$_DLCKFND 0X056 #define SPI$_NUMLOCKS 0X057 #define SPI$_NUMRES 0X058 #define SPI$_ARRLOCPK 0X059 #define SPI$_DEPLCKPK 0X05A #define SPI$_ARRTRAPK 0X05B #define SPI$_TRCNGLOS 0X05C #define SPI$_RCVBUFFL 0X05D #define SPI$_JNLJRNLS 0X05E #define SPI$_JNLCHNLS 0X05F #define SPI$_JNLWRTAI 0X060 #define SPI$_JNLWRTBI 0X061 #define SPI$_JNLWRTAT 0X062 #define SPI$_JNLWRTRU 0X063 #define SPI$_JNLDIRIO 0X064 #define SPI$_JNLBUFIO 0X065 #define SPI$_JNLWRTSS 0X066 #define SPI$_JNLFORNL 0X067 #define SPI$_JNLFORFL 0X068 #define SPI$_JNLBUFWR 0X069 #define SPI$_JNLWRTFM 0X06A #define SPI$_RUFACTIV 0X06B #define SPI$_RUFJNLS 0X06C #define SPI$_RUFCHNLS 0X06D #define SPI$_RUFWRTS 0X06E #define SPI$_RUFREADS 0X06F #define SPI$_RUFXTNDS 0X070 #define SPI$_RUFMARK 0X071 #define SPI$_RUFMRKRB 0X072 #define SPI$_RUFABORT 0X073 VAX-24 PAGESWAPPER - April 1988 - Volume 9 Number 9 Get System Performance Information Service #define SPI$_FIDHIT 0X074 #define SPI$_FID_TRIES 0X075 #define SPI$_FIDMISS 0X076 #define SPI$_FILHDR_HIT 0X077 #define SPI$_FILHDR_TRIES 0X078 #define SPI$_DIRFCB_HITS 0X079 #define SPI$_DIRFCB_TRIES 0X07A #define SPI$_DIRFCB_MISS 0X07B #define SPI$_DIRDATA_HIT 0X07C #define SPI$_DIRDATA_TRIES 0X07D #define SPI$_EXTHIT 0X07E #define SPI$_EXT_TRIES 0X07F #define SPI$_EXTMISS 0X080 #define SPI$_QUOHIT 0X081 #define SPI$_QUO_TRIES 0X082 #define SPI$_QUOMISS 0X083 #define SPI$_STORAGMAP_HIT 0X084 #define SPI$_STORAGMAP_TRIES 0X085 #define SPI$_DISKS 0X086 #define SPI$_TOTAL_LOCKS 0X087 #define SPI$_ENQNEWLOC 0X088 #define SPI$_ENQNEWIN 0X089 #define SPI$_ENQNEWOUT 0X08A #define SPI$_ENQCVTLOC 0X08B #define SPI$_ENQCVTIN 0X08C #define SPI$_ENQCVTOUT 0X08D #define SPI$_DEQLOC 0X08E #define SPI$_DEQIN 0X08F #define SPI$_DEQOUT 0X090 #define SPI$_BLKLOC 0X091 #define SPI$_BLKIN 0X092 #define SPI$_BLKOUT 0X093 #define SPI$_DIRIN 0X094 #define SPI$_DIROUT 0X095 #define SPI$_DLCKMSGS 0X096 #define SPI$_SCS 0X097 #define SPI$_VOLLCK 0X098 #define SPI$_SYNCHLCK 0X099 #define SPI$_SYNCHWAIT 0X09A #define SPI$_ACCLCK 0X09B #define SPI$_XQPCACHEWAIT 0X09C #define SPI$_SYSTIME 0X09D VAX-25 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby The SIR Lobby Jonathan Pinkley Gould OSD Dept. 913, Bld. 2 18901 Euclid Avenue Cleveland, OH 44117 This is a short summary of comments regarding current SIRs made by various dial-up contributors on the PAGESWAPPER system. I have tried to remain objective, but I am human and I have my own opinions. The summaries are mine, and may show inadvertent bias. This summary is from the Pageswapper SIR_LOBBY Notes conference as it was on Monday, February 22, 1988. The following is the method I have used to summarize. I have arranged the replies into four categories; Yes, No, Indifferent, and Discussion. Following are my definitions of the categories: o Yes -- This is a vote for the SIR. I have limited this to one per person, i.e. if John Doe has left 5 replies in favor of a particular SIR, I count only one as a Yes, the others will be counted as discussion. o No -- This is a vote AGAINST the SIR; i.e. a negative vote. The same one vote per person as above applies. o Indifferent -- Not a Yes, but not a negative vote. o Discussion -- This is a reply that discusses previous replies or possible enhancements to the SIR for a future submission. I have listed these in the numeric order of the SIRs. I have omitted all SIRs for which no replies have been left. - S88-1: SCS Communications Access for Users 1 Indifferent -- Not sure what it means, if it's for cluster compatible utilities I'm for it. VAX-26 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby - S88-2: Better Batch Job Load Balancing 1 Yes -- Would really be best if DEC gave us "user written job (sub-)controller". - S88-3: Privileged Deallocation of Tapes Away from Users 4 Discussion -- how to do it now, what is needed etc. - S88-5: Batch Execution Queue Assignment "Filtering" 2 Discussion -- What does it mean, should it be part of S88-2? - S88-6: "Virtual Disk" Capability 2 Yes -- V5 will probably break most device drivers, therefore DEC should support this. Fall 87 VAX SIG tape will have "memory" disk driver. - S88-7: Identity Information About LAT Sessions 1 Yes -- This needs to be done by LOGINOUT so that login failures will contain the information. 4 Discussion -- V5.0 will have it in $GETDVI. This doesn't solve the problem stated though. - S88-8: Queued ALLOCATE Service 2 Yes -- Good for shops that only have a single tape drive. Also good for shops with 10 drives. - S88-9: Support For Simple Project Accounting 2 Discussion -- DEC indicates security problems with the simple model in the DECUS proposal. - S88-10: BACKUP Added Logging and Incremental Restore 2 Discussion -- Don't BACKUP journals provide logging information? VAX-27 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby - S88-11: DCL WRITE Without CR/LF 1 Yes -- This would make the job much easier to talk to "Smart" modems, etc. ! 3 Discussion -- Work around with READ /PROMPT=string /TIME_OUT=0 - S88-12: More Capabilities for VAX-11 RSX BRU 4 Indifferent -- Discussion about whether this should be in the VAX SIR area. Summary: anything that is related to VAXes that might be resolved by DEC is ok; not just software, not just VMS, not just the operating system. Problem: due to the limited constituency, not likely to make top-10, and therefore the vote may be "wasted". - S88-13: Enhanced Command Line RECALL Capabilities 2 Discussion -- Want to add new features to the SIR - S88-14: Extend DCL TABLES 2 Discussion -- Want to add new features to the SIR - S88-15: DCL Status Return Enhancements 3 Discussion -- The example given already has different status return! Don't waste a vote. 1 Yes -- Need this capability with stable or symbolic return codes. - S88-18: DCL /LOG Qualifier Consistency 1 No -- Not a new different qualifier; at least don't break the old ones! - S88-19: Command for "Control Print Screen" To A File 2 Discussion -- DEC doesn't plan to implement this because they already provide this with SET HOST/LOG. But the whole point is to change DEC's plans! VAX-28 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby 1 Indifferent -- It would be nice... - S88-21: Mail Enhancements 3 No -- Too Much Effort, Too Little Payback 4 Indifferent -- Nice ideas but there are other things that are more important. Only agree with part of the SIR. 3 Discussion -- How the SIR should be changed. - S88-22: SET HOST/DTE Enhancement For More Modems 1 No -- DEC provides for custom DTE dialer modules. There is a Hayes-compatible one on this system in [US197634] for general consumption. DEC should provide for their own modems, not everyone else's. 1 Yes -- DEC should provide this. Also now there is DMCL (DEC Modem Command Language) for their new modems (See V4.6 release notes.) - S88-23: Enhance SHOW PROCESS Command 2 Indifferent -- Nice but... both liked the SHOW PROCESS/FILES part. (jlp) The last paragraph of the SIR states "SHOW DEVICE/FILES on one drive system with many installed images provides too much output." DEC agrees with this and that is why they provided SHOW DEVICE/FILES/NOSYSTEM 1 Discussion -- Shouldn't be able to show files used in a protected subsystem without privilege. - S88-24: MOUNT/FOREIGN and Uninitialized Tapes 1 Yes -- It is a pain to have to initialize tapes that are new. 1 No -- It is negligent to use uninitialized tapes. VAX-29 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby 16 Discussion -- Is "MOUNT /FOREIGN /INITIALIZE /LABEL= /DENSITY=" what people really want? MOUNT (and INIT) /OVERRIDE=(ACCESSIBILITY, EXPIRATION, OWNER_IDENTIFIER, SETID) does it already. Should it be SPRed? - S88-26: /BELL Qualifier for Certain DCL Commands 1 No -- Don't waste a top-10 slot for something that is easily done with the current system. 3 Indifferent -- Not needed, easy work-arounds available. Command files use $ bell[0,7]=7 ... $ write sys$output bell Interactive; just type ahead a CTRL/V CTRL/G. - S88-28: Improving VMS Define Utility 1 No -- Just not worth wasting a top-10 slot for, just don't use ASSIGN if you don't like the way it works. - S88-29: "Wild Card" Capability in SYS$GETDVI 1 Discussion -- Home grown version available from John Ferriby - S88-32: Protection and Ownership Attributes of Directory File This one gets the prize for the most replies. 1 Yes -- There is no way for a non-privileged user to find out where he has copied files to that are being charged to his quota. It is not possible to use identifiers to create a "write only" directory. If the person that copied the file into the directory does not give delete access, the person who owns the directory can not delete it. (jlp) This may lead to "lost" files, since the person could SET FILE/REMOVE to get it out of their directory. VAX-30 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby 5 No -- Could break existing code, the default must not change. People would use this to move files into someone else's area to prevent being charged for it and to get around the quota system. Just because another O/S has it doesn't mean it's the "right" way. 15 Discussion -- Discussions of several alternatives. Alternative #1: Have a bit in the directory file header that will cause files to change ownership to that of the directory. Alternative #2: Provide a privileged utility to let people change the ownership of files in their directories. - S88-33: Provide A Real-Time Debugger 9 Discussion -- What does this really mean? - S88-35: Control DECnet File Transfer Priority 2 Discussion -- Priority of what? process or decnet channel? 1 No -- If it means changing the NCP or NETSERVER process priorities. - S88-36: Descriptive Text For Files 1 Indifferent -- capability is there via ACL 4 Yes -- It would provide a needed functionality, and it needs to be part of the file as opposed to being in a description file (ala the Norton Utilities under MS-DOS.) 4 Discussion -- Application ACEs are described on page 3-18 of the System Services Reference Manual, section 3.4.1.2. Up to 253 bytes of your choice. This could form the basis for the needed functionality. This was previously in the top-10 and DEC said that the underlying capability was there via the "informational VAX-31 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby ACE" and that they would provide the DCL interface in a future release. - S88-37: READALL Should Only Permit a File To Be Read 1 Indifferent -- This should be an SPR not an SIR. 2 Yes -- Yes it's a bug, but we need to let DEC know we know it's a BUG. 1 Discussion -- It's a documented feature, but it should be changed. - S88-38: Run New Images Under Old Major Versions 2 No -- Would cause too many nasty side effects. 5 Discussion -- Several work-arounds discussed. - S88-40: SMG/non-SMG Screen Interaction 1 Discussion -- An example - S88-41: DECnet Copy Performance to Same Node 2 No -- Causes security alarms, etc. 1 Indifferent -- Only if transparent. 1 Discussion -- Will be in Future Major Release. - S88-42: Install Images Memory-Resident 1 Yes -- This could help 2 Indifferent -- Not needed, is the right thing being optimized? 4 Discussion -- What about RAM disk, etc. - S88-44: Multiple MACRO Modules Per Source File 4 Indifferent -- Slightly pro or con VAX-32 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby 6 Discussion -- Is it better to have only a single module per source file for software tracking? - S88-45: VAX Ada Package for VMS Run-Time Library 2 Discussion -- Why only Ada? Strong type checking too! - S88-46: Line-Number Support In TPU 3 Yes -- No efficient way to do this now. - S88-47: Eliminate Automatic Unsolicited ACE on File Creation 3 Yes -- The "Magic ACE" causes too many problems. - S88-48: Prevent Password Reuse by Users 3 Yes -- This is a necessary part of password expiration. 1 Indifferent -- 1984 was four years ago... 10 Discussion -- Best way to implement, and how not to. - S88-49: Suppress Login Failure "Error reading command input" 1 Yes -- This is not really a login failure. - S88-50: No File Modification Date Update on Protection Change 1 No -- Will break existing method of determining if something has changed when things stop working. 2 Indifferent -- The file contents haven't changed, why set the modified date? 4 Discussion -- More date fields in the file header would solve the problem. VAX-33 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby - S88-51: Protected Subsystems 1 Yes - S88-54: DECnet-VAX End-to-End Encryption 1 Indifferent -- Need ability to use hardware if it exists already. - S88-55: Support DECnet Proxy Access for SET HOST Command 1 Yes -- This would eliminate one more of the remaining situations where a password has to appear in plain text. - S88-56: Better Control Over DECnet Remote File Access 1 Indifferent -- Only through special ACL's so it would be optional. - S88-57: Enhance COPY to Copy ACL's 1 No -- The ACL should be determined by the destination. - S88-59: General Identifier as the Owner of a Process 1 Yes -- This is working toward an environment without System, Owner, Group, World. It should be kept as an option. - S88-60: Security Alarm ACE Bypass by Certain Users 2 Indifferent -- Good Idea but... 3 Discussion -- Security and Bypass in the same sentence? - S88-61: Print Form Setup and Reset Modules Verbatim 4 Yes -- This must be fixed! VAX-34 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby 1 Indifferent -- But this should be an SPR 4 Discussion -- But DEC ignores SPR's ... - S88-62: BACKUP Dismount and Deallocate Tape Drives 1 Yes -- but it must not be the default. - S88-63: Bell Character to Certain BACKUP Messages 1 Indifferent -- Cute but is it worth a vote? 1 Yes -- This has been needed for a long time 7 Discussion -- Suggestion for a generic way; SET MESSAGE /FACILITY /IDENT /SEVERITY /TEXT /TIME /BELL - S88-64: Limit Simultaneous Interactive Logins 1 Yes -- No easy way to do this. 2 Indifferent -- What about something in SYLOGIN? 5 Discussion -- Why MAXJOBS won't work - S88-65: Distributed Management of UAF Parameters 1 Indifferent -- Write your own using SETUAI and send it to DECUS - S88-66: Working Set Quota/Extent Via INSTALL 1 Indifferent -- Not really necessary 1 Yes -- Good for All-In-One users - S88-67: Execution Priority Via INSTALL 1 Indifferent -- Incomplete specification, would this affect all types of access? Would it be absolute priority? - S88-68: Multiple Layered Product Versions on One Machine VAX-35 PAGESWAPPER - April 1988 - Volume 9 Number 9 The SIR Lobby 2 Yes -- Would make upgrades much smoother. - S88-69: Stand-alone BACKUP Support On More Devices 2 Indifferent -- The problem is the ROMs 1 Yes -- Let there be ROMs 7 Discussion -- How it's handled on the 11/73 etc. - S88-70: More Output File Qualifiers for BACKUP Restoration 1 Indifferent -- "Oh Gawd, not MORE qualifiers!!!" VAX-36 PAGESWAPPER - April 1988 - Volume 9 Number 9 LUG News LUG News Meeting topics for April - from respective LUG Newsletters _S_t _L_o_u_i_s _L_o_c_a_l _U_s_e_r_'_s _G_r_o_u_p_: Second Tuesday of every month at the Salad Bowl Restaurant 3949 Lindell Boulevard 5:30 pm - social time 6:00 pm - dinner 7:00 pm - program April - PDP Topics - (possibly a case history of a migration from PDP to VAX given by Ken Denson). _M_I_V_A_X_L_U_G_: Lawrence Institute of Technology Management Building, Room M336 10-Mile Road Southfield, MI 6:15 Open Steering Committee meeting 7:00 Main Meeting April 12 - Configuring Ethernet LANs - Jim Raquepau VAX-37 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture A New VMS System Management Architecture From the Fall 1987 (Anaheim) Symposium Session by Jim Swist, VMS Engineering Digital Equipment Corporation 110 Spit Brook Road Nashua, NH Transcribed by Ron Frederick National Institute for Petroleum and Energy Research Post Office Box 2128 Bartlesville, OK 74005 Most of you were probably here for the system management talk I gave two hours ago. Then I talked more about the nuts and bolts and practicalities of the day-to-day improvements we have been doing or thinking of doing. This talk is different--I am going to talk about something called architecture. Have you heard the definition of an architect, particularly in software terms? Well, an architect is someone who knows a thousand ways to make love, but has never been on a date. Architecture is a framework in the strictest sense. A way to think about a problem and a way to put this problem in the context of a framework it never had before. I am not describing any one thing. I am going to describe generally some thinking we have had and solicit your feedback. The next major release may have the beginning pieces of this. We want to put our system management software in over the next several years, in several major releases, not just the next one. First, I will talk about what this problem is we are trying to solve and give a summary of the approach taken to solve this problem. Then I will present the new architecture, including a major component called a "human interface." We want to run by you a separate set of strategies for that component. Since this is a relatively short presentation, there will be time for questions and answers at the end. What is the problem? There are a lot of professional system managers in this audience so this doesn't come as news to people. Our system management facilities are based on the original 11/780 mode. The 11/780 system management model is a derivative of the PDP-11 model--a part-time technical user who ran into the computer room twice a day, authorized the users, VAX-38 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture backed up the tape, and was very knowledgeable. It was a part-time job. Our audience was the same type person when we went to the 780. He just continued in that direction. Today we have the so-called "desk-top data center," a breadth of range of configuration, yet we still use that same, very simple-minded, "system management model." The feedback indicates that we have strained that model at both ends. At the high end--many of you people here are system managers of very complex configurations. The world is distributed; people are managing multiple systems. Unfortunately, there are many, many utilities and interfaces to learn. There is much repetitive work, repeating what you are doing on all the systems you deal with. We have professionals at the high end, dedicated operators, dedicated administrators, yet we don't have any special facilities for them. We basically tell everybody, "Give yourself some privileges, use the general purpose interface, and a few odd utilities." At the low end--we are into workstations and very small systems competing with the PC-mentality, as I call it. That sounds like a derogatory term, when, in fact, it is a very good model. It comes out of the box and it works; we don't worry about system management. Yet, this low-end user is faced with the same plethora and array of system management utilities as the high-end user and essentially must learn to use them all in order to deal with a small system. There are reasons why we arrived at this situation, but a lot of it has to do with there not being internal software architecture for system management. There's nothing written down saying, "If I'm going to add a new facility to VMS, this is what to do." Let's pick a major new category, local area VAX clusters. Local area VAX clusters have a system management component. There is nothing written down anywhere saying how I implement the system management component. What rules shall I follow? Does it become a part of some utility? Do I add some DCL commands? Do I provide SHOW commands to monitor some things? None of this stuff has been defined. Over time, whenever a new facility of system management content was added, we came up with whatever was convenient. We have a broad range of interfaces in the system management area, including DCL commands, special utilities with special syntaxes, special editors, like the ACL editor, canned command procedures like VMSINSTAL, SHUTDOWN, AUTOGEN, things like that. VAX-39 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture There are probably four or five different interface models. We have a real problem now because of extensibility. We'd like to say "We have new audiences, and we have a new configuration we never had before." We want to deal with this situation, make help available in some easy to use, very specialized way, but there is no easy way to do so. Everything is there. There is no layering, so layering is what we really want. The distributed stuff is the other big problem to solve--the world is distributed. We have had some success in giving the illusion of a nondistributed system for end users. Our file systems and applications packages essentially make the data location and the data processing transparent. We have done a pretty good job there and our customers and applications packages have also done a good job there. We haven't done a good job in the system manager's arena, separate systems are here and things are distributed. The exact nature of that distribution has to be understood. In general, there are very few support tools for dealing with problem. I call the other thing a consolidation problem. We really do not distinguish, at this point, between system management and end user human interfaces--the system manager's interface on the VMS is the end user interface with some privileged extensions. There is something to be said for that if the user and the system manager are the same person, but as I stated earlier, these are diverging. The system manager at the high end is a professional, not necessarily doing the same thing as an end user, and at the low end, maybe a system manager, but not by choice. These are some of the problems we are trying to solve. We did an organizational focus first. We have a group which worries about such--the management within VMS. VMS has been around a long time, almost ten years now, and we never had a system management project per se. We had a security project, and we had the volume shadowing project. We had a DECnet project and an exec project. Any system managing all those things was invented in those projects without any coordinating body. We are not trying to do everything in this group, but we are trying to act as a clearing house and provide a place where people can come within the Digital development organization. Say we add a piece to VMS--a new product, a new layered product, or a new optional function and here is the system management piece. What should it look like? We've never done this before. I think this is a big step in the right direction. VAX-40 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Goals There are four major pieces in the solution aside from the organizational one; we had a new internal software architecture, which I will go into. It's a three-layered architecture which solves a lot of these problems. An interim user interface called "Sysman" is a part of the next major version and initial implementation of this architecture is also provided as discussed in my previous talk. We concentrate on this question of human interfaces and how to handle multiple audiences across a broad range. There are, of course, other points in the system management area which don't fall strictly into these particular problems. We want to look here, too. The goals of the architecture follow: Goal - Consolidation We want to consolidate the internal system management functions under a uniform call interface. Meaning we want to have a list of internal management functions. There will be a call for each one and a structure of the parameters for the call. The calls are very similar from function to function. We don't have such a list today. We want to treat VMS system management as a recognizable software subsystem with a defined set of boundary interfaces, conventions, and such, rather than random extensions...the general user interface. We want to provide distributed services as a standard feature, not something pasted on or, typically, something the customer adds. We want to separate form and function in recognition of the need for multiple human interfaces. My previous statements on multiple audiences show that system management is a multiple human interface problem. The human interface onto system management functions is completely different from the high to the low end. We don't want to reinvent all the low lying components supporting those functions. The small system has to authorize the user as well as the large system. The difference is the way it looks to the user. It is presented in a very simple way with very few parameters for the low-end user. The high-end user might have all the full blown functionality of an AUTHORIZE utility with VAX-41 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture all the privileges, switches, and options. We don't want to rewrite the underlying function to maintain a user authorization file every time we have a new requirement for user interface. Goal - Documented Interface Next, we would like to document all these interfaces in the recognition that VMS Development is certainly not omniscient in all the human interface will require in the future. There will always be special-purpose audiences. We even have groups inside Digital which are not in our group. For example, the Office and Information Systems group has an All-in-One product targeting an office/secretarial environment. Perhaps these people would like to have a system management interface specific to that audience. They should be able to look at some document and write a human interface for that audience without introducing hacks of layering onto something which was never intended to be layered on, or worse. The last goal of this architecture is to recognize there are other management architectures. The significant one we deal with daily is network management. We want to provide inter-operability of VMS management system architecture with network management architectures in it, including any other ones which come along. Layers of Implementation Now let's have a technical overview of what we have done. We divided the components dealing with technical management problems into three layers. I'll describe them from bottom to top in some detail.At the bottom we have a primitive function layer; above that layer, another layer we call integration and common services; above that, another layer we simply call the human interface, of which there are many. Subsequent slides show each layer in some detail. VAX-42 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Primitive Layer Starting at the bottom, the primitive layer. What does that word mean? System service, RTO routines or other callable modules performing some lowest level, atomic function, for example, an ACP QIO to modify a parameter into the callable SYSGEN utility which is something we created as part of SYSTEM CHANGE, a system parameter, etc. There are many examples. Something modifying a record in the user authorization file. These are lowest level, atomic functions in the sense that they can't decompose into any functions which themselves would interest system management. In that sense they are atomic. Many of these parameters are shared with the general user interface. Access control, various other things, not necessarily a directory creation of something to be used by system management when we create a new user. Yet the end user does directory creation all the time when creating a subdirectory. That is another characteristic. Uses of these low-level components are mixed between system management and the regular user programming interface. Another characteristic, an implicit acknowledgment of what exists. There are different types of call interfaces. Some are system services, some are QIO functions. There are a number of different pieces in the system. We have to live with the fact that in this architecture we have a number of low-level primitives implemented over a period of time in different styles. We don't want to rewrite all this when we have a new system management architecture. Last, the primitive layer is very notions distributive. Some of these low-level primitives, for example, operate databases on cluster-wide disks for automatic cluster-wide distribution. Some operate only on in-memory databases. Depends on what you look at. Some things are distributed and some things aren't. We have a set of low-level functions, variable in terms of distribution and in the style of call interface. How they are used between system management and non-system management programming interfaces to solve the problem of all these different low-level functions inside the system. VAX-43 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Integrator Layer The next layer up is the integrator. The integrator layer is designed to smooth out the differences of all these low-level functions and provide a single, common call interface to the human interface layer sitting on top. There is one integrator per system--this is the common control point for all system management functions. We finally have a thing inside VMS we can call a system management control point, not some random piece of code somewhere. This is nice because if we want to deal with something such as logging or various security things, there is someplace we can go. All system management functions pass through this layer. That is the first good point about it. Another good point: integration translates the nonuniform, primitive call interface onto the uniform call interface seen by the user of the integrator. The integrator also provides the form distribution mechanics, despite what is going on at a lower level. For example, if a low-level, atomic function is not inherently cluster-wide, the call interface to the system integrator to the higher human interface is to do cluster-wide functions. The integrator does those things necessary by repeating that function on each node in the cluster so the human interface doesn't have to worry about that particular problem. I mentioned before about the architectural anchor point through which all functions pass; I'll go over that point again, just as an implementation point. The integrators talk to each other. That is how we do distribution. The call interface to the integrator is exactly the same regardless of the atomic function being implemented-- whether it is in the local system or a remote system. Implementing human interfaces which deal with distributed configurations is easily accomplished without going through tremendous gyrations. The user needn't worry about where these things are being executed. The last point of the integrator: it is human interface independent. The call interface to the integrator is not dependent on any particular syntax or style of implementation, character cell workstation, whatever. This call interface can support multiple human interfaces in the same system. An easy- to-use interface and a more sophisticated interface can run in the same system against the same integrator. In fact, the human interface might not even be human. It could be an AI-type interface or, in the future, a type of sensing interface which figures out your thoughts about your system and then does it. VAX-44 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Human Interface Layer The top layer is the human interface layer. We have a separate strategy associated with this one. I will go into some detail as this is important. Multiple instances are possible for human interfaces, each one for a specific audience. All low-level services are provided by the integrator call interface. These human interfaces do not do any system management, low-level functions themselves. They worry about presentation, dealing with the user, user assistance, help, formatting of error messages, all those things which are very audience-specific. They don't worry about whether the fifth bit of the fourth field contains the privileges. As I said before, it doesn't have to be a human interface. It can be some kind of automatic mechanism or some other kind of layer. It is important that an architecture like this be somewhat open-ended. Do not assume the human interface is going to be the last layer. Doesn't have to be a human interface, it can be a program talking to something else. The human interface is free to aggregate or subset the lower level functions as necessary. Example, in a simpleminded user authorization scheme you might want to automatically add a proxy account, add some disk quota, create a top level directory, do all kinds of automatic things the system manager wouldn't deal with, and they all default. Those functions should be separate in a sophisticated environment because the system manager requires separate control of those things. The human interface does that kind of aggregation as necessary, as well as subsetting. It doesn't have to implement all the functions available at the integrator level. The human interface also can provide any view of the distributed system appropriate to the audience being served. You might, going back to the example of the simpleminded, low-level interface, want to hide everything that is cluster-wide in the human interface. All things are the same in a homogeneous cluster--why should the system manager worry about that. Let the human interface internally figure that out. In the more sophisticated case, you may want a human interface to provide control when dealing with individual systems. Human Interface Categories VAX-45 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture I've discussed the lower levels, now let's talk a little more about human interface. "Sysman" is the first human interface under this new architecture and we would like to build new ones on it. A new terminal medium is needed for system management, particularly in larger systems. We've announced the DEC windows program. At this point that program is the target for all future work with human interface. The DEC windows program uses the X-protocol where something as inexpensive as an IBM-PC or a PC clone can run the X-server and provide a bit map interface in a system, at a cost comparable to a character cell terminal. We don't believe that reduces the cost problem any more. The need for additional real estate on a workstation screen is obvious when we manage a cluster or a complex, distributed configurations environment. To that end, we think it is a good idea since we can't do everything to minimize investment and character cell terminals in terms of system management and human interfaces. To target the multiple audience problem, we have divided the audience: Class I, Class II, and Class III. We define three audiences, which I'll run by you in the next few slides. These are interfaces we think we need. We start from the bottom, the top in terms of capability of the person doing the system management. Class I - Human Interface for Workstations Class I is a stand-alone workstation, or a workstation loosely coupled to a network in the Ethernet, or a light area network connection. This is the PC-mentality user I mentioned before: somebody who is using a workstation to accomplish a job, a person not versed in system management and probably doesn't even want to do it. In some cases we have tools. For example, we have our RSM to do remote backup and loading of optional software. This person might be helped by some centralized network service. At this time, however, a substantial subset of the full VMS system management functions is required to deal with the management of small workstations. That is a big problem. The PC mentality is good here because we can think of this problem in a completely different way now. VAX-46 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Class II - Human Interface for the Desktop Class II is essential to what we call a desk-top strategy. We are very high on local area VAX clusters. We think they eliminate all system management problems for end users. You boot off the common system. All system management is essentially done for you by the system manager of the boot node. We have not dealt with the system manager of the boot node. We see local areas VAX clusters being deployed in office environments. For example, half a secretary's time is spent system managing this local area VAX cluster. We've done that within Digital in a couple of test installations without much success. Most interfaces require full CI cluster knowledge. We think there is an important intermediate user audience between the workstation and the user in the full blown, large cluster manager. I'm talking about a Class II audience. We don't want to assume extensive DCL knowledge or knowledge of the VMS utilities, as I said before. Clusters are not making the progress we would like at the low end of the marketplace. The system management problem is a big, big piece of improving this progress and why we want to deal with it. Class III - Human Interface for Traditional Environments Class III is everybody else, traditional audience, a lot of people in this room. These systems have become complex enough--enough systems and enough software to manage them--that we are talking about dedicated jobs. You are also going to be talking about a multi-role environment. A typical large environment consists of security managers, operators, technical administrators, nontechnical administrators, accountants, people like that. All these roles are possible. These people are system managers. It is important that the model we produce allows the creation of multiple user interfaces. We could have an operator interface completely centered around the functions of the dedicated operator role. A technical user interface and a technical system management interface in the same site, both working as parallel human interfaces off the same set of lower level, system management architecture components. Some of this is conjecture. If you think this is really off the wall, please let me know, but this is the way we see it going. I'll go in VAX-47 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture the reverse order this time. In the Class III area we've done the "Sysman" work for the next major release to make distributive configurations easier to manage and consolidate a few things. Future Development We think a DEC windows version of the same thing is the next important thing to do. DEC windows here are not so much for the mouse- and ease-of-use- type things of the PC mentality because we are not dealing with that kind of user. But the operator interface and the screen-use interface are essential when managing large configurations. To have a recognizable subsystem we need to continue consolidating the bits and pieces in various corners. Other major new subsystems within VMS will have a system management component. We want to make sure everything coming out in the future is architecturally compliant with this new model so we need to minimize the number of new random utilities for the system manager. We want to do something about these new specialized role interfaces. The operator interface bothers us at the moment -- the opcom request reply interface. We feel this is inadequate for the professional computer room operator (LOST ON TAPE) We have an advanced development project underway again. This is just advanced development, nothing necessarily is going to happen with this as a product. We have a DEC windows-based, Class II human interface for the system manager of the boot node of a local area VAX cluster which is relatively bounded and isn't mixed or interconnected. Something we can get our arms around. It's a single interface for all functions. A menu-driven, DEC windows-based thing doing nine or ten major system management functions: authorizing users, backup, restore, printing error logs, configuring satellites, configuring a controlling network, installing optional products, shut down, dealing with the queue manager, some media disk structure and maintenance management. All from one user interface. We can produce something like this. We will be able to sell people local area VAX clusters and succeed at our goal: a nonprofessional system manager who doesn't have a great deal of knowledge, in particular doesn't know DCL, and hasn't managed VAX-48 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture the system. It's not going to be easy, but we think we can do it. The Class I human interface strategy there involves recognizing the I-don't-want-to-do-system-management syndrome. We are working on various advanced development projects to pre- install VMS and have it work coming out of the box. This kind of thing totally hides system management. Where we do have to have some, it would also probably be DEC windows based and a subset of the Class II interface. Question and Answer I think that's all; I was going to make up these big question slides for the end but I forgot. That's the end of the formal presentation. At the risk of repeating myself, this is a bunch of ideas. We've done some work in some areas, we have some advanced development in projects in other areas. I'd be interested in comments on this as opposed to the last session. I'm not telling you that you shouldn't ask certain questions, but things like the backup utility needing a new bar switch probably aren't appropriate for this presentation. I'd like to keep it at a higher level in terms of the technology. Q: Dick Picard, Kalamazoo College. I'm delighted with your direction. I think a couple of things are likely to be common to a number of...at least college environments, if not commercial ones. Every fall we get this surge of new account creations as the new students arrive and every June old account deletion. We have this extensive DCL which is doing very nicely and obviously will need to be reworked. That doesn't bother me, but I hope you give us as much documentation as possible to study before we try to put version N up. Also, we have operators who are, in many cases, students working part time, and a very limited staff. Many of the specialized roles you project are, in fact, going to be one person. Even though you may envision this specialized role in your mind, keep a human interface consistent across all those roles. At least one of the interfaces available should be consistent. VAX-49 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture A: Well, I think stylistic consistency...human interface is very important for the multiple roles in a given shop. I think your first question is probably the hardest problem we deal with on a day-to-day basis: how to evolve VMS, do new and better things, and not mess up existing stuff that works. We intend that the old stuff will always work. We are not going to throw anything away, but we hope people will migrate to the new stuff because it is better. I wouldn't be too concerned that suddenly things may stop working. We've tried pretty hard to not stop things in the past, not always successfully, but we tried hard. Q: Mike Lynch, 3-M. I came a little late so forgive me if I missed this. Did you talk about AI tools in terms of tuning a performance management system as part of this whole bundle and, also, are you suggesting from the biasing of your slides that most likely we will see this thing in LAVC support before we see it in large clusters? A: I wouldn't say you will see it anywhere before anything else. We thought this area needed work and was particularly interesting. At the moment, this is just an advanced development project which isn't necessarily going to show up anywhere. What was the other part of your question? Q: What about performance tuning? A: Oh, AI tools and stuff. We look at the idea as an open-ended architecture to support multiple human or non-human interfaces and make creation of those things easier. The architecture itself does not deal with those things. People are looking at that stuff from other groups though. Q: Is it more likely to be further away than the other things you are talking about? A: I can't make any comment on that, sorry. Q: Lawrence MacIntyre, Martin-Marietta. I might add that I am delighted with your direction, too. We've everything from the large systems to the MicroVAXes on some scientist's desk. I would say Class I is probably going to see the most use. We have a lot of phase one, Class I at our installation and those people don't have any help. Some kind of logging facility would be nice. We have this problem with operators. They do something at night and say, "Well, I tried this and VAX-50 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture it didn't work," and the machine will be down. We would like to capture what they did. A: In theory, if we ever implement this, we would have a central point. We could do consistent system management auditing and not have the place in three different logs or not at all. The potential is there and is one reason the thing is designed the way it is, so we can do this. We had experimental versions of things which in fact do log all system management functions. Q: As far as Class III, the large systems, only the distributed stuff would be really nice. The rest of it... A: Yep, I understand. Q: Ted Bolson, University of Washington. I thought my 750 was a PC (talk about my mentality). I want to reiterate the thing about performance tuning before I get to my question. My feeling for a long time has been that a DEC system initially performs badly so they can sell you their software tuning tool. I'd rather have a management tool do it for me and not have to integrate all kinds of extra software. Queue management definitely is a big thing to look at for your new interface, a current method of stop-start, show queue, etc, etc, needs--I can't even imagine how much...it's like you have to start over from scratch. I've got people who take longer to figure out how to stop the queue than it takes for the garbage to print out 40 pages. That's the kind of single person management... A: A classic case of the problem I was talking about. It started out as a very simple thing and there is a mixture in that queue interface between end user function and system manager functions. They become all mashed together. That's a classic example of why we need new architecture. Q: The most important thing is speed. It is a user interface issue because you don't want to run "Sysman" and set your environment, etc., etc., etc. By the time you have done all those things, the system has already thrown...from too much stuff all over the place. VAX-51 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture A: Right. The system management function is legitimately run by end users in many cases and we want to support that. Q: Jim Wheeler, Bureau of Reclamation, Sacramento. We have a distributed means of system management. Have you planned into your architecture a means whereby you can have feedback from one level of system management to another. For example, we have 730s on the site. We do a great deal of our own work, and they should, but actually I have a lot of visibility with what they do. My calling them would be more useful than their calling me, saying "Mother, may I." A: I'm having a lot of trouble hearing you. Would you run your question by again. Q: Have you built into the architecture a means of communicating between level 2 and level 3 automatically so a level 2 manager and a level 1 manager, or level 3 manager, can interact without having having to pick up the telephone. A: That's what's nice about having your own theoretical architecture. Yes, it is possible. Just a small matter of programming. There is a formal split in this architecture between human interface and underlying components. Yes, you can do so if that is the case. Q: Phil Naecker, Professional Press. Back to your layering diagram, can we play, too. Can I write at all three of those layers? Do you intend that I will be able to write my own user interface? Can I add things at layer 2 and layer 3 and in some way buy in to the work you have done? A: Good point. Having the formal call interface at the top level is more important initially. We also recognize that other people are going to create functionality which adds to VMS and has a system management component. It would be very nice if they could come into the low levels of this architecture also. This requires documenting the architecture at all three levels which is of course a much...I would have to say a much longer term goal. Very desirable. Q: You might consider the remote portion so at least we can play the remote game with you. VAX-52 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Q: David Richie from Fermi Lab. The ability to decentralize certain things to a particular user managing a group or project is helpful to a large system environment. This immediately comes to mind--I would like to take all the quota stuff and say to experiment xyz, "Okay, you have got 100,000 blocks of quota. You divvy it up between your users." There are other areas where new accounts...a person joins the experiment...I'd like to say to the group manager, "Okay, within some parameters you create some kind of account." That ability would be interesting. A: That's come to us, we've had SIRs on that in the past, too. It's called hierarchical system management group system management. We have been looking at this area and find it is a real problem. Q: Dave Schafer, State of Texas. Are you looking at the OPER utility under TOPS-10 as a possible interface for the operator under VMS? A: I'm not familiar with it. Are you telling me I should look at it? Q: I'd suggest you look at it as a possible starting point. Q: Louise Whooley, Measurex. Since this is sky-blue-type activity, I'm a naive VAX user. I just bought 15 nodes of ______ and I am going to stick 'em in all the engineer's offices. I want to plug it in, have something come up ask me a few questions, maybe something about how many queues I want or what kind of user things I want. Have it build up a nice database and plug all that stuff into all the system management tools automatically. Whatever has to run to make the system come up every time I boot it with all that information. A: That's what we want to do to. We'd sell millions. Q: Gary Bellum, Monsanto. I assume a normal DCL interface to all these functions will be available, which means you will be able to get around all this, or any automatic logging features, or anything like this...bypass. VAX-53 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture A: We have upper compatibility reasons as well as sites very happy with what they are doing now. We don't want to supersede anything we have. We are not going to enhance the DCL interface because we have limited resources. We think we should put our money in advanced development over the next few years as I outlined in this presentation. That's our best guess at this point. Q: You will be up against making assumptions and using them to make decisions. You may find that your decisions do not match users' reality, and they will hesitate to use your work. A: Right, but I can argue on that one. We got in trouble by going too far in that direction in the past. We avoided making a decision. Every time there are two possible ways of doing things, guess what we do. A SYSGEN parameter...let the end user decide which one to use. We have done so to extreme within the system and perhaps it is time to go in the other direction. We may make a few wrong decisions here and there, but the capability of multiple human interfaces, etc., minimizes the problem. There are ways to get around it, but let's lower the choices for at least some of the new audiences. Make system managers out of everybody. The interface should be easily customized. Come up with a basic human interface they can tweak to their heart's content and make it as they want. That, of course, is my long-term, idealistic dream--to supply a tool kit so the user can put together a system management interface for whatever audience he or she has. That would be wonderful, but also hard problem. Q: Spencer Coskiss, from John Hancock. I agree with your direction, but aren't you potentially creating another problem? I agree with the direction if the reluctant system manager's job is easier. By forcing him to learn a lot, are you not lessening the probability of his keeping the system up and running well? Aren't you creating another problem? A: Well, we are trying to do a good enough job to keep the system up and running despite him. We have to solve that problem. VAX-54 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Q: How will you facilitate this thing if you are not going to make a self- tuning system? Tuning will find bottle necks and correct them before there is a problem. A: I think in the long term we have to, all the vendors do. You think about it. The programmer productivity problem of 1970 is now a system manager problem of the 1980s...we can't find enough system managers with enough talent to handle all the hardware out there. We have to solve the problem and so does everybody else. Q: ..., Eastwest Center. I'm glad you addressed that issue because it is clearly the problem we face. We have two system managers--one is a junior grade, the other is standing in front of you. More products like this will enable more senior members to come to DECUS while the junior members run the shop. DEC windows implies the use of VAX stations; that makes a lot of sense from the presentation point of view. The upper limit for a number of LAVC VAX stations is 26. I wonder what your thoughts on that would be. We would have to pull one workstation away from our user base for our operator or manager. A: We are not talking about a full-time management job. It will be shared along with other functions. If you don't want to lose a workstation, I understand. Q: I wonder what are your thoughts on that. Are you saying losing a workstation is the cost of coming to DECUS? A: I think it is, but... Q: I'm Joe King, University of Wisconsin. I think you are addressing my case more than most of the people who come to the mike. I thought I would state what that case is. I'm actually a scientist who has been forced into systems management. The only way to use our workstations is to have some sort of management. We've been forced into LAVC, meaning I'm the only one who spends enough time managing them. No one else wants to. This ideal is what you are talking about and I think a lot of the audience doesn't quite see because they haven't lived in my shoes. VAX-55 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture Q: Dwight Chandler, RealShare. You talk about our being able to write user interfaces...is there going to be a sort of fourth generation language, a FORTRAN, C thing, or what? A: The interface at the moment is a VAX-calling, standard compatible program. You would have to call it from a program, a third generation language. Q: Would there be an interface in it, like lexicals with DCL, that type of thing? A: I understand that would be more of a system manager productivity thing for creating other system manager human interfaces. I understand the problem you are trying to solve. I'm not sure we have been able to put a short term effort into it. I do hear you. Q: That second layer would probably run time-library routines. Q: Keith Chadwick from Fermi Lab. Will there be support for the VAX cluster console interface? Or enhanced support for the VAX cluster console? A: I hadn't thought about it. I'm dealing with architecture here, I am not interfaced to any particular product. Q: Jeff Brunkorst, Mayo Foundation. Is your position held within the VMS group or is it a DEC strategy? I.e., I see myself in a position of managing a VAX cluster, MicroVAX stand-alone, LAVCs, Unix workstations, and PCs. Can this product or, a set of these products distributed like DECnet, fit into your architecture? A: As a long-term goal. The interface with other architectures is important, particularly the network management architecture. In that case, of course, the integrator protocol that talks to the other integrators would be a public protocol of some kind and you could have other implementations of that. A very nice thing to do down the road. Q: Are you working from a VMS position or is this something DEC supports? Do you see DEC supporting this overall? VAX-56 PAGESWAPPER - April 1988 - Volume 9 Number 9 A New VMS System Management Architecture A: I think probably both as long as DEC is supporting multiple architectures. We try to cooperate with that support in the VMS group. It is probably not realistic to expect something like that immediately. Thank you very much. VAX-57 PAGESWAPPER - April 1988 - Volume 9 Number 9 VAX Performance Working Group The VAX Performance Working Group is just starting and is open to suggestions for projects. We're also looking for members who can contribute their efforts to the projects. Projects already on the agenda are: 1. Developing a list of the important performance data, along with the places the data are reported. This will result in a valuable reference for VAX performance people, and will also help us catalog important data that are missing. (For example, it seems impossible to get the I/O's on a disk broken down by workload or process. Also Monitor still does not report any data on sizes or lengths of disk I/O's, so you may have very long seeks without realizing it.) 2. Developing methods of obtaining and reporting reliable performance information on new hardware and software releases. 3. Of course, a lot of war stories and hints/tops will be traded. If you have a suggestion or are interested in joining a project, please contact John at the address/phone below: John T. Peterson Datametrics Systems Corporation 5270 Lyngate Court Burke, VA 22015 703-425-1006 VAX-58 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange Mail written I/O submissions (no special form required) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. ================================================================ Note 542.4 Diagnostics on the system disk of the u-VAX 4 of 4 "Michael A. Stams" 26 lines 13-FEB-1988 19:40 -< Installing MDM on your system disk >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 8 Number 5 (December, 1986) through Pageswapper Volume 8 Number 6 (January, 1987) > I am interested in a way to run diagnostic on a Micro-VAX from > the system disk (Instead of the TK-50 or floppy ) Using v1.12 of MDM I have done this two different ways. Copy the diagnostics SYSBOOT.EXE into an alternate system root or into [SYSMAINT]DIAGBOOT.EXE. Copy all the "loadable images" into SYS$SYSTEM. The diagnostic monitor has been written to load these from "bootdevice":[SYS0.SYSEXE]. VAX-59 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT To boot from the alternate root: >>>B/20000000 ! where the alternate root is SYS2 To boot from [SYSMAINT] >>>B/10 ! as indicated in a previous reply I have yet to try it on later 1.xx versions. Have fun and write protect everything! Michael A. Stams Boeing Aerospace Corporation P.O. Box 3999 Mail Stop 3l-09 Seattle WA 98124-2499 ================================================================ Note 547.1 Software Development Portfolio Licenses 1 of 3 "Harry Herman" 56 lines 25-FEB-1988 16:06 -< New information on Software Portfolio >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 8 Number 6 (January, 1987) We have been looking at the Software Portfolio Licenses that Larry mentioned in the previous note. Thanks Larry, we would not have known about them if you had not published the information in the Pageswapper! In looking at the portfolio licenses, we asked the local sales office for a current list of what products were on the portfolio, in case things had changed since 1986. We were sent a photocopy of page 9-35 of the January-March 1988 VAX Systems and Options catalog. In comparing that list with the list from the above note, I noticed that the current list did not mention VAX Notes or VAX Teamdata. I called our salesman and mentioned it to him, and asked if he could find out an 'official' answer as to whether or not Notes and Teamdata were dropped from the list. He passed me off to somebody else at the local office, and after several attempt to describe the situation to her, she said she would see what she could find out. I then asked her if she could call Mass. and get an official answer. About 1/2 hour later I got a call from somebody else who simply identified herself by name and that she was from 'DEC'. She did not say VAX-60 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT which office. She proceeded to say that if the VAX Systems and Options catalog was wrong, they would have an addendum saying that the book was wrong, and since they had no addendum, the DECUS article MUST be wrong. When I found out she was still from the local office, and that no call had been made back to Mass. to get an official answer, I pointed out to her that an addendum can only be sent out saying something is in error if somebody has noticed the error and bothered to send out the addendum. I then asked yet again for somebody to call Mass. and get an official answer. About 2 hours later, I get a call telling me that the Systems and Options book is wrong and that the Pageswapper article is right. She also requested the product manager to send a current list of products in the portfolio, which she then forwarded to me. She then thanked me for pointing out the error, and hoped that the next VAX Systems and Options book will be corrected. Since that is the third piece of incorrect information I had found in writing (the others were in apparently outdated SPDs in the Electronic Store), I have my doubts about it being fixed anytime soon. The only differences I see between the information in the previous note and the 'new' flier (number ED-30642-48 (c) 1987) is three additions to the RunTime Option Program Development Portfolio License (QZZDC-1P/QZZDC-JP): VAX ACMS Remote Access Option VAX LISP VAX OPS-5 Note that the VAX ACMS Remote Access Option is in addition to the existing VAX ACMS RTO mentioned in the previous note, it is not replacing it. Both names are given. Hope this information is of use to somebody else out there. Harry Herman Corpane Industries 10100 Bluegrass Parkway Louisville, KY 40299 (502) 491-4433 VAX-61 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 547.2 Software Development Portfolio Licenses 2 of 3 "Bill Mayhew" 15 lines 26-FEB-1988 10:29 -< When confusion reigns, it pours! >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 8 Number 6 (January, 1987) Just to make things a little more interesting... The Program Development Portfolios are also itemized in the "Official" U.S. Price List. I have the 12/28/87 version of that in front of me (to my knowledge the newest) and it indeed lists Notes and Teamdata as part of the base portfolio. It does not list any of the other three products as part of the runtime-only portfolio. The U.S. Price List has somewhat more standing as an "official" document than the SOC does. I, certainly, would have no compunctions about using any of the products that are listed, in the USPL, as being part of the Portfolio, if I bought the Portfolio. But I would, on the other hand, want to get some additional reassurance before I started to use a product that was _not_ listed in the USPL, e.g. a specific letter from at least the local sales manager authorizing it, which probably still would have no particular legal basis but would "help." Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-62 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 585.28 Anyone use defrag programs? 28 of 28 "Offline Submission" 15 lines 6-FEB-1988 22:01 -< Diskeeper cannot be as bad as you say >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 8 Number 9 (April, 1987) through Pageswapper Volume 9 Number 7 (February, 1988) I have used it on line in a batch mode with no problem. I started it on a badly fragmented disk, less than 20% free space, without doing a backup/restore and it cleaned it up. Cluster disks - no problem; even the cluster-wide system disk. So far, I am a satisfied customer. Jerry Taylor c/o Monsanto Chemical Company River Road Addyston, Ohio 45001 Telephone: (513) 467-2387 Date: January 26, 1988 ================================================================ Note 588.1Does BACKUP incremental restore have a problem? 1 of 1 "Bob Hassinger" 68 lines 1-FEB-1988 18:13 -< A response - problem confirmed - and in only a year!!! >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 8 Number 9 (April, 1987) Update - After working the problem with CSC for some time and getting them to confirm it they told my to submitted an SPR which I did (including a request to at least confirm or deny the problem, even if they could not provide a fix right away) on February 12, 1987. It was acknowledged in a reasonable amount of time as ICA-4265. When no response had been received by the Nashville Symposium I asked about the problem and SPR in the VAX Advanced Q&A session. The person answering for BACKUP said he had never heard of the problem or SPR but that he would be sure I got a response. (Later investigation indicates the SPR was received by the screening people at CSC on February 19th and sent on to VAX-63 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Engineering on March 4th - which they consider quite quick and only because of the previous efforts by phone confirming the problem.) Since then I have had a number of contacts with the SPR Administration people in Maynard and customer service people in Colorado, each promising to find out what the trouble was and, in the cases when they got back to me, returning the answer that it had been sent to Engineering, they had inquired about it with no response, and there was nothing more they could do. Now, in the last week or two when I had a conversation about other problems with the *Atlanta* support center and when I explained why I no longer considered submitting SPRs a viable way to get problems fixed they put me in contact with *their* customer assistance people (after I indicated I wanted the number for *corporate customer assistance* or I would just write a letter to Ken Olsen). This time I got action! Everyone up and down the line has been calling and today (Monday) I got a call from the engineering manager for BACKUP. He says *late Friday* was the FIRST time he had been aware of my SPR!!! He tells me this is a problem they were aware of independent of my SPR that has been recognized for a long time and that they intended to try to fix it in the first "functional" release after V5.0. (I take it that most likely means V5.2?) The indication is that if they can they would like to fix the failure-to-delete-directories problem as well as the failure-to-free-up-space-first problem at that point. We also had a nice chat about letting people know about the problem and available work-arounds. He indicated he thought he might let CSC know about the problem so they could "put it in their data base so users could see it". I told him about the fact DSIN has one data base and the specialists had another, larger one and the need to be sure it went in the data base the customers have access to. I also encouraged him to put it in the Dispatch for those who can not or do not look in DSIN regularly. In addition I encouraged him to document and publish in both places the work-arounds I found so that if others have the same problem they will know what to do. He agreed that those suggestions sound like good ideas that he would look into (!). VAX-64 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT I have no idea what finally got this thing unstuck and got me some response. Everyone agrees I did everything a customer can be expected to do and more. It might be that my company has been recognized as a rather strategic account recently or it might be that DEC really is trying harder to fix the badly broken SPR process now or maybe it was just dumb luck, stumbling onto someone who bothered to actually get the wheels turning. Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 704.14 Digi-Data Gigastore System 14 of 22 "Frank J. Nagy" 56 lines 12-FEB-1988 08:42 -< Gigastore Usage and Performance Report >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 2 (September, 1987) through Pageswapper Volume 9 Number 7 (February, 1988) We have been using Digi-Data "Gigastore" VHS-based tape drives since the middle of November for archival storage purposes on our LAVC. The Gigastores are connected to a pair of MicroVAX-IIs which are the boot and core nodes (each serves a pair of RA81s to the entire cluster). We experienced one initial problem common to both drives -- occasionally, BACKUP would fail in the middle of a save signalling a message like "device offline or not in configuration". Digi-Data shipped us a new drive which we swapped with the most-failure-prone drive of the two. Since we have done so (a few weeks ago) we have not seen a recurrence of this failure on either drive! Both drives are functioning well enough that we are now depending upon them for our system backups. We offer no explanation for the reason that such errors have abated from the formerly less-failure-prone drive (and, indeed, the second drive as well). VAX-65 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT We have 4 RA81s as system disk and user file store. A pair of RA81s is served by each of the core MicroVAX-IIs (each equipped with a Gigastore drive). A batch job runs at 3 AM and saves a pair of RA81s onto a cassette in each Gigastore; the system manager replaces the cassettes in the morning with a fresh set. Of course, we organized operations so the RA81s saved by a particular MicroVAX are those RA81s directly connected to that MicroVAX (thus eliminating any unnecessary Ethernet overhead). Discounting the files marked /NOBACKUP, we are currently saving about 360 MB to each of the Gigastores (total of roughly 720 MB in use). From MONITOR records made during running of these jobs, we find that the CPU utilization (on the MicroVAX-II) is in the range of 20-30%. The backups are done /NOCRC (in order to reduce loading on the MicroVAX.) We see the disk I/O rate averaging on the order of about 15 requests per second. This is in the middle of the night and the systems are otherwise idle. All this results in an effective useable I/O bandwidth to the Gigastore of about 60-65 KBytes/sec. (Digi-Data claims -- and there is no evidence to the contrary -- that the Gigastore is capable of sustaining 120 KBytes/sec). A test, saving all 4 RA81s to a single Gigastore cassette, saved 713 Megabytes in 3 hours and 9 minutes -- an effective rate of 64 KBytes/sec. The Gigastore is serving our basic needs even though we are a bit disappointed in the overall performance. BACKUP seems incapable of pumping data out fast enough for the Gigastore even though its usage of the CPU and disk are very modest. The Gigastore looks like a Pertec tape drive and is connected to a Dilog controller which emulates a TS11. A modified version of the standard TS11 driver is used as some timeouts in the software had to be adjusted. This is a bit of a concern and we are wondering what experience people are having with Exabyte systems on TMSCP controllers. Does anyone have experience with tape systems using the Exabyte drive which uses the 8 mm cassettes? The Exabyte system is claimed to run at 250 KBytes/second. What type of performance are you seeing? Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 VAX-66 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT (312)840-4935 ================================================================ Note 704.15 Digi-Data Gigastore System 15 of 22 "John Osudar" 20 lines 12-FEB-1988 20:49 -< So far, so good >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 2 (September, 1987) through Pageswapper Volume 9 Number 7 (February, 1988) Our Gigastore has been in use for about two months now. In early January, we used the Gigastore for a "production" backup for the first time -- backed up all three of our user disks (RP07, 2xRA81) and two others (RA81, RM05) with no problems. The user disks all fit onto one tape, no telling how much room to spare -- but we did these backups on a 785 using the default /CRC and /GROUP settings, and still got about 1.3Gb of real data onto the tape. (I was cautious and did a verify pass, so each backup/verify took about 4 hours.) In early February, I got really brave and did both a backup and a compress for each user disk. Total time, about 6 hours per disk; again, no problems. I found that the amount of time it takes to back up a disk depends greatly upon the degree of disk fragmentation -- e.g. our least full, but most fragmented disk took considerably longer to back up than our fullest disk. Still fit all three user disks onto a single tape. (And I haven't had to come in to work for a sixteen-hour Saturday backup marathon since December! :-) We haven't had the problems that Frank ran into. I saw one "device offline or not in configuration" message, but it occurred after the system had crashed with a tape in the Gigastore, and not at load point. Rewinding the tape fixed the problem. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-67 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 704.16 Digi-Data Gigastore System 16 of 22 "Harry Herman" 13 lines 20-FEB-1988 16:33 -< Another request for Exabyte info. >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 2 (September, 1987) through Pageswapper Volume 9 Number 7 (February, 1988) In addition to Frank Nagy (the writer of .14), we are also considering purchasing an Exabyte system, due to it using SCSI, being proposed as an ANSI standard, and its 5 1/4" form factor. I am also told there is another company that is starting to sell another 8-mm drive that is supposed to be compatible with the Exabyte drive. Has anybody out there used Exabyte's drive at all? If so, how well does it perform? Does it need custom patched device drivers to run (like the Digi-Data system does)? Any problems with defective units? I appreciate any feedback you can provide. Harry Herman Corpane Industries 10100 Bluegrass Parkway Louisville, KY 40299 (502) 491-4433 ================================================================ Note 704.17 Digi-Data Gigastore System 17 of 22 "Kevin Angley" 18 lines 22-FEB-1988 16:10 -< Yet another request for Exabyte info >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 2 (September, 1987) through Pageswapper Volume 9 Number 7 (February, 1988) I, too, am considering a helical scan technology drive and would appreciate any info that people have gathered. VAX-68 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT As far as the Exabyte drive is concerned, there are some nice articles in January 88 Hardcopy. The Exabyte drive is not available directly but through OEM's such as Aviv, Summus, Contempory Cybernetics, etc. - each with a different twist. I kind of think I like the Exabyte over the VHS because 1) the media is more compact, 2) even though the drive itself is single sourced, there are several sources for the complete package, and 3) at least there is a chance that it may evolve into a standard. Frank - if you had it to do over again, would you do Digi-data or VHS? Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 704.18 Digi-Data Gigastore System 18 of 22 "Frank J. Nagy" 18 lines 23-FEB-1988 08:00 -< If we had to do it again... >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 2 (September, 1987) through Pageswapper Volume 9 Number 7 (February, 1988) > > Frank - if you had it to do over again, would you do Digi-data > or VHS? I think we would go with the Exabyte/8mm over the DigiData/VHS with a TMSCP controller in order to be compatible with a Digital driver. One worry we have about the Exabyte on a MicroVAX-II is that since the rated speed of the drive is 256 KBytes/second and our measurements show BACKUP putting out 60-70 KBytes/second, will we only be able to use 1/4 of the tape capacity (i.e., 600 MB or so) due to the tape streaming and writing placeholder records on the tape. As is, with the Gigastore, we figure we are only able to use about 1/2 of the tape capacity (about 1.2 GBytes) due to this same problem. VAX-69 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT These are the sort of questions I'm looking for answers from 8mm users: is it truly compatible with the TUDRIVER? Are you getting the full tape capacity or only a small (25%) fraction of it due to the streaming (on a MicroVAX-II, please note)? Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 704.21 Digi-Data Gigastore System 21 of 22 "John Osudar" 8 lines 24-FEB-1988 19:23 ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 2 (September, 1987) through Pageswapper Volume 9 Number 7 (February, 1988) I'd like to second what Frank said. Although our Gigastore has been OK (and with a 785 all to itself, it seems to get about 60% to 65% of rated capacity), if we had waited four or five months longer (i.e. until now) we'd probably go 8mm. But we're looking for an 8mm tape backup that will get full capacity (or close to it) regardless of how fast you feed it data -- our 785 can't keep up with the Gigastore, and we're likely to "upgrade" soon to a couple of 8350's, which, of course, are slower CPU's than the 785. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-70 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 777.1 Datatrieve Plots on LXY 1 of 1 "George Bone" 6 lines 12-FEB-1988 10:35 -< VAXLIB HAS IT NOW! >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 5 (December, 1987) There is software available on a VAXLIB tape that will do that. Unfortunately, I can't seem to find my catalog right now, but when I do, I'll put the program name down. We have tried it (a little) and it looks like it works okay, but have had too much to do to really work on it. I'll get back to you or you can call me at (707)646-2531 between 06:30 and 17:00 west coast time, M-F. George Bone Code 2301.2 Mail Stop T-11 Mare Island Naval Shipyard Vallejo, CA 94592-5100 (707)646-2531 ================================================================ Note 820.7 Foreign Disk Comments 7 of 8 "Offline Submission" 19 lines 6-FEB-1988 22:00 -< An Emulex Fan >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 6 (January, 1988) I love my Emulex equipment. I've had Fuji Eagles running on a V-master controller emulating RP06's for over 5 years. 24/7 and no failures. The secret is the RP06 emulation. It does not use a patched driver, and I have been able to make all VMS updates, including 3.7 to 4.0 with no problems. I just bought the Emulex SMDI controller that makes other disks look like RA series. I've only had it a month, but with disks connected to an HSC50 or a KDB50 (BI bus) everything is working fine. Jerry Taylor c/o Monsanto Chemical Company River Road Addyston, Ohio 45001 VAX-71 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Telephone: (513) 467-2387 Date: January 26, 1988 ================================================================ Note 820.8 Foreign Disk Comments 8 of 8 "Terry Kennedy" 34 lines 7-FEB-1988 18:54 -< If you don't mind giving up the space... >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 6 (January, 1988) > The secret is the RP06 emulation. It does not use a patched... This is what I had with my Emulex subsystem (SC31 w/ M2351A). However, having to give up a sizable percentage of the disk capacity to make 2 RP06's was rather distressing. If you can live with the loss of space, it should be fine. Recently, I beat up on Emulex to swap my SC31 for the 'latest', a UD33, which does MSCP emulation. I discovered some interesting new problems you might like to hear about: o The UD33 reports garbage for controller hardware and firmware revision levels. If your OS ever starts enforcing minimum acceptable revision levels, this board will *stop working*. o Despite the fact that the board prompts you to enter a drive serial number during formatting, the number emitted to the host is a constant, *not* the number you supplied. o The board (unlike the SC31), does not come with a boot PROM. If you have a PDP-11 or a VAX 750, you'll have to order the PROM from DEC spare parts. o Most seriously, the board has bus loading problems. In some slots of an empty backplane, it works. In others it doesn't. Replacing the CPU's bus drive module seems to help. On the plus side, it is a good deal faster (with the same drive) as the SC31. However, this may be due mainly to the differences between MSCP and the RP protocols, and not anything to praise Emulex about. VAX-72 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 849.5 MicroVAX 2000's serial line expander "arrives" 5 of 8 "Bill Mayhew" 7 lines 2-FEB-1988 13:01 -< Conflicting information >- ---------------------------------------------------------------- Very interesting... the announcement info on the DHT32-AA showed up today, finally, and it says that the DHT32 is "application-compatible" with the DHV/DHQ11; and that the user can expect "approximately" the same performance on a 2000/DHT32 as on a II/DHV or II/DHQ; but that the DHT does NOT do DMA...! Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 849.6 MicroVAX 2000's serial line expander "arrives" 6 of 8 "Jack Patteeuw" 20 lines 2-FEB-1988 17:40 -< 1-800-332-3366 >- ---------------------------------------------------------------- Check the Electronic Store ! I'm almost certain that it said there that is does do DMA but no modem control was included. By the way, DEC was showing a DHB32 16 channel async multiplexer for BI bus machines at Anaheim but no one at my local office could find out anything for me. Turns out this board (which is functionally equivalent to a DHU11, ie. 16 RS232 ports with full modem control **OR** 14 DEC423 and 2 RS232 w/modem control) is designed/built by the Computer Special Service (CSS) in Digital. These guys don't do high volume stuff and I guess they didn't have all their t's crossed and I's dotted so the big boys wouldn't let them release the card yet. VAX-73 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT By the way, DEC's marketing people are getting smarter (and we loose). The cost compared to a DHU11 is 50% more (for the same function, just different bus) but very close to what 2 DECserver 200's would cost ! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 849.7 MicroVAX 2000's serial line expander "arrives" 7 of 8 "Bob McCormick" 28 lines 18-FEB-1988 11:14 -< More DHT32 and µVAX 2000 info >- ---------------------------------------------------------------- What I know about the DHT32... Its a small card that you stuff in the 2000 box in the cramped area where memory expansion and ethernet live. You can have the DHT 8 line multiplexer or the (program announced) sync interface, but not both. The DHT provides 8 DECconnect style lines, through the harmonica H3104 and cable - same as with the DECserver 200/DL and appropriate DHQ11 cab kits. You can't install a DHT in a 'old' 2000 box -- the original units did not come standard with the expansion adaptor, which is a $1,200 option now included on _ALL_ 2000 configurations. This box is required to cable from the interface module to the FCC certified cable bulkhead. If you're not witty and good at mechanics I suggest you take caution when taking apart a 2000 box with the expansion adaptor. Its really tight with cables (lengths), and which screws you should/shouldn't remove! As for DMA, don't know [didn't care, either!] But you should be aware that SYSGEN works differently with the 2000, which has no spine (bus) -- I believe the ROMs upon boot set up a structure which is read by AUTOCONFIGURE/ALL ... You'll notice this when you don't have your TK50Z or external disk connected, and try to connect after boot time (sorry, charlie!) VAX-74 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Its a neat little box! BOB MCCORMICK 39 FORGE ST FEEDING HILLS MA 01030 ================================================================ Note 866.52 VMS 4.7 is here! 52 of 65 "Larry Kilgallen" 0 lines 29-JAN-1988 14:12 -< VMS V4.7 Microfiche arrived in Boston today >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 876.1 Anyone with experience with MOBIUS? 1 of 1 "Lisa Pokel" 57 lines 18-FEB-1988 08:27 -< Some notes on Mobius vs. RAF >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) I have used both Mobius & RAF on an IBM PC/AT connected to a VAX 11/750 (asynchronous @9600). My notes are over a year old so note that I am referring to V2.0 (Mobius) and V1.6 (RAF). Neither is real speedy on file transfers going asynchronous. It is kind of like running off of floppies. Both are handy for mapping DOS directory structures to VMS structures, although they each handle that differently. RAF maps subdirectories as subdirectories; to get at subs with Mobius you must define them as a disk drive (you can define up to 26 drives and this can be done in a startup command file when you start up the host process on the VAX). Both require a process to be running on the VAX to enable file transfers from the PC; one bug that existed with RAF was if the VAX server was not running and you tried to access one of the pseudo-drives it would hang the PC. RAF did seem faster on file transfers to the host. VAX-75 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT RAF's VT100 emulator was better than the one with Mobius; you don't have to keep hitting CTRL-W to refresh in EDT. It wasn't perfect; one downside is that if you have any printer port programs those escape sequences were totally ignored and the file would display on your screen. Mobius does turn on the printer, but as I recall it did something weird like double space everything (this is one area that I have found A LOT of VT100 emulators fall short; not a biggie, I suppose, but still an annoyance if you are used to generating listings off of your terminal). More notes (in no particular order): - RAF created text files on the VAX that are readable from DCL (under Mobius you must TEXTIFY them to 7 bit). - RAF supports up to 16 drives (vs. 26 for MOB) and you can't redefine A-C (which can be a problem for some old programs insisting on files from the floppies). - RAF is copy-protected (MOB isn't). - RAF did not have color support, although I believe the new version does. - Disconnect from the RAF server was kludgy (hitting 6 CTRL-C's vs. a QUIT command under MOB). - MOB has a mechanism for setting the micro's clock (synching you with the VAX). - MOB has disk logging capability (RAF didn't). - Both programs are TSR's; MOB has a NOMOBIUS program to deinstall it but RAF did not provide that feature. Of course if you have a stack management program for the PC you can do it yourself. The main plus that I noted with RAF was the VAX directory mapping (you can even do a TREE/F on the VAX and can also CD up and down). I found Mobius handy for creating command files to backup software that I was developing on the PC to the correct VAX directories; obvious the same could be accomplished with RAF. I purchased Mobius although I am still keeping tabs on RAF (I have noted that 1-2 terminal emulation packages have now claimed that they work with RAF which would be a way around some of the VT100 shortcomings). I hope this is of some help. VAX-76 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Lisa Pokel AM Multigraphics 1800 W Central Road Mount Prospect IL 60056 ================================================================ Note 882.11 Diarrhea of the Modem and SET HOST/DTE 11 of 18 "Terry Kennedy" 15 lines 19-FEB-1988 18:36 -< Use SET TERMINAL/PERMANENT/XON >- ---------------------------------------------------------------- > What seems to be really happening is that the port gets an XOFF > (control-S), but never receives an XON (control-Q). The > solution I tried at first was to use a program I wrote some time > ago that did a $FORCEX (force exit) on the process. That got > the process freed up, but the port was still in a wait state. If you're running VMS 4.x (presumably you are), you can use the undocumented, unsupported command: SET TERMINAL/PERMANENT/XON ddcu: which fakes the driver into thinking that a ^Q has come in, which should unwedge the port. You do need some privilege or other to issue the command, as the /PERMANENT part is required. Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 885.5 VAX DEBUG V4.6-9 Bug on VAX 8550 Processors 5 of 6 "Bill Mayhew" 12 lines 2-FEB-1988 13:13 ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) Re: .1 (exam/ascii bug) Got a reply on DSIN, within about 4 work days of logging the call, confirming that this is a known problem that will be "fixed in the proverbial next release of DEBUG." VAX-77 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Stupidly, I did not ask what the relationship was between the next release of DEBUG and the next release of VMS. The reply was signed by one of DSIN's busier software support specialists, as follows: Regards, I did not report, and have no info on, the bug in .0 however. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 885.6 VAX DEBUG V4.6-9 Bug on VAX 8550 Processors 6 of 6 "Kevin Angley" 2 lines 3-FEB-1988 10:59 -< DEBUG 4.7 >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) There is a patch to DEBUG for version 4.7, but the only bug they claim to fix is control-Y handling. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 VAX-78 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 886.0 Privileged queues? 13 replies "Terry Kennedy" 19 lines 22-JAN-1988 23:44 ---------------------------------------------------------------- Is there an easy way to disallow entry of print jobs to a particular queue? I've tried to discover this in the documentation, but have had no luck. Here is what I have tried/thought about: 1) ACL on the queue manager workfile - no good as it applies to ALL queues. 2) ACL on physical output device - no good as jobs could still be entered but not executed. Also may have problems because might check the print symbiont's access rather than the submitters. RSTS has the ability to require the user to have a particular privilege to create entries in a queue. I thought VMS might have something similar, but it appears not to from my look at the manuals. I'm sure I'm missing something simple and obvious, though... Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 886.5 Privileged queues? 5 of 13 "Chris Erskine" 2 lines 5-FEB-1988 07:32 -< This is what compilers are for >- ---------------------------------------------------------------- You could roll your own print command which does the checking first, set UIC and then put file in the queue. Chris Erskine 23 S Holcomb Clarkston, MI 48016 (313) 524-8836 VAX-79 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 886.6 Privileged queues? 6 of 13 "Terry Kennedy" 39 lines 5-FEB-1988 22:58 -< Arrrrrgggggghhhhhhh! Flames ahead! >- ---------------------------------------------------------------- > This is what compilers are for No, this is what operating systems are for! I am unsure what (besides a 32-bit virtual address space, which wasn't the operating system's doing after all) the bloat of VMS does for me. > You could roll your own print command which does the checking > first, set UIC and then put file in the queue. 1) Several problems - first, whatever I do has to work for ALL users without breaking such things as existing .COM files (such as VMSINSTAL). It has to prevent users from using the 'real' system print command (remember, that was the original request?). Next, it has to be simple, yet work on several releases of VMS at several sites. 2) One would expect this sort of functionality from an advanced oper ating system like VMS. I will have to put this on my list of 'reasons I'd rather not deal with VMS, which currently reads as follows (in part): o *NO* group account management facility to speak of. As an example, on RSTS you can give a faculty member the GACNT privilege, and they can create/delete multiple accounts with a single, simple DCL command. o *NO* functional session logging facility. Again, RSTS has it. Yes, I know about SET HOST 0/LOG and @TT:, but both have serious limitations. o A truly brain-dead print/batch services implementation. There are too many examples to list, but my original question is a good case. VAX-80 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT I'm really not trying to ram RSTS down your throats as a shining example. It's just that coming from a cramped 16-bit 32K environment to a VAX, one expects things to get better, or at least stay the same. Sure, all of this could be addressed by suitable programming the point is that it shouldn't have to be! Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 886.7 Privileged queues? 7 of 13 "Larry Kilgallen" 27 lines 6-FEB-1988 01:08 -< How did VMS get that way? >- ---------------------------------------------------------------- Terry is certainly right in saying that is what operating systems are for. There are deficiencies. That is what DECUS is for -- to lobby DEC to fix it. On the other hand, DECUS is also for sharing ideas on how to surmount existing obstacles, and I would not want to discourage that sort of interchange to keep things going while DEC gets their act together. Now, how did VMS get that way? Coming from TOPS-10, I was horrified to see what passed for Batch/Print in VMS V1. Terry, if you think what is available today is deficient, you should have seen it when... But enough of that. How did a company which know how to do better manage to start off with such a pathetic Batch/Print system? Folklore has it that when somebody at DEC said "32-bit" there were raised clenched fists from RSTS developers saying "16-bits forever", and even at DECUS symposia there are T-shirts that say "36-bits forever". So VMS came out looking like RSX. I hope we will all be wiser when someone from DEC in the future heralds our future by whispering "57.5 bits", or whatever totally unnecessary proposal might be brought up as a purported successor to what will no doubt by then be a perfect VMS environment. Larry Kilgallen Box 81, MIT Station VAX-81 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Cambridge, MA 02139-0901 ================================================================ Note 886.8 Privileged queues? 8 of 13 "Terry Kennedy" 60 lines 6-FEB-1988 03:34 -< Watch out - this is a long one! >- ---------------------------------------------------------------- Well, I have this idea... Back when you were using your favorite 16-bit DEC operating system, chances are there was a good deal of similarity between your use of the system and XYZ's use of the same operating system at their site. DEC encouraged a wide variety of PDP-11 operating systems, each targeted at a particular area. Sure, some are no longer around, and others may have changed focus, but the statement still holds. Now, with the VAX, DEC has generated a 'standard' environment in VMS, targeted to appeal to a wide variety of user types. The problem is, this makes certain system area inefficient or just plain unusable for some users. These users justly vote improvements to these items on the SIR. However, the parts of the system which are just *slightly* a pain in the %^& to *all* the users don't make it up to the top, because most of the users have something more important to vote on. This is compounded by the legions of DEC people coding for VMS. Trying to find the right person to ask a question of is becoming more and more impossible ["technical Q&A", anyone?]. At least in the 16-bit area, where there are fewer people involved, you can actually find someone to answer your question (and possibly implement a fix). As an example, I asked for a feature in RSTS to beep the terminal when a user autobauds at LOGIN time [See, there *are* things I admire in VMS!]. Total time from my suggestion to the feature appearing in an official release: less than 6 months. To contrast this, I asked VMS development about a VMS LOGINOUT bug, where if user A dials in, gets to the Username: prompt, types ^S, and hangs up, the next user to dial in on the same port is greeted with dead air. The closest I came to an answer was a comment that "we cannot address this problem as some users may depend on this feature." Depend on something being unpredictable and broken? Give me a break! [This came from a developer at Nashville, not an SPR answer. Apparently some of the really stupid answers *do* come from developers!] VAX-82 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT I have a suggestion, but I don't think it will ever happen due to inertia (mainly DEC's). There are three ways changes (other than bug fixes) are planned for a product: 1) Loud, vocal request from the users (SIR, etc.) 2) By implementing DEC's strategic plans for the product. 3) Ideas added by the developers Now, I'm not saying that developer's ideas aren't valid, or that they should be ignored. I also know that some amount of 'fun' is necessary to keep talented programmers around. However, if the developers paid more attention to 1, then they might find that 2 would follow along naturally. Perhaps we could vote on the developer's items before they are actually implemented in the system. Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 886.9 Privileged queues? 9 of 13 "Larry Kilgallen" 88 lines 6-FEB-1988 09:51 -< Improving Feature Addition Responsiveness >- ---------------------------------------------------------------- The point about narrow-purpose operating systems having the capability to be more responsive to change is certainly a good one. I think it points up the need for considerable improvement in the SIR/SPR handling area. Let me list a few things I consider necessary for this: 1. DEC must get their SPR act together. Given the time it takes to get a wrong answer to a serious bug, does anyone *really* believe that suggestion SPR's have a chance? If they do have a chance, then let's get some better responses to suggestion SPR's. The current ones all seem to have been written by a lawyer. It is possible to not be bland and still not commit the corporation. Let's get some *feedback*, such as "All the developers think it's VAX-83 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT a neat idea, but time doesn't permit us to put it in for at least 3 minor versions.", "We have problems doing this because of the security impact" (that is the answer they gave about simple project accounting, indicating they had a more complicated way in mind but that it will take longer). It is not like it will take tremendous effort to compose these answer -- typically they already exist. If you ask Keith Walls at a Symposium why Backup does not do X, he really knows the answer, does a quick mental calculation, and can give a good approximation as to the chances of it happening in the forseeable future. The problem is, how does DEC internally provide these quality answers and still leave Keith time to code. That is a subject too long for inclusion in this topic, but it is critical. Now this will not directly address sheer inertia matters, such as the release cycle time, but few ideas are that startling. Terry, somebody else may have previously thought of a bell on autobaud for RSTS but not been in a position to put it into the proper channel. If a reasonable (not the current) pipeline delay were there starting with the "first" time a given suggestion were made, it would still be a tremendous improvement. 2. DECUS needs to refine its feedback mechanisms A few of the VMS developers on Friday night in Anaheim said they have a problem with not having enough background on *why* a particular SIR has reached the Top 10. Knowing that people want timestamps in their batch log just gives them a chance to implement a point-feature without an overall design. If they want timestamps because TOPS-10 had them, that is important information because perhaps there is something else in the TOPS-10 batch area they need to consider. If, on the other hand, the votes for timestamps were because some branch of the Federal government is requiring it for their in-house VAX machines, then *that* is important to know so that DEC can get a copy of that Federal regulation to learn what the *next* SIR down the pike will be. Not that they would necessarily go VAX-84 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT off and implement number 2 immediately (especially if it would slow down number 1), but at least they would be able to schedule number 2 to coincide with when somebody was changing that part of VMS anyway. The major reason the developers expressed for needing more information about SIRs, however, was that DEC may be working on some feature (which they want to keep secret until release) which could benefit from better understanding of how people use computers in the field. To understand *why* people want feature X helps DEC to better integrate the features. I am afraid we will never reach the point where my marvelous suggestions will be implemented in VMS in less than six months. My unique ideas, however, so often provoke developer responses that "yes, we have heard that from a lot of people", that I would be resigned to be happy if they made it in 9 months after the "first" person suggested the idea to DEC. It would be disappointing, however, to never be able to think of a capability which was missing. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 886.10 Privileged queues? 10 of 13 "JEFF KILLEEN" 22 lines 6-FEB-1988 13:37 -< CUTLER'S BABY >- ---------------------------------------------------------------- > But enough of that. How did a company which know how to do > better manage to start off with such a pathetic Batch/Print > system? Folklore has it that when somebody at DEC said "32-bit" > there were raised clenched fists from RSTS developers saying > "16-bits forever", and even at DECUS symposia there are T-shirts > that say "36-bits forever". So VMS came out looking like RSX. No! - the truth is VMS is David N.#Cutler's baby - and the project team was a closed group. That is the Cutler of RSX-18 and RSX-11 fame - and Cutler only seems to know how to write one type of O/S. Rumor has it you pick up an RSX-18 system service manual you feel like you are reading VMS system service calls. Mark Bramhall, the senior RSTS architect, left RSTS for VMS VAX-85 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT right after VMS V1 and found a very bad case of not invented here think. Peter Conklin was part of the original VMS team. Peter was from the 10/20 world. I like Terry am going through the pain of moving from the RSTS world to the VMS world. The VMS kernel is a better architected system then RSTS however the user friendly polish on the utilities is poor when compared to RSTS. JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 ================================================================ Note 886.11 Privileged queues? 11 of 13 "Seton Droppers, PBS, (703)739-5100" 27 lines 6-FEB-1988 13:51 -< VMS: Use != Design? >- ---------------------------------------------------------------- I got the impression, when I first learned VMS (2.x) that VAX/VMS was considered a follow on to the 11 series (11/7xx, looks a lot like 11/xx, after all), and NOT a mainframe system, and not something to replace the 10s, 20s, and TOPS with. I even seem to remember that a lot of people got real upset when DEC canned the 10s,20s and TOPS. It appears that the original VMS was never designed for what it is currently being used for, and never meant to be used with as BIG a system as it now can be. This feeling was reinforced at Nashville where one of the futures speakers noted that the whole concept of VMS and crashes was going to have to be redone since it was designed when no one could envision a physical address space bigger than eight mega-bytes. That VMS can do all that it can is amazing to me. (Oh yes, I certainly think some of the VMS/DCL commands make a lot more sense than some of the RSTS commands I used - COPY makes a lot more sense to me than PIP... but then RSTS may have changed since V6) Seton R. Droppers Public Broadcasting Service 1320 Braddock Place Alexandria, VA 22314 (703)739-5100 VAX-86 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 888.3 Another SPR classic 3 of 4 "Kevin Angley" 23 lines 29-JAN-1988 13:53 -< Every lock that ain't locked when no one's around >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) I asked that my SPR be elevated so that I could get a more intelligent response, and I did... "Bob" called and said that GETDVI works fine, even on a cluster, except for a few things (as we suspected, of course). The particular problem that I was having was that the status of a volume shadow member was coming back as copy complete when in fact other nodes thought the shadow copy was still in progress (when viewed by GETDVI). So, subsequent mount attempts failed. This, it seems, is really the same problem that GETDVI's opinion of mount status isn't correct with respect to whether other nodes have completed a dismount or not. So that makes sense. But it still doesn't solve the real bug that GETDVI ought to be consistent across a cluster with respect to cluster devices - just like SHO DEVICES is - but of course it is obvious that DEC's command to sho device information would not use the system service for getting device information. Enroute to looking up how SHOW DEVICE worked .. I discovered that defining logicals SHOW$DEBUG and SHOW$DEBUG_LCKBUF gave an interesting display for show devices. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 VAX-87 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 888.4 Another SPR classic 4 of 4 "Alan B. Hunt" 9 lines 5-FEB-1988 13:10 -< Problem with tape drives too. >- ---------------------------------------------------------------- Antecedent IO(s) published in: Pageswapper Volume 9 Number 8 (March, 1988) I SPR'ed this during VMS V4.1/4.2 days because I wanted to use F$GETDVI to determine if a tape drive was allocated in a cluster. Turns out it tells you only if it is allocated on the same machine. However, SHOW DEVICE MU will tell you which machine. They said it wasn't a bug but enough complaints had been received that they were looking at changing it but no promises. To me this is a bad bug and a real headache. Their idea of bugs and ours seem to differ radically at times. ALAN B. HUNT 26803 BERG RD. #301 SOUTHFIELD, MI 48034 ================================================================ Note 898.2 ANY INGRES USERS OUT THERE??? 2 of 2 "Bob Huckins" 10 lines 11-FEB-1988 18:26 -< Not personally, but... >- ---------------------------------------------------------------- I don't use Ingres personally, but our company (Nuclear Data) does sell several products based on it. It has lots of good capability, but from what I can tell, some of the 4th-GL functionality is overstated. The people developing our products almost always had to write a program to do what they wanted, due to either performance or functionality considerations. Supposedly, gobs of development time was saved in forms and journaling development. There is a very active Ingres users group, sponsored by RTI. If you ask you local RTI representative, they will put you on the mailing list. Bob Huckins Nuclear Data Instrumentation Div. Golf & Meacham Rds. VAX-88 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT Schaumburg, IL 60196 312-884-3659 ================================================================ Note 900.0 Asynch DECnet on MicroVAX 2000 9 replies "Thomas P. Berk" 5 lines 9-FEB-1988 15:14 ---------------------------------------------------------------- I've been trying to set up asynchronous DECnet between a 750 and a MicroVAX 2000. I haven't been having much luck. I've been working with DEC, and they suspect some problem in the RS423 serial communications on the MicroVAX 2000. Has anybody out there had any luck setting up asynchronous DECnet using a MicroVAX 2000? Thomas P. Berk Inter-Tel Incorporated 6505 W Chandler Blvd Chandler, AZ 85226 602-961-9000 ================================================================ Note 900.1 Asynch DECnet on MicroVAX 2000 1 of 9 "Jonathan M. Prigot" 10 lines 10-FEB-1988 10:22 -< VS2000 <--> 8250 >- ---------------------------------------------------------------- Before I babble on too much, what are the symptoms? I'm not exactly sure how much good this will do, but we use async DECnet between a VAXstation 2000 and our 8250. We 'borrowed' the DECnet components from the 8250, and run it over the RS232 port on the VS 2000. One sneaky thing that bit us is having to specify TRANSMIT PASSWORD (on the 2000) and RECEIVE PASSWORD (on the 8250) before things cranked up (circuits went from ON-STARTING to ON). (Sneaky, because I don't remember this being enforced with earlier versions of VMS V4.x). Jonathan M. Prigot W.R. Grace & Company 55 Hayden Avenue Lexington, MA 02173 617-861-6600 x2148 VAX-89 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 900.2 Asynch DECnet on MicroVAX 2000 2 of 9 "Bill Mayhew" 16 lines 10-FEB-1988 21:13 -< More success, may not be totally germane >- ---------------------------------------------------------------- We, too, run async DECnet between a VAXstation 2000 and, in our case, a 785. Dynamic async DECnet, in fact. Same caveat re: transmit and receive passwords. Possibly our success, and .1's, may not be relevant to .0 since we're both using the RS232 port, not the DEC423 port that .0 is trying. I do, however, have a second (static) async circuit set up between my VS2000 and a MicroPDP-11/73 running DECnet/RSX. In this case, I'm using the VS2000's "printer" port, thru an H8571 9-pin-to-DEC423 converter, through a DECconnect cable, thru a DEC423-to-male-RS232 converter, thru a BC22D null modem cable, to the PDP. No problems except that we've had some strong static discharges in the immediate vicinity of the BC22D shut down the circuit (actually they typically halt or crash the 11/73, which makes the 2000 think the circuit went down). Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 900.3 Asynch DECnet on MicroVAX 2000 3 of 9 "Thomas P. Berk" 10 lines 11-FEB-1988 09:31 -< More details >- ---------------------------------------------------------------- Everything seems to go pretty well until we actually try to bring up the circuit. It seems do come up momentarily, and then aborts because of a line error (I don't recall the exact error). I have specified the receive and transmit passwords on both machines, and it appears to be getting past that stage. VAX-90 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT From what I've heard so far, it sounds like the problem has to do with the 423 ports on the MicroVAX. DEC has been pretty sluggish in responding, so my guess is that the problem is real. Thomas P. Berk Inter-Tel Incorporated 6505 W Chandler Blvd Chandler, AZ 85226 602-961-9000 ================================================================ Note 900.9 Asynch DECnet on MicroVAX 2000 9 of 9 "Thomas P. Berk" 20 lines 21-FEB-1988 12:00 -< ...but I swear it didn't work... >- ---------------------------------------------------------------- DEC actually came out to my site to investigate the problem a couple of days ago. They were armed with a data scope, and they even brought a couple of extra people along to observe. Believe it or not, when I actually went to set up the situation so that they could set up their scope, the damned thing went and worked perfectly. Of course, as long as things worked, there was no point in hooking up their fancy equipment. Needless to say, I felt more than a little foolish. I'm reasonably sure that I did everything exactly the same, so all I can say is that there must be some borderline conditions (phase of the moon, sun spots, etc.) that make it fail sometimes. DEC still has a couple of sites reporting a similar problem. It turns out that since we're going to be using modem communications, we'll be using the one RS232 port anyway, and it works flawlessly. Thomas P. Berk Inter-Tel Incorporated 6505 W Chandler Blvd Chandler, AZ 85226 602-961-9000 VAX-91 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 902.0 TA78/TU78X problems..... 5 replies "Robert Gerber" 10 lines 11-FEB-1988 10:02 ---------------------------------------------------------------- Does anyone know of any problems with the new circuitry that DEC is putting in some of the TU/TA78's in the field. DEC upgraded our TA78 and put a 'TU78X' sticker on it. We are having intermittent machine checks on our 8600 when using the upgraded tape drive (They may not be related...but you never know.....) The TA78 is connected to an HSC50. Our other systems (785,8700) seem to have no problem with the drive.) Robert Gerber Gillette Co Tech Services Dept 4U-3 1 Gillette Park Boston, MA 02106 617/463-3636 ================================================================ Note 902.2 TA78/TU78X problems..... 2 of 5 "Dale E. Coy (505) 667-3270" 8 lines 11-FEB-1988 23:09 -< No way >- ---------------------------------------------------------------- I can't see any way that a TA-78 hanging on an HSC-50 could cause machine checks in anything past the HSC-50 (and probably not that, either). Even if they changed the "firmware" in the HSC (and I haven't heard about that), the connection between the HSC and the rest of the "nodes" is essentially a software connection. Maybe system crashes, but if you're truly seeing machine checks I don't think it could be the TA-78X. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 VAX-92 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 902.4 TA78/TU78X problems..... 4 of 5 "Brian Tillman, Smiths Industries." 9 lines 15-FEB-1988 16:18 -< A TA79 by any other name... >- ---------------------------------------------------------------- RE: < Note 902.3 by NODE::US178326 "GREG P. SCHULZ" > -< TA78 or TA79 >- > Ask your field service representative but the upgrade may be a > part of the upgrade to the TA79 less the name... The field changes made to a TA78 do not make it a TA79, although some of the changes are incorporated into the TA79. There is more to the TA79 than just the FCOs. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 910.0 Western Data Comm - Vadic 4224 4 replies "Brian Tillman, Smiths Industries." 3 lines 19-FEB-1988 11:28 ---------------------------------------------------------------- Has anyone out there used Western Data Comm line guards with Vadic 4224e modems for dialback security? If so, do they seem reliable to you? Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-93 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 910.1 Western Data Comm - Vadic 4224 1 of 4 "Rytis T. Balciunas" 10 lines 20-FEB-1988 10:09 -< Vadic does not work with Western Datacomm >- ---------------------------------------------------------------- We use Western Datacomm 424 modems with Western Datacomm Lineguard 3060 dial-back security system and Western Datacomm 1801 dialer in a Racal-Vadic 1600 chassis. Racal-Vadic modems DO NOT work with the Western Datacomm dialer....Found this gem out two years ago... Other than that, the system is solid as a rock for us - NO FAILURES TWO YEARS. Works out really nice for restricting phone access to our VAXen... RYTIS T. BALCIUNAS CALGON CARBON CORPORATION PO BOX 717 PITTSBURGH PA 15230-0717 (412)787-6784 ================================================================ Note 910.2 Western Data Comm - Vadic 4224 2 of 4 "Chris Erskine" 2 lines 22-FEB-1988 08:06 -< Vadic DOES work >- ---------------------------------------------------------------- We have the 306x systems with Racal-Vadic modems installed at several locations and have not had problems. Chris Erskine 23 S Holcomb Clarkston, MI 48016 (313) 524-8836 VAX-94 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 910.3 Western Data Comm - Vadic 4224 3 of 4 "Brian Tillman, Smiths Industries." 13 lines 22-FEB-1988 11:07 -< It DOES work, but... >- ---------------------------------------------------------------- RE: < Note 910.1 by NODE::US198418 "Rytis T. Balciunas" > -< Vadic does not work with Western Datacomm >- > We use Western Datacomm 424 modems with Western Datacomm > Lineguard 3060 dial-back security system and Western Datacomm > 1801 dialer in a Racal-Vadic 1600 chassis. Racal-Vadic modems > DO NOT work with the Western Datacomm dialer.... But they DO work. Ours work, but there seems to be a problem in the lineguard that only allow two numbers to be entered at the moment. I spoke with someone else, too, who has this setup that works as expected. Ours is just a lemon, apparently, which we are going to get the dealer to replace. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 910.4 Western Data Comm - Vadic 4224 4 of 4 "Rytis T. Balciunas" 3 lines 25-FEB-1988 07:48 -< 2 cents' worth >- ---------------------------------------------------------------- My, how things have changed in two years --- Western Datacomm people were the ones that finally admitted to us that the Vadics did not work at the time (late 1985).... RYTIS T. BALCIUNAS CALGON CARBON CORPORATION PO BOX 717 PITTSBURGH PA 15230-0717 (412)787-6784 VAX-95 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 911.0 VT100 Emulators for the Mac 8 replies "Lisa Pokel" 18 lines 19-FEB-1988 17:05 ---------------------------------------------------------------- I am looking for a *good* VT100 emulator for the Macintosh. I have just been using MicroPhone (v1.1) and have ran into problems with the some of the keyboard mappings (not a real big problem) but also it did not update the screen when using a word processor on my PDP (and thus lost track of where it was). I have also tried MacTerminal but that was choking on some of the escape sequences for screen display. I am running on a Mac-512 with (until the enhanced keyboard comes in) the standard keyboard and a plug in auxiliary keypad; while the word processor (LEX) uses the application keypad, they also (conveniently) duplicate the cut/paste/etc. functions using ESC & CTRL keys on the main keyboard so I know that it wasn't that. I have a list of about 10 different emulators from various magazine articles so what I am looking for is some first-hand opinions (both for & against) of the various emulators. Thanks in advance. Lisa Pokel AM Multigraphics 1800 W Central Road Mount Prospect IL 60056 ================================================================ Note 911.1 VT100 Emulators for the Mac 1 of 8 "JEFF KILLEEN" 0 lines 19-FEB-1988 20:07 -< RED RYDER - IT HAS BUILT IN KERMIT - GOOD KEYBOARD MAPPING >- ---------------------------------------------------------------- JEFF KILLEEN 31 HOPEDALE ST. HOPEDALE, MA. 01747 617-478-8098 VAX-96 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 911.2 VT100 Emulators for the Mac 2 of 8 "GREG P. SCHULZ" 11 lines 22-FEB-1988 09:49 -< TRY MAC240 >- ---------------------------------------------------------------- I am currently using MAC240 from White Pine software. Previously I used MACterminal and Kermit. MAC240 has a lot of nice features such as 132 columns, REGIS, SIXEL, KERMIT, XMODEM, VT100 & VT2XX keyboards. The package is one of the better ones on the market. I also considered VERSATERM. I am using MAC240 to communicate with several different VAX systems on a regular basis. I am using a MAC+ with a PL30turbo disk. GREG P. SCHULZ BURLINGTON NORTHERN RR ISS LOC 3 176 E 5TH STT ST. PAUL, MN 55164 612 298-7344 ================================================================ Note 911.4 VT100 Emulators for the Mac 4 of 8 "Bruce Bowler" 4 lines 22-FEB-1988 14:42 -< Try VersaTerm >- ---------------------------------------------------------------- I haven't tried Mac240, but can speak kindly about VersaTERM. Lately (since I went to 4.7) it has been having problems with SET TERMINAL/INQUIRE. It supports KERMIT, MacBinary, MacTerminal and emulates VT100, DG something-or-other, and Tek 4010 (or is it 4014?). Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 VAX-97 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 911.6 VT100 Emulators for the Mac 6 of 8 "GREG P. SCHULZ" 13 lines 23-FEB-1988 18:34 -< MORE ON THE MAC... >- ---------------------------------------------------------------- In addition to the previous capabilities of MAC240, you also have the capability with additional software from White Pine to translate and display regis. I have already displayed sixel files on my MAC and am currently working on displaying MACpaint type files on my VT240 at work. ALso trying to print MACpaint files on a LN03. MAC240 is a driver based emulator (Don't hold your breath but LAT may be in the future...) meaning that new drivers (Serial, etc.) may be used for communicating. MAC240 also works with TSSNET for those who need DECnet capability. GREG P. SCHULZ BURLINGTON NORTHERN RR ISS LOC 3 176 E 5TH STT ST. PAUL, MN 55164 612 298-7344 ================================================================ Note 913.0 Looking for Exabyte 8mm users 4 replies "KEVIN J. KUREK" 49 lines 23-FEB-1988 15:15 ---------------------------------------------------------------- How many of you have tried the 8mm 2.3 Gb drive from Exabyte? What has been your experience with the drive? I would like to get your feedback? Recently, I purchased one of these drives from a value added reseller. The drive was easy to install and took less then 30 minutes on a VAX 11/780. The drive works great. It truly holds 2.3Gbytes. To prove this I successfully backed up 5 RA81s that were 95+% full to the drive. Performance of the drive has proven to be adequate for my environment. I have seen transfer rates between 70 and 90 Kbytes/sec. I did expect higher transfer rates, but since backup is done during the night I really do not care how long it takes. My test showed that initializing (INIT dev: vol_name:) VAX-98 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT a tape on the average takes 2.25 minutes. Mounting (MOUNT/FOR dev:) an initialized tape took approximately 33 seconds (it takes 30 sec. to get the drive spinning). And the BACKUP/IMAGE of an RA81 took approximately 1.25 hours. The backup command used did have CRC turned on and used the default buffer count. The disk was very fragmented and contains many small files. (average block size is 35). One of my initial concerns about the drive was media reliability and data integrity. After reading several articles about the drive I discovered that the drive employs both ECC and Reed Solomon error checking. This gives the drive a non-recoverable error rate of less than on bit in 10**13, or about the same as the rates for a Winchester disk. Thus, I am no longer as concerned about data integrity. I am still concerned about media reliability. The only problem that I have had so far is the reliability of the drive itself. The first drive I received lasted only 2 days before breaking while the 2nd drive lasted 2 weeks before breaking. I am currently on my 3rd drive and have had it for about 5 weeks without a problem. Considering that SONY makes 90% of the drive I believe that it is just coincidental. Lastly, I have found one major difference between an Exabyte drive and a Digi-data VHS drive. It is my understanding that whenever the VHS drive must stop and start that approximately 1 Mbyte of tape space is lost. On the other hand this transition on the 8mm tape only loses 8 Kbytes of tape space. KEVIN J. KUREK GIDDINGS & LEWIS ELECTRONICS 666 S. MILITARY RD. P.O. BOX 1658 FOND DU LAC, WI 54936-1658 (414)929-4713 VAX-99 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 913.1 Looking for Exabyte 8mm users 1 of 4 "Bob Huckins" 3 lines 25-FEB-1988 18:41 -< Maybe not coincidental... >- ---------------------------------------------------------------- Re your comment about Sony: if you look at the Consumer Reports reviews of VCRs, Sony has one of the worst reliability records. Maybe you'd have had better luck if Magnavox made the drive! Bob Huckins Nuclear Data Instrumentation Div. Golf & Meacham Rds. Schaumburg, IL 60196 312-884-3659 ================================================================ Note 913.2 Looking for Exabyte 8mm users 2 of 4 "Terry Kennedy" 12 lines 26-FEB-1988 00:30 -< Put the 'It's a Sony' sticker on the garbage can... >- ---------------------------------------------------------------- Sony seems to be good at developing technology, but bad at mass-manufacturing it. After about 10 assorted pieces of gear from Sony, I have given up on them. Every single piece of equipment developed severe mechanical problems soon after purchase (in some cases, instantly thereafter). Also, their service facilities do not 'repair' equipment - they sit on it until you call and complain, and then charge you for a supposed repair when you pick it up. [Note- the above was determined by putting colored screw sealer on all the case screws - when the item was returned, all the seals were intact...] Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 VAX-100 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 913.3 Looking for Exabyte 8mm users 3 of 4 "Bill Mayhew" 9 lines 26-FEB-1988 10:34 -< This ain't the Sony User's Society, but... >- ---------------------------------------------------------------- I have had nothing but good luck with Sony equipment including 2 of their VCRs, one of which did need new heads after two years of two-hour-a-day (minimum) use, but so what. The local Sony authorized repair facility also did a very good job on fixing it, particularly after I tried to fix it myself first {VERY embarrassed grimace...}. The reason I tried to do it myself is that the local repair facilities were all backed up for four weeks, minimum. There is a market out there for DECservice on VCRs, methinks. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 913.4 Looking for Exabyte 8mm users 4 of 4 "Terry Kennedy" 8 lines 27-FEB-1988 20:07 -< A distinction >- ---------------------------------------------------------------- > The local Sony authorized repair facility... As opposed to a "Sony factory service center"? If so, you dealt with some non-Sony people who were trained and approved by Sony to fix Sony equipment. Yes, they seem much better than "real" Sony service, but I wouldn't bet on them fixing 8mm backup equipment where Sony only makes part of the mechanism. Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 VAX-101 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 920.0 My kingdom for a password... 2 replies "Michael R. Pizolato" 28 lines 26-FEB-1988 13:58 ---------------------------------------------------------------- I am planning to implement an electronic signature system for documents. What I want to be able to do is prompt the user for his password (with no echo and a verification, of course) and verify the password against his UAF record. There is nothing in the system services or RTL manuals about this. I called Colorado, and they told me this was probably intentional, but they weren't sure why. The only reason I could think of is that good data encryption algorithms require a key for decryption so that even if you know the algorithm you can't decrypt the data without the key. Since there is no key used for the encryption of passwords, knowing the password encryption algorithm could allow someone to decrypt the password. One problem: the encryption algorithm is in the VMS microfiche! Does this mean all our systems are vulnerable to attack? Lawd, I hope not! But, if knowing the algorithm as presented in the fiche is not enough to allow decrypting of passwords, why can't there be a system service to allow suitably privileged users to do password verification? Anyway, since DEC doesn't supply such a routine, does anyone out there know where can get my hands on one? I'm not fluent in MACRO or BLISS, so I don't want to try to reverse engineer the routine in the fiche (and that may not be legal). Michael R. Pizolato AT&T Technology Systems Dept. 323610 555 Union Blvd. Allentown, PA 18103 215/439-5500 VAX-102 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 920.1 My kingdom for a password... 1 of 2 "John Osudar" 27 lines 26-FEB-1988 16:45 ---------------------------------------------------------------- The password encryption algorithm used in VMS is supposed to be "one-way", i.e. you can encrypt the original password to get the encrypted result, but you can't take the encrypted password and arrive at the original password. VMS checks passwords by encrypting the password being tested, and comparing the result against the encrypted valid password. Thus, having the encryption routine published in the fiche doesn't present a "significant" risk. (Of course, you COULD write a program that tests every possible password by encrypting it using the algorithm, and comparing the result against the valid encrypted password. Having the routine in the fiche makes this easier, but I can't imagine wanting to spend the effort required to do this, if a system mandates reasonable minimum password lengths.) Having the encryption routine available for general use seems to make sense -- you could then use it to password-protect your own software in a manner similar to VMS. Why it's not available is unclear, but keep in mind that a lot of other useful routines that VMS calls all over the place (e.g. LIB$FID_TO_NAME) aren't available in any library, and are undocumented except in the fiche. (Some of them may make it into V5.0 as documented and supported library routines, however.) Legal or not, a lot of people have copied useful subroutines out of the fiche and used them for their own software. (Actually, I don't see why it would be illegal as long as you stay within the restrictions that are placed on other DEC subroutines linked into your own code.) As I recall, the routine in question is not all that long (a couple of pages?) so typing it in shouldn't be too horrible -- but it is a shame that you have to do it at all. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-103 PAGESWAPPER - April 1988 - Volume 9 Number 9 INPUT/OUTPUT ================================================================ Note 920.2 My kingdom for a password... 2 of 2 "Dale E. Coy (505) 667-3270" 12 lines 26-FEB-1988 22:20 -< DEC Provides It - you just have to know where! >- ---------------------------------------------------------------- Get out your copy of the VMS4.7 distribution tape. Unpack the save-set, and look at: VMS$CHECK-DIGITAL-ACCOUNTS.COM and VMS$SECUREPWD.EXE This is used to check if passwords on an account are easily guessable (is the FIELD password MAINTENANCE?), but could be simply modified to do exactly what you want. It's not left behind by VMSINSTAL, but since it comes on the distribution it must be legal to have/use/modify it. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 VAX-104 PAGESWAPPER - April 1988 - Volume 9 Number 9 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - April 1988 - Volume 9 Number 9 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Mark D. Oakley Battelle Columbus Division Room 11-6-008 505 King Avenue Columbus, Ohio 43201-2369 USA PAGESWAPPER - April 1988 - Volume 9 Number 9 VAX Systems SIG Spring 1988 SIR Ballot VAX Systems SIG Spring 1988 SIR Ballot DECUS membership number __________________ (six digits) Our site uses the following VAX cpus (check all that apply) 8700/8800 ___ 86nn ____ 85nn ____ 83nn/82nn ____ 11/780,11/782,11/785 ____ 11/750 ____ 11/730,11/725 ____ MicroVAX I,II ____ MicroVAX 2000 ____ MicroVAX 3n00 ____ We use VAXes in the following applications(Check all that apply) Business EDP ____ Software Development ____ Education ____ Computer Science Research ____ Data Acquisition/Control____ CAD/CAM ____ Service Bureau ____ Hardware Development ____ Scientific/Engineering ____ Office Automation ____ Telecommunications _____ Other __________________________ I support the following as the most important System Improvement Requests. (List from zero to fifteen SIR's): -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- I oppose the following SIR's as detrimental. (List from zero to five SIR's): -------- -------- -------- -------- -------- Mail to: Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, OH 43201-2693 USA To be counted, your ballot must be received by April 8. PAGESWAPPER - April 1988 - Volume 9 Number 9 VAX Systems SIG Spring 1988 SIR Ballot Tear out or photocopy reverse to vote on SIRs Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, Ohio 43201-2693 USA