PAGESWAPPER Editor's Workfile . . . . . . . . . . . . . . . . . 3 DEC Response to The Fall 1984 SIR Ballot . . . . . . 4 VAX Security Working Group Report . . . . . . . . 12 A User Written Program to Monitor Devices . . . . 17 User-Written ACPs . . . . . . . . . . . . . . . . 22 VAX System SIG Committee List . . . . . . . . . . 23 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . 26 LUG Agenda . . . . . . . . . . . . . . . . . . . . 30 System Improvement Request Ballot . . . . . . . . 33 VAX Systems SIG Spring 1985 SIR Ballot . . . . . . 66 INPUT/OUTPUT Submission Form . . . . . . . . . . . 68 System Improvement Request Submission Form . . . . 70 PAGESWAPPER - February 1985 - Volume 6 Number 8 General material for publication in the Pageswapper should 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. Please do not submit program source, as that is better distributed on the VAX SIG tape. Material for "The DBMS Monitor" section of the Pageswapper (pertaining to VAX-11 DBMS) should be sent to: Julie Llewellyn United Technologies Microelectronics Center 1365 Garden of the Gods Road Colorado Springs, CO 80907 USA 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. 2 PAGESWAPPER - February 1985 - Volume 6 Number 8 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor The best laid plans ... What was supposed to be the first issue with the table of contents on the cover last month turned out to be the first issue without any table of contents at all. This month I will try again on getting agreement between Cambridge and Marlboro as to what is happening, so hopefully the issue you are now reading has a table of contents on the cover. Previous (Cincinnati) commitments by DEC regarding documentation of VMSINSTAL have been fulfilled in a slightly unexpected fashion. If you looked through the VMS 4.0 documentation set in vain, try 232 D 15 in the microfiche. It seems like a great idea to me, since it provides the documentation a vocal minority clamor for without the expense of additional pages in every documentation set or burdening the user who does not write software for distribution and could hardly care less. Months ago I jotted down a note while listening to the audio tape of a software tools symposium session, and the note has just surfaced. The basic idea (perhaps obvious to everyone else, but it had not occurred to me) is to document all your site-specific subroutine library entrypoints in VMS help files so that programmers need not go looking for the (perhaps nonexistent) hardcopy documentation. I presume that those in well-disciplined shops even extract the text automatically from standardized comments. Wow! 3 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot DEC Response to The Fall 1984 SIR Ballot Gary Grebus SIR Coordinator and Peter George VMS Development At a session during the Anaheim Symposium, Digital presented their responses to the top ten items on the Fall 1984 System Improvement Request ballot. The responses were presented by Peter George from the VMS development group, and represented the work of several developers. A full report on the Spring SIR Ballot was published in the December 1984 issue of the Pageswapper. The full text of the top ten are reproduced below, along with the text of the responses. You should note that several of the top 10 items generated a number of questions from the VMS developers. A very clear example is the most popular SIR item on this ballot, LOGOUT and SYSLOGOUT procedures. This is not the first time that this request has made the top 10. However, Digital has said they don't believe it is possible to implement this capability, given the wording of this request. It appears that this topic (among many) is sufficiently complex to require further discussion. What restrictions would be acceptable? What would be acceptable behavior given error conditions? How can the limitations of such a mechanism be made clear to avoid misuses? Based on the SIR voting, a number of SIG members feel they need LOGOUT procedures. If you are one of these people, give some further consideration to all aspects of the problem. Put your observations in writing and share them with the SIG membership, by sending them to the the Pageswapper or to the SIR Coordinator. Such input can form the basis for SIG position papers and further discussions with DEC. Other important VAX topics require a similar, more intensive approach. Do you need system rollout capability, better tape handling, more resource sharing in a cluster? We can gauge the popularity of such topics through the SIR program, but the requirements and technical issues are not done justice in a one paragraph SIR statement. More complete discussions, in concert with the SIR program and the activities of the SIG working groups are needed to address such complex issues of VAX evolution. The Fall 1984 Top 10 System Improvement Requests 1. SIR: F83-28 4 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot Automatic LOGOUT and SYSLOGOUT procedures required. VAX system managers can create a SYSLOGIN command procedure to be executed by all logins, and can specify a LOGIN procedure in the UAF entry for each user. A corresponding LOGOUT feature is needed to allow site specific process shutdown activities that cannot be bypassed by the user. Reply: It's a neat idea that we've heard many times before, but the catch is that we don't know how to do this in a way that "cannot be bypassed by the user". Some of the major issues: o How do you keep the logout command procedure from being bypassed by the user? He can always use STOP/ID=0 or a program of his own that calls the $DELPRC system service to delete his own process without running the command procedure. o How do you keep other people from using the same mechanisms to delete someone's process. o Assuming you solve these problems, how do you then kill a process that has been made "undeletable" if it gets out of control? o What do you use for a logout command procedure for processes that run under CLI's other than DCL, like MCR and SHELL? o How do you handle processes where there is no CLI? Do they also need to run the logout command procedures on deletion? o How about subprocesses? o How about batch jobs that are deleted in the midst of execution? o What do you do if a process's CPU limit runs out before running the logout command procedures? o What if a process' CPU limit runs out while running the logout command procedures? In general, how do you handle errors that happen in the midst of this new, more complex process deletion system? Should we consider implementing the feature in a way that makes on claims about not being able to be bypassed by the user? Our feeling is that such a feature would be of little value and is 5 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot subject to misinterpretation or misuse. 2. SIR: F83-12 VMS needs lexical functions to access all information available through the SHOW command. Many applications are forced to do a SHOW "XXXXXXX" with the output assigned to a file that is then read back and parsed. This is very inefficient and is invalidated every time the output format of SHOW is changed. A preferred method would provide extensions to DCL lexical functions permitting user access to all items of information provided by the SHOW facility. Reply: We both agree and would like to take this suggestion even further. We believe that all information available through the SHOW commands should also be available through a callable interface. This interface could then be easily mirrored by a DCL lexical function interface. The only real issue is that it takes time to do this and the usual tradeoffs have to be made in considering exactly which features get included in a particular version of VMS. We have begun this effort. The addition of many new items to the $GETDVI, $GETJPI, and $GETSYI systems services and lexical functions in Version 4 is a good example of our intentions. Also, the new F$ENVIRONMENT lexical function gives you easy access to much information that was formerly very difficult to retrieve. 3. SIR: F83-16 All DCL file utilities need a /CONFIRM qualifier. When using COPY or PURGE on a subset of a directory it is often impossible to use wildcards to select the correct files. It would be useful to be able to select all the files and then be prompted to confirm each file individually. Reply: We've satisfied this request in Version 4 by making a set of file selection qualifiers common to many DCL file manipulation commands. The qualifiers are: /BEFORE=time /BACKUP /BY_OWNER=uic /SINCE=time /CREATED /CONFIRM /EXPIRED /EXCLUDE=(file,...) 6 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot /MODIFIED The DCL commands that allow all these qualifiers are: APPEND, COPY, DELETE, PRINT, PURGE, RENAME, SET FILE, SUBMIT, TYPE, AND UNLOCK. We are also constantly working to improve the more general problem of consistency between DCL commands. We try to have the same qualifier mean the same thing no matter what command it is used on and we try to supply each command with as complete a set of qualifiers as makes sense for that particular command. 4. SIR: F83-14 Support wild card SHOW SYMBOL. Reply: Good idea. DELETE/SYMBOL should too. That would allow a command procedure to easily create and delete a unique set of symbols for its own use by simply using a unique prefix on all its symbol names. We are also looking at ways to restructure the DCL symbol table and hence speed up symbol table lookups. We hope that any easy implementation of wild card symbol lookups will fall out of this work. 5. SIR: F83-30 The BACKUP utility should provide a feature to copy save sets from one media type to another. The BACKUP utility should be enhanced to include a '/COPY' qualifier which would enable a sequential saveset to be copied from one device to another. A prime example of this is the archiving of VMS update kits to tape from sequential floppy disk save sets. There are also many cases in which it would be useful to copy mag tape save sets from one drive to another while at the same time utilizing the error recovery and error checking algorithms used within the BACKUP utility. Reply: We've heard this one before and think it's a good idea. We can think of lots of good applications for it ourselves. The major reasons it hasn't been done yet are (1) it will require a significant amount of reworking of BACKUP's save set processing and (2) active development of BACKUP was minimized during Version 4 because the development resources were needed elsewhere. It is on our list of enhancements to make to BACKUP in a future release. 7 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot 6. SIR: F83-31 Enhance BACKUP "SELECT" and "EXCLUDE" capability. It is frequently necessary to exclude or select many files from a BACKUP restore run. Often, several passes are required over a BACKUP tape because all of the desired files cannot be specified due the limitation on the length of DCL commands. BACKUP should allow the SELECT and EXCLUDE operations to be driven from a file that will contain a list of the files to be selected or excluded. Reply: We've heard this one before too. However, we didn't realize it was this popular. We'll add it to our list. In the mean time, the problem is at least partially alleviated in Version 4 by the increased size of the DCL command buffer - now 1024 characters. 7. SIR: F83-9 Provide an easy mechanism for maintaining customer extensions to DCL. Currently only two ways exist to add customer commands to DCL: executing SET COMMAND commands during login, and modifying the Digital supplied DCLTABLES. The former method greatly slows logins, and the latter creates maintenance problems when VMS is upgraded. It would be desirable if there was a better isolated mechanism for modifying the DCL tables. For example, an ordered hierarchy of tables could be searched for user commands, site commands, and Digital supplied commands. Reply: The good news is that Version 4 provides some new ways to specify the command tables that you want a process to run with. The bad news is that none of these methods implement the search list concept that this SIR specifically suggests. The new methods are: o You can specify the command tables in a user's UAF record. o You can specify the command tables after the user name prompt when logging in, for example, /TABLES=DCLTABLES. o You can specify the command tables on a SPAWN command using the /TABLES qualifier. The major issues that we see arising from a multiple table implementation ae: 8 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot o If we go with a search list of several tables, are you willing to pay the performance price of multiple searches every time DCL parses a command? Not that ambiguity checks would still have to be performed in secondary tables even if most commands could be found in the first set of tables. o If we go with a single set of merged tables, are you willing to pay the performance price of merging those tables every time a DCL process is created? o In both cases, should we allow commands to be spread across the source tables? Can SHOW DEFAULT live in one set of tables and SHOW PROTECTION in another? IF the answer is yes, then this raises a whole torrent of questions on how exactly do you merge two commands together. o Where do the DIGITAL supplied tables fit in the search order? If not at the beginning, then how do we support a system where you've changed the command definitions that we've shipped. In summary, this is not an easy feature to implement, but we'll look into it. 8. SIR: F83-3 Provide a VMS primitive for determining if a process is truly idle. Many user sites implement programs to terminate idle interactive processes for security purposes. Current VMS primitives do not provide a reasonable way for detecting the fact that a process appears idle (no CPU, I/O, etc.) because it is waiting for an operator reply or tape ACP service. Reply: What is an idle process? Different people have different definitions. Also, how can the system distinguish between a process that is in a LEF state because it is waiting for the operator to mount a tape and process that is in a LEF state because it hasn't received any input from a terminal in the last two hours? We don't know how. We prefer to continue to let you decide on your own personal definitions of idle processes. Once you've done that, it is simple enough to create a process that sits around on your system and uses the $GETJPI system service to periodically check processes for the attributes that you've decided indicate true idleness. 9 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot [Note: A discussion of this response followed. The consensus of the session attendee's (including the original author of the SIR) was that the SIR did not request DEC to implement idle process detection. Rather, the SIR points out that the existing primitives ($GETJPI, etc) are not able to distinguish two particular cases of an idle process. The SIR asks that these two cases be distinguishable so that we can implement our own policies reliably. Given this clarification, Digital indicated they would investigate adding this enhancement.] 9. SIR: F83-15 Provide a better utility for navigating directory trees. The present command for "navigating" a directory tree (SET DEFAULT) is inadequate. Almost every VAX site has implemented some program or command procedure to allow shorthand notations for changing default directories. For compatability, it would be useful to have a DEC supplied utility. The most important feature of such a utility would be to provide a memory of the last n directories visited, with a notation for backing up to the m'th previous directory. Reply: This request came as a bit of a surprise to us. We never sensed a great need for this sort of utility precisely because we all have our own little tricks and command procedures that we use to achieve this goal. Given the level of interest in this request, we will investigate providing the feature either through enhancements to DCL, or through the addition of a new utility. In the near term, command recall and editing should help a little. 10. SIR: F83-23 Provide a SYSGEN DISCONNECT command. When configuring devices with the CONNECT command, it would be useful to be able to reconfigure the device without rebooting the system. This would allow correcting the specification of CSR address or vector due to an error in the CONNECT or in the device switch settings. Reply: We do not know how to make a safe SYSGEN DISCONNECT command. In particular, the mechanisms to detect an idle (safe to disconnect) device do not exist and are nearly impossible to define. For example, we already know that the idle device test uses by the SYSGEN RELOAD command is full of holes. 10 PAGESWAPPER - February 1985 - Volume 6 Number 8 DEC Response to The Fall 1984 SIR Ballot So give us a better idle of what you want to do? Is it okay to implement this feature for some drivers and not for others? For example, is it okay for the CI port driver and the disk class driver to not be disconnectable? Will you be satisfied if VMS allows a disconnect only if the device reference count is zero? 11 PAGESWAPPER - February 1985 - Volume 6 Number 8 User-Written ACPs User-Written ACPs At the Anaheim DECUS symposium, the two of us agreed to co-chair a panel discussion on user-written ACPs for the Fall 1985 DECUS symposium. Since it takes more than two to have a good panel, we are asking for participants. Anyone who has written an ACP, wants to talk about it, and wants a pretty ribbon on their badge, is invited to contact us. If we get an interesting set of participants, we will try to write up the discussion for the PAGESWAPPER. Jamie Hanrahan Chuck Bolz Simpact Associates Aptec Computer Systems, Incorporated 5520 Ruffin Road 10180 SW Nimbus Avenue, J-6 San Diego, CA 92123-1390 Portland, OR 97223 (619) 565-1865 (503) 620-9840 VAX Security Working Group Report C. Douglas Brown January, 1985 Three years ago, the VAX Security Working Group submitted a position paper to DEC requesting a variety of security enhancements to VMS. As of the VMS 4.0 release, the majority of those requests have been implemented. I would like to publicly thank VMS Development in general and Andy Goldstein in particular for the significant advances in security provided by VMS 4.0. I am quite sure that this was not due simply to the activities of the Security Working Group but was also a result of the developers' concern for security. The security features provided with VMS 4.0 adequately addressed the first four areas of concern in the 1982 working group position paper, i.e., (1) basic system integrity, (2) protection against scavenging, (3) audit trails, and (4) discretionary file access. The last two areas have not yet been adequately addressed. They are (5) nondiscretionary access controls and (6) network security. However, VMS 4.0 does indeed contain some latent, unsupported code that implements nondiscretionary access controls, but the user interfaces are missing and some of the code is not yet there. Also, DECnet security was enhanced by the official support of proxy access in VMS 4.0. 12 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX Security Working Group Report Because VMS Development is now in the process of planning for the next major release, I thought it best to issue an updated position paper dealing with the security features that have not been addressed by VMS 4.0. It is my belief that VMS Development is already interested in implementing the features that we will be requesting, but by restating our requests for security enhancements I hope to accomplish two things--(1) refining our requirements based upon our experiences over the past three years and upon the directions in which DEC appears to be heading, and (2) providing impetus to DEC to continue with the implementation of additional security features by demonstrating a continued interest on the part of the working group. The first draft of a new position paper is included below. I WOULD LIKE TO SOLICIT YOUR COMMENTS, BOTH POSITIVE AND NEGATIVE, TO THIS PAPER. After receiving comments, I will send a second draft to those persons who responded to the first draft, and I will try to finalize the position paper by the third draft. The final draft will again be published in the Pageswapper. I will forward copies of all the comments that I receive to VMS Development, so that minority comments which do not make it into the final draft will still be available to the developers. If you are at all interested in the security features being discussed in this paper, please respond, preferably in writing, so that I can gauge the level of interest. Even if you have no changes to suggest, it would be very helpful to hear from you. My address and phone number are as follows: C. Douglas Brown Sandia National Laboratories Division 2644 P.O. Box 5800 Albuquerque, NM 87185 Phone: (505) 844-7993 VAX Security Working Group Position Paper First Draft, January 10, 1985 It is requested that the following security features be implemented in the VAX/VMS operating system. 1. Non-discretionary Access Controls These types of controls have in the past been used primarily by those sites which are processing government classified information, but their use may extend to other environments where a high degree of security is desired. It is desired that 13 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX Security Working Group Report non-discretionary security controls be implemented to the extent that the standard VMS operating system can be certified by the DoD Computer Security Center at the B1 level or higher. In a system with non-discretionary access controls, each user process operates at a security classification established by the system at login time. The minimum and maximum security classifications at which a user may operate should be parameters in the user authorization file. Each data object within the system, e.g. file, mailbox, event flag cluster, or logical name, should have a security classification associated with it that is inherited from the process that created the data object. Accesses to those data objects should be controlled according to a predefined security policy that compares the security classification of the process with the security classification of the data object and determines the allowable modes of access. The non-discretionary controls which are latent and unsupported in VMS 4.0 should be satisfactory if completed and supported throughout the operating system at the user interface level. In additional to the general support of non-discretionary access controls, some specific items are discussed below. 1. Conversion to Non-discretionary Controls In order to ease the conversion of a system to non-discretionary controls, files that exist on disk prior to the activation of those controls should be assumed to have the lowest security classification. A utility, perhaps a qualifier to SET FILE, should be provided for use by the system manager in setting file classifications during this conversion process. 2. Objects to be Controlled In addition to support, which is latent in VMS 4.0, for non-discretionary controls on disk files, disk volumes, logical names, and mailboxes, VMS should also support such controls on global sections. It is also desirable to have non-discretionary controls on event flag clusters and locks, but such controls should only be included if the degree of complexity of the implementation is not too great and the performance impact is not significant. Batch and print queues should have associated minimum and maximum security classifications and jobs should be permitted in those queues only if they fall within the range of allowable security 14 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX Security Working Group Report classifications. 3. Print Symbiont Capabilities A capability should be provided for a user-modified print symbiont to specify a site-supplied bottom-of-page routine for the purpose of printing classification markings. The current VMS 4.0 capability for specifying a site-supplied top-of-page routine is necessary but not sufficient. It would be very useful to have a print symbiont that would take advantage of the above capabilities to print classification markings (obtained from the classification of the file being printed) at the top and bottom of each page of a listing. 4. Magnetic Tape Access Controls The magnetic tape access checking capability that is provided with VMS 4.0 should be enhanced to include parameters that are necessary for non-discretionary access control checks, e.g., a pointer to the Access Rights Block for the process requesting the tape and a pointer to the Objects Rights Block for the tape drive. 2. Network Security This is an area that admittedly overlaps considerably with the activities of the VAX Networks Working Group within the VAX SIG, and it is understood that the Networks Working Group is pursuing some of the same network security features that are discussed below. However, we are addressing network security in this paper because of its importance to VAX security. It is of limited value to have a highly secure VAX/VMS system, if that system is in a network that lacks important security features. 1. Improved Node Authentication Better node authentication should be provided by DECnet-VAX. The node authentication provided by DECnet-VAX in the form of node transmit and receive passwords is woefully inadequate. Not only is it easily circumvented, but it is applicable only to adjacent nodes. A better node authentication capability is desired, perhaps one that is encryption based, so that a system can have a high degree of certainty that the nodes with which it is communicating are who they claim to be. Note that it is not necessarily desired that all data be 15 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX Security Working Group Report encrypted, as that may entail a high overhead. 2. End-to-end DES Encryption Optional end-to-end DES encryption should be supported within DECnet-VAX, with a separate DES key being used for each logical connection. This feature should be implemented at the NSP level, so that it is transparent to the user program. End-to-end encryption would protect data in transit on intermediate routing nodes or in transit across an Ethernet network from disclosure to and/or modification by privileged users within the network. The system manager should be able to activate or deactivate DES encryption between his VAX and any other DECnet node that supports that feature. 3. Non-discretionary Security Non-discretionary access controls should also be enforced by DECnet-VAX. Each DECnet "connect initiate" message should contain the security classification of the process that is requesting the connection. The connection should be rejected if the security classification of the process that is accepting the connection does not match the security classification of the requesting process. This feature is necessary in order to prevent information from being downgraded to a lower classification as it is being moved across the network. It would be desirable to have each node in a network configured with minimum and maximum security classifications, so that connections to that node outside that range of classifications would not be permitted. 4. Disabling Access Control Strings The DECnet proxy access capability should be enhanced with an option that allows the system manager to turn off access control strings, incoming and/or outgoing, for specified nodes. If the system manager were careful to ensure that the proxies mapped user accounts from remote nodes into accounts on the local node with the same security classifications, then the users would be prevented from declassifying information across the network. However, this approach is less desirable than simply passing security classification information between nodes in the DECnet protocol as described above. 16 PAGESWAPPER - February 1985 - Volume 6 Number 8 A User Written Program to Monitor Devices A User Written Program to Monitor Devices B.C. Dow-Pleines Calma 1565 Barber Lane Milpitas, CA 95035 There are several programs in existence that monitor various devices. The programs output data about how busy the device is and the number of QIO's. But what if you want more information on a certain device, for instance, average number of bytes per transfer per second? Or what if you want a "real time" video display of whats happening on a device. The solution is to write your own program to do it. Actually, the true solution is to obtain a copy of the program BUSUSE (MBAUSE) , written by R.F. Wrenn, and modify it to meet your needs. BUSUSE monitors the activity on the massbus, and massbus drives and outputs statistics onto the screen. It takes data every 1/4 of a second and updates the video display every five seconds. Luckily, to update BUSUSE for your device does not require much change, in fact the structure of the program does not have to change at all. Only the references to the device name and UCB - Unit Control Block - parameters, the display output lines and the statistics need to be changed. Another important consideration is that BUSUSE is written in Fortran which is a widely known language. Now to get started. First decide what device you want to monitor and find its three character mnemonic name using the show /device command in the sysgen utility. Then choose whether you want to represent the data in char or integer format. The character format used is char*3, the integer format is I*4. (Note, integer is faster, but character is more readable for the future debugger.) After declaring the variable, use a data statement to assign the three characters to the variable. An example is shown below. CHAR DATA INTEGER DATA character*3 RRA integer*4 DCA data RRA /'RRA'/ data DCA /'41434403'X/ Note, that when declaring the integer data type that the number three appears first followed by the numeric values for the characters in a RIGHT-TO-LEFT order. This is because bytes are loaded in a right to left order. 17 PAGESWAPPER - February 1985 - Volume 6 Number 8 A User Written Program to Monitor Devices The next step in the program is to find this device name in the linked list of DDB's - Device Data Blocks in the system. The linked list is pointed to by the pointer: IOC$GLDEVLIST The format of a DDB is shown below. --------------------------- | DDB$L_LINK | LINK TO NEXT DDB IN CHAIN --------------------------- | DDB$L_UCB | LINK TO UCB ASSOC WITH DDB --------------------------- | | DDB$W_SIZE | SIZE OF DDB --------------------------- | |$B_TYPE| | TYPE OF BLOCK --------------------------- |00 | --------------------------- | DDB$L_DDT | ADDRESS OF DISPATCH DRIVER --------------------------- | DDB$L_ACPD | NAME OF DEF ACP FOR CONTROLLER --------------------------- | DDB$T_NAME | GENERIC NAME OF DEVICES --------------------------- | | ATTACHED TO CONTROLLER --------------------------- | | --------------------------- | | --------------------------- | DDB$T_DRVNAME | NAME OF DEVICE DRIVER FOR --------------------------- | | THE CONTROLLER --------------------------- | | --------------------------- A do-while loop is the best structure for this exercise. An example of the code is shown below with comments. The routine syspeek picks up the contents of the location specified. A value of 4 in the call to syspeek picks up a longword, the value 2 picks up a word, and 1 picks up a byte. c Example, look for RRA device. Variable RRA c declared CHAR*3 c c pick up the head of the device list c ddb = syspeek (%loc(ioc$gl_devlist),4) c 18 PAGESWAPPER - February 1985 - Volume 6 Number 8 A User Written Program to Monitor Devices c Loop until device found, ddb = 0 means end of linked list. c do while (ddb .ne. 0) c c Pick up device name in current DDB and compare to RRA c variable. c c First byte contains a count of the number of characters c in the device name. Store this value in variable count. c count = syspeek(ddb+%loc(ddb$t_name),1) c c Pick up device name char by char c do i = 1,count devname(i:i) = 1 char(syspeek(ddb + %loc(ddb$t_name)+i,1)) enddo c c Now compare with RRA variable to determine if DDB for c RRA device has been found. c if ( devname .eq. RRA) then c c Found the RRA device, pick up the associate UCB (UNIT c CONTROL BLOCK) for this DDB. c ucb = syspeek(ddb + %loc(ddb$l_ucb),4) endif c c pick up next device in linked list by following link c pointer c ddb = syspeek(ddb + %loc(ddb$l_link),4) enddo After the address of the UCB has been found the data collection area can begin. The parts of BUSUSE that can be copied without modifications are: the code that sets priorities, the code that creates an exit handler, the system service calls, and the syspeek, and readkey subroutines. The screen display code only needs minor modifications to display your text. But the data portion is where the most rework gets done. An example would be worth more than a thousand words. In the example below, the RRA will be a graphics device on which I want to monitor the %busy, number of QIO'S per second, and the average number of bytes transferred per transaction. The UCB parameters that are examined are: ucb$l_opcnt - a longword containing the number of operation counts on a device since boot up time 19 PAGESWAPPER - February 1985 - Volume 6 Number 8 A User Written Program to Monitor Devices ucb$w_bcnt - a word counting a count of the number of bytes in an I/O transfer ucb$w_sts - a word containing the status of the device c c sample 1/4 of a second for five seconds. Note, this c means 20 samples c do k =1,20 c c wait for time (Code directly below copied from BUSUSE) c status = sys$wflor(%val(1), %val('00000002'X)) status = sys$setimr(%val(1), interval,,) c c Check the busy bit, and if the device is busy, obtain c a count of the number of bytes in the I/O transfer. c c first compare device status with the value indicating c device is busy - ucb$m_busy c busy = 1 syspeek(ucb + %loc(ucb$w_sts),2) .and. 1 %loc(ucb$m_busy) c c test for device busy c if (busy .ne. 0)then c c yes device is busy increment busy value c busy_value = busy_value + 1 c c keep a summation of the number of bytes in each I/O c transfer. At the end of 20 samples, divide the c byte_count value by the Busy_value to get the average c number of bytes per transaction. c byte_count = byte_count + 1 syspeek(ucb + %loc(ucb$w_bcnt),2) c endif enddo To obtain the number of QIO's per second is a bit tricky. Luckily BUSUSE has this code in it so you don't have to worry about major modifications. It is interesting to figure out how this data is obtained. The operation count field in the UCB contains a count of operations since boot up. In the program the initial value is stored away into a variable. Then the new operation count value is obtained once every five seconds, the old and new values are differenced and the 20 PAGESWAPPER - February 1985 - Volume 6 Number 8 A User Written Program to Monitor Devices difference is divided by five to get the number of QIO'S per second. The code is shown below to help clarify this. c c (Note, the origial operation count variable has been set c further up in the program, I am only grabbing the new value c after a five second interval c c grab qio counts c new_opcnt = syspeek(ucb + %loc(ucb$l_opcnt) c c calculate qio rate c qio_rate = (new_opcnt - old_opcnt)/5. c c reset old_opcnt to new opcnt to obtain the next set of qio's c old_opcnt = new_opcnt The above collection of code is certainly not all of the program modifications needed to be done. However, it is a substantial amount of the changes needed. The rest is left up to the reader. Finally, there are some caveats for this program. Because the program looks into the operating system tables it requires CMKRNL privilege to run. Also, if you have a bug in the portion of the code that looks at the operating system you will crash the VAX, and other users on the VAX do not appear to appreciate the imposed coffee break. 21 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX System SIG Committee List VAX System SIG Committee List As of December 12, 1984 Joe Angelico - Volunteer Coordinator and System Management US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA. 70130 June Baker - Planning Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 C. Doug Brown - Security Sandia Labs P.O. Box 2644 Albuquerque, NM 87185 Jack Cundiff - Assistant Symposium Coordinator Muskigum College New Concord, OH 43762 James R. Cutler - Hardware Software Results Corporation 2887 Silver Drive Columbus, OH 43211 Doug Dickey - Data Management SIG Interface CTEC, Inc. 6862 Elm Street McLean, VA 22101 Jim Downward - Migration and Host Development KMS Fusion Inc. 3621 South State Road, P.O. Box 1567 Ann Arbor MI 48106 Dan Fleury - Education University of Hartford West Hartford, CT 06117 Dennis Frayne - Real Time/Process Control McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals In House Systems 165 William Street 22 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX System SIG Committee List New York, NY 10038 Bob Boyd - Commercial GE Microelectronics Center MS 2P-04 Post Office Box 13409 Research Triangle Park, NC 27709 Don Golden - Overseas Coordinator / Publications Coordinator c/o Shell Development Company, D-2132 Westhollow Research Center Post Office Box 1380 Houston, TX 77001 Mark Graff - TOPS-VAX M/A-COM Linkabit, Incorporated 3033 Science Park Road San Diego, CA 92121 Gary Grebus - System Improvement Request Battelle Columbis Labs 505 King Avenue Columbus, OH 43201 B. Hancock - Network Sohio Petroleum Company Two Lincoln Center 5420 LBJ Freeway, Suite 900/LB 03 Dallas, TX 75240 R. Haydt - Foreign Devices, Hardware/Software Information Consultants International Incorporated P. O. Box 2014, E. V. STA Ormond Beach, FL 32074 Jeffrey S. Jalbert - Symposium Coordinator Dennison University Granville, OH 43023 Ken Johnson - Handouts 800 N. Lindbergh Monsanto MS V2B St. Louis, MO 63043 Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 23 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX System SIG Committee List Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Bob Robbins - VAXElan Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA P. Sandwell - Graphics Seismograph Service Corporation P. O. Box 1590 Tulsa, OK 74102 David Schmidt - LUG Coordinator Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201 D. Slater - Artificial Intelligence Mantech International 2320 Mill Road Alexandria, VA 22314 Louise Wholey - Languages and Tools Measurex Corporation One Results Way Cupertino, CA 95014 Douglas J. Wilson - Office Automation MIT Joint Computer Facility Room 5-137, 22 Massachusetts Avenue Cambridge, MA 02139 24 PAGESWAPPER - February 1985 - Volume 6 Number 8 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 367 Caption: Trapping Control Characters -- Reply to I/O # 333 Message: I have a FORTRAN subroutine for getting characters from the terminal which allows trapping any character. Contact: Tom Worlton Building 360 Argonne National Laboratory Argonne, Illinois 60439 Telephone (312) 972-8755 Date: January 3, 1985 INPUT/OUTPUT 368 Caption: Public Domain Version of RIM Message: Does anyone have any information on the availability of a Public Domain (i.e. cheap) version of the RIM database program developed for NASA by Boeing? I have heard one is available but cannot find it. Contact: Jack Berger FluiDyne Engineering Corporation 5900 Olson Memorial Highway Mpls. MN 55422 Telephone (612) 544-2721 Date: January 7, 1985 25 PAGESWAPPER - February 1985 - Volume 6 Number 8 INPUT/OUTPUT INPUT/OUTPUT 369 Caption: Mail Merge Message: We are looking for a software package, preferably free, which has the equivalent functions of MicroPro's Mailmerge for use in a VMS environment. The package should be able to merge a file containing a list of data elements for each record into a form letter. Contact: Joel Cohen Canisius College Computer Center 2001 Main Street Buffalo, NY 14208 Telephone 883-7000 x 448 Date: January 7, 1985 INPUT/OUTPUT 370 Caption: Massbus Load Evaluation -- Reply to I/O # 348 Message: There is a program named BUSUSE on the DECUS (USA) 1983 Spring tapes that monitors the load on the Massbus and Massbus drives. I have modified this program to also monitor the load on the Unibus and Unibus drives. If you are interested, I will send you the source. Contact: Barbara Dow-Pleines Calma MS BL2C 1565 Barber Lane Milpitas, CA 95035 Telephone (408) 943-5908 Date: January 7, 1985 INPUT/OUTPUT 371 Caption: Hewlett-Packard 7550A Plotter Message: I would like information about how to be able to use this device under VMS as a "print" type queue so multiple users could generate plots and route them for plotting. We are using H/P-ISSP subroutines. Contact: Gene Stonewall Farmland Industries, Incorporated Post Office Box 960 26 PAGESWAPPER - February 1985 - Volume 6 Number 8 INPUT/OUTPUT Bartow, FL 33830 Telephone (813) 533-1141 Date: January 10, 1985 INPUT/OUTPUT 372 Caption: restore FDR tapes to disk Message: We have 40+ tapes written by an IBM backup program called FDR. We would like to contact anyonw who has been able to restore files from such tapes. Contact: Duncan Sharp International Survey Research, Incorporated 303 East Ohio Chicago, IL 60611 Telephone (312) 828-9725 Date: January 16, 1985 INPUT/OUTPUT 373 Caption: "VAX Cat" Poster Availability Message: The VAX System SIG Poster "Welcome to VAXland" (the VAX cats) avalable at DECUS symposia, was a bit hit here. We would like to know if it is possible and if so how to purchase these posters between DECUS symposia. Contact: Ron Jolley DEC 1009 Nicklaus Avenue Milpitas, CA 95035 Telephone (408) 946-5947 Date: January 17, 1985 Pageswapper Editor's Response One problem is that between symposia the contents of the "DECUS Store" is cubic-close-packed into wheeled cabinets and not quite accessible. Another is that the volunteers who staff the DECUS store are only around at Symposia. The goal of mail order or similar sales is 27 PAGESWAPPER - February 1985 - Volume 6 Number 8 INPUT/OUTPUT well understood; but there are implementation problems (kind of like execute-only command procedures on VMS). DECUScope would be a good publication for discussion of these issues, since the problem is of interest beyond just the VAX Systems SIG. INPUT/OUTPUT 374 Caption: Booting MicroVAX I from RL02 -- Reply to I/O # 341 Message: In MicroVMS V4.1, there is a new command procedure and VMB that will provide the capability of booting from an RL02 or RC25. It is accomplished by booting an "intermediate" RX50 that contains the new VMB. Refer to the MicroVMS V4.1 Release Notes for all the details. Contact: Kathleen Morse DEC, ZKO1-1/D42 110 Spit Brook Road Nashua, NH 03062-2698 Telephone (603) 884-8396 Date: January 17, 1985 28 PAGESWAPPER - February 1985 - Volume 6 Number 8 LUG Agenda LUG Agenda The following LUG meeting information is published with the understanding that Pageswapper readers will receive it too late to attend the meetings. The purpose, rather, is to share meeting topic ideas among LUGS. o New Mexico VAX LUG - February 11, 1985 From meeting announcement The planned agenda is: 1. Dan Esbensen of Touch Technologies, Escondido, California will talk about their application development tool which is like VAX BASIC enhanced. It runs under VMS now, UNIX later. 2. Jerry Hanks of Sandia will present his implementation of an office environment, taking a PDP-11 and VAX 11/750 (stand-alones) to a three VAX, Ethernet, PDP, cluster system today. Experiences, successes, frustrations involved will be discussed. 3. Daryl Doucet of MICOM will discuss communications options available today. 4. Mike Hoy of DEC Software will discuss networking gotcha's found by DEC software specialists throughout the state. 5. Reports from members on the recent DECUS Fall Symposium held in Anaheim, California. 6. Open discussion. o BAYVAX LUG - Thursday January 31, 1985 From VOX VAX, the BAYVAX LUG Newsletter Our next meeting will be held Thursday, January 31 at the auditorium of Building 202, Lockheed, Palo Alto (up on the hill) from 9 am til noon. For those of you who attended the image processing/Moxon talk - same place. For those of you who didn't, a map is attached. We will NOT be badging people at the door - this is to be a "colloqium". As a result, you will NOT be allowed to leave the auditorium/lobby area at any time. 29 PAGESWAPPER - February 1985 - Volume 6 Number 8 LUG Agenda We will have speakers from those who agreed to report on Anaheim Symposium sessions and then an extended Version 4.0 Forum session. Please bring you V4.0 questions, gripes, bugs and any other interesting fauna to share with us. As a teaser, did you know: 1. Any program linked with /TRACE and /DEBUG may no longer be INSTALLed with privilege? (security feature) 2. When, in the upgrade procedure you get asked if your system disk will be shared across the cluster, "reliable sources" say you should ALWAYS say "yes"? (Otherwise you will have to go through the upgrade procedure again when you change your mind). 3. Any ACCOUNT field in the SYSUAF which contains only numeric information will cause the RIGHTSLIST creation to complain? (try adding a "-") 4. In any manually configured device, you must specify "CSROFFSET" and "VECTOROFFSET" in the CONNECT command of SYSGEN? (beware of the infamous "14") See y'all there! o DFWLUG (Texas) From the DFW LUG Newsletter A list of future meetings in this newsletter has each tagged with "suggest a topic". But later on the DFW LUG offers a list of potential meeting topics for members to volunteer to present: 1. ALL-IN-1 Version 2.0 2. Comparison of relational database products 3. How I manage my VAXs 4. Security under VMS V4 5. Non-DEC equipment analysis 6. How to properly see a hardware problem corrected 7. SPRs - What they are and how to use them 8. Using SPM to tune your VAX 30 PAGESWAPPER - February 1985 - Volume 6 Number 8 LUG Agenda 9. VAX system performance 10. Managing a VAX cluster 11. What to do when your system dies 12. Disaster planning 13. The Pit and the Pendulum: VAX/VMS V4 14. Installing Ethernet 15. How to cluster your VAXs 16. Utilities on an HSC50 Finally, the Pageswapper has just started receiving newsletters from the SBVSLOCADLUG. Issue number 1 stated that the Santa Barbara, Ventura, San Luis Obispo County Area Decus Local Users Group is considering a shorter name. Editor Earl Cory of Eaton Corporation notes that the first suggestion received would have shortened the acronym from SBVSLOCADLUG to SLUG. Or since most members are from the Goleta area, he suggests they might use GLUG. Well those names may not have the unique character of SBVSLOCADLUG, but your Pageswapper editor hopes they do find some shorter name before I have to type too many articles attributed to them. 31 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot System Improvement Request Ballot Spring 1985 Everyone has an opinion about what is right or wrong with VAX. Here is your chance to influence the directions of future DEC development. The VAX Systems SIG System Improvement Request (SIR) program provides a major vehicle by which the VAX user community expresses its concerns and desires to Digital. Your opinion is important, and every ballot adds to the influence of the SIR program. Attached you will find the current collection of System Improvement Requests and a ballot form on which to record your preferences. Please take the time to review the enclosed SIR's and assess their effect on your use of VAX's. Rank your favorites by assigning them a point value. For your convenience, the ballot items have been grouped by area of interest. Also, please fill out the revised questionnaire portion of the ballot. Such information helps point out requests which are important to a particular segment of the VAX community. Please return your ballot AS SOON AS POSSIBLE. To allow time for DEC to respond, BALLOTS RECEIVED AFTER APRIL 15 CANNOT BE COUNTED. The results of the voting and DEC's responses will be given at the VAX SYSTEM SIG SYSTEM IMPROVEMENT REQUESTS session of the Spring 1985 DECUS Symposium in New Orleans. Instructions You have a total of 100 points to allocate among the SIR's on the ballot. The more points you allocate to a particular SIR, the more strongly you wish to see this feature included in the VAX or VMS. You may assign your points in either a positive sense (to encourage the change) or a negative sense (to discourage the change). In order to assure a wide range of improvements, we have limited the number of points that may be allocated to any SIR to 10. To allocate points to a SIR simply record the number of the SIR in the column labeled SIR NUMBER, and the number of points to allocate to it in the column labeled POINTS. Remember you can specify only 100 points total (i.e. +70 points and -30 points uses all your 100 points). Please note that any ballot not following the points assignment rules, or not specifying a DECUS membership number will not be counted. Only one ballot per member will be accepted. 32 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot VMS Internals ___ _________ SIR: S85-1 Abstract: Allow BACKSPACE to be equivalent to DELETE. Description: It should be possible to make the VMS terminal driver consider a BACKSPACE as equivalent to a DELETE for one or more terminals. This option should be implemented as a terminal attribute, controlled via QIO call or via the DCL SET TERMINAL command. It is acceptable that the line editing function normally assigned to BACKSPACE would be inaccessible. This feature is required because many novice users, despite exhaustive warnings, try to use BACKSPACE to correct typing errors. This confusion is also prevalent in multi-vendor sites, because most non-DEC operating systems use BACKSPACE to delete characters. SIR: S85-2 Abstract: Make the use of sharable images easier. Description: Sharable images are a very powerful feature of VMS, but are somewhat difficult to use. It should be possible to: 1. Have the linker produce transfer vector sections on request 2. Allow declaration of section attributes to be done in all compilers or in the linker. In particular, there should be a simple way to declare all FORTRAN COMMON sections to be other than /SHR/GBL. 3. Eliminate the need for the /OPTIONS file in simple cases (i.e. linking to a sharable image or producing a sharable image.) 4. Allow use of the debugger on shared images, except when protection would be violated. 33 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot SIR: S85-3 Abstract: Provide a true AND function for event flag wait. Description: The current functionality of $WFLAND is "static" or "latching" rather than "dynamic". If an event flg is set when the service is called, it is considered set for the purposes of the AND, even if it is reset again before the rest of the flags are set. Thus, if you are seeking the simultaneous setting of two flags to signal your program, you won't get it. You only get an indication the two flags were set, but not necessarily both are set at any particular time. SIR: S85-4 Abstract: Provide a means to turn off the traceback output while allowing other messages to be displayed. Description: The VMS LIB$SIGNAL facility provides a very convenient, standardized way to display error messages from a program. For most programs, it is sufficient to let the messages be displayed by the default condition handler, without interposing a user written handler. However, when the image is linked with TRACEBACK, all signalled errors generate the full traceback dump. It should be possible to selectively enable and disable the display of the traceback dump, either via a bit in the condition longword, or via a routine call. This would allow the program to display user error conditions without the traceback, while retaining the dump for unexpected or internal errors. SIR: S85-5 Abstract: Provide a means to debug another process. Description: 34 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot An appropriately authorized user should be given a mechanism to "debug" another process. This would be done via a scenario such as: 1. Posting a "pseudo-Control-Y" to the process. 2. Image merging the debugger to the image running in the process. 3. Connecting the input and output of the process back to the requesting user. There are many uses: debugging processes which must run detached, closing files, closing channels on devices such as disk or tape, investigating a "hung" batch job, etc. Obviously it is necessary to address the behavior of such a mechanism when the target process is in DCL or an inner access mode. The effects of the relative priorities of the processes must be considered. SIR: S85-6 Abstract: Change VMS's internal time representation to be a universal time. Description: The use of local time by VMS has several shortcomings, some only recently apparent. The growth of widely spaced distributed software systems (which DEC justifiably prides itself on) is inconsistent with the use of local time. Time stamps on messages, synchronization for "first in line" distributed services (such as selling tickets to a concert of the Rolling Stones), and many other distributes applications are not served well by the use of local time. Even on local applications, the twice yearly changes for daylight savings time wreaks havoc for accounting and continuous, real-time monitoring. A universal time format should be adopted and the local time should be generated by the services which produce formatted output, such as $ASCTIM. Conversion utilities could be provided for changing time stamps on files to the new standard. Appropriate SYSGEN parameters could allow a vast majority of programs to run unmodified when the change is made. Both UNIX and TOPS-20 utilize a similar scheme. SIR: S85-7 Abstract: 35 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Add a "passall" mask to the terminal driver. Description: A passall mask, similar to the break character mask currently provided by the terminal driver could be added. This would allow a user to tell the terminal driver which characters may be interpreted, and which should be passed without interpretation. This would simplify coding many applications which are required to ignore only a few VMS defined control characters. SIR: S85-8 Abstract: Add ACK/NACK protocol to the terminal driver. Description: The ACK/NAK protocol is available on some asynchronous printers. It provides more positive control than the XON/XOFF protocol currently implemented. Under this protocol, the host waits for an ACK character from the printer before transmitting another line. This is in contrast to XON/XOFF where the host must assume the printer is functioning unless it receives an XOFF. SIR: S85-9 Abstract: Provide restrictions for autobaud speeds. Description: It should be possible to specify a range of acceptable autobaud speeds on a VMS terminal port. This should selectable for each port as a terminal attribute. This feature could be used by sites to avoid the high interrupt load associated with high baud rates, while retaining the flexibility of autobaud. It would also allow the terminal driver to optimize the baud rate recognition process and thus require fewer carriage returns for baud rate detection. SIR: S85-10 36 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Abstract: Provide a service to return extended error information. Description: Many of the condition values returned from system services are not sufficiently precise (e.g. NOPRIV, no privilege for attempted operation). However, modifying the services to return more specific codes would break many existing applications. As an alternative, VMS should provide a system service which returns extended error information about the last system service failure. This would include more specific codes (e.g. which privilege was not available). SIR: S85-11 Abstract: Make CPU and memory error counts available via $GETSYI. Description: The $GETSYI system service should be able to return the error counts for CPU and MEMORY errors, such as are displayed by the DCL SHOW ERROR command. The error counts for all other devices are currently available through $GETDVI. This would allow users to very simply write a non-privileged error monitor from either DCL or an executable image. SIR: S85-12 Abstract: Provide a package to support multiple execution threads in a process. Description: VMS should provide a package which would facilitate writing multi-thread (multi-tasking) applications. This capability would allow "server" type applications to be written without the excessive resource consumption of using one process for each requestor. A similar capability is implemented in the ACMS layered product. 37 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot SIR: S85-13 Abstract: VMS should support RT-11 style file "factoring" file specifications. Description: VMS should support a notation similar to RT-11's which allows the common part of several file specifications to be "factored out" of a specification. For example, COPY DISK1:(MYF)1,2,3.FOR MTA0: would copy three files, MYF1.FOR, MYF2.FOR, and MYF3.FOR. This provides a very useful shorthand when performing file operations. SIR: S85-14 Abstract: Provide a user reserved quadword in the file header. Description: It is frequently necessary to associate application or site specific information with arbitrary files. In such cases, the data may not conform to the format of the data in the file. VMS should provide a user reserved quadword field in the file header to hold such data. This field would not be used for any purpose by VMS, but could be read and set via $QIO ACP calls and via RMS. SIR: S85-15 Abstract: Restructure VMS directories for improved performance. Description: The current structure of VMS directory files causes performance problems when directories contain many files. The time and overhead to perform even DELETE operations becomes very large when a directory contains more than a few thousand files. While knowledgeable users would use subdirectories to organize the files, there are often applications (such as loading the contents of magnetic 38 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot tapes) where this requires considerable work on the part of the user. It seems that the VMS file system could also assist by structuring directories to speed access. SIR: S85-16 Abstract: A fragmented SYSDUMP file should not prevent VMS from booting. Description: If the SYSDUMP.DMP file is expanded on a fragmented disk, it may contain too many extents to be mapped by SYSBOOT. Currently, this prevents VMS from booting. This requires the system disk to be dumped and reloaded at what may be a particularly inconvenient time. The VMS V4 SHUTDOWN option will at least detect the occurence of the problem. However, it should be possible to reboot a system in this condition, suppressing the creation of a crash dump. A suitable warning message could be generated. This would allow the problem to be corrected at a later, more convenient time. SIR: S85-17 Abstract: Allow system date to be automatically be set. Description: When VMS requires the system date and time to be reset, it normally prompts on the operator console. This can prevent a reboot from happening when the system is unattended. VMS should provide an option which would limit the wait time at this prompt, and cause an approximate date and time to be obtained from the disk. The most reasonable source for such a time would be the time stamps recorded in the VMS error log. As an alternative, a separate time stamp could be maintained in a known location on the system disk. SIR: S85-18 Abstract: 39 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Provide a mechanism for accessing group global sections from a different UIC group. Description: Currently, access to global sections is normally qualified by UIC group number. This makes it difficult to create applications which may be run under various UIC groups. There should be a supported mechanism by which a suitably privileged user could map global sections belonging to another UIC group. Alternatively, the distinction of group vs. system global sections could be removed if global sections could be protected in the same manner as files and devices. SIR: S85-19 Abstract: Allow an image to be installed with a priority and UIC. Description: The ability to allow a user a priority boost or decrement while running an image would be a great help in a heavily loaded interactive system. The ability to run with a UIC other that the owner's is a great help in cases where mailbox communication is necessary. The VMS INSTAL utility should allow both of these conditions to be specified, in the same manner as enhanced privileges. SIR: S85-20 Abstract: Support a "time change" AST. Description: VMS should allow one to enable a "time change" AST to be delivered anytime the system time is changed via the $SETIME system service. This would allow programs (such as the Job Controller) to properly re-synchronize their timer requests. Currently, an application has no way of detecting this inconsistency and can not even attempt any recovery action. SIR: S85-21 40 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Abstract: Provide a unique name generation service. Description: A facility is needed to supply programs and DCL procedures with unique names suitable for files and other global resources. This name should be unique across a system boot and across an entire cluster. This facility is particularly important for programs and procedures which generate scratch files. Without it, there is no reliable mechanism for preventing two processes, running from the same directory, from interfering with each other. SIR: S85-22 Abstract: Support a standard print control format for printable files. Description: VMS tools, utilities, and programs use an almost capricious variety of carriage control formats when producing human readable output files. This include FORTRAN style carriage control, implied carriage control, and PRN style carriage control. A particularly troublesome practice is creating multiple lines of printed output by embedding ASCII control characters in a record. This is done in the listings from several compilers. This variety of formats causes considerable problem when the files must be transferred through a heterogeneous network for final printing. All DEC supplied software should be modified to produce one standard carriage control format. At a minimum, DEC should supply a utility which can convert any printable file to a standard format. SIR: S85-23 Abstract: Document the interfaces required to create cluster wide resources. Description: 41 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot DEC should document the interfaces required to create cluster-wide sharable resources. This would include the information necessary to interact with the Connection Manager. This information is required to allow high-performance, expensive peripherals (such as floating-point processors) to be shared in a cluster. Given that the cluster support is new and not fully evolved, it is accepted that major, incompatible changes could occur in this interface in future releases of VMS. SIR: S85-24 Abstract: Provide convenient function for testing file access. Description: VMS should provide an RTL function for testing if a particular type of standard access (READ, WRITE, EXECUTE, DELETE) is available to a file. The $CHKPRO system service provides this capability, but appears to require considerable setup to test a file. A simple routine which uses only the filespec and desired access as input would simplify writing many applications. DCL and Utilities ___ ___ _________ SIR: S85-25 Abstract: Make the syntax of SHOW QUOTA consistent. Description: The SHOW QUOTA command has inconsistent syntax. All DCL commands which may specify a UIC as an optional parameter do so with the /OWNER_UIC or /UIC qualifiers. SHOW QUOTA uses the qualifier /USER. It should be modified to accept the two standard qualifiers as well. SIR: S85-26 Abstract: 42 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Provide a DCL WRITE command that will not advance to the next line. Description: The DCL WRITE command should have an option to prevent the output device from advancing to the next line. For example, WRITE/NOADVANCE FOO "Text1" WRITE FOO "Text2" would produce a single line of output: Text1Text2 This would be particularly useful when using DCL to send escape sequences to a terminal, for example to set up an attached printer. The carriage-return line-feed sequence must be suppressed to avoid unwanted repositioning on the terminal or printer. SIR: S85-27 Abstract: ANALYZE/RMS should provide a record count on sequential files. Description: Part of the output of ANALYZE/RMS of an indexed file is the number of records in the file. This information should be available for sequential files. Since this would require reading the entire file, it should be an optional item. SIR: S85-28 Abstract: Add a /VERIFY qualifier to the "@" command. Description: It would be convenient to have a qualifier which would turn on procedure verification for the duration of one command procedure. Possibly this qualifier should override SET VERIFY and F$VERIFY() commands issued within the procedure. This would enable normally "quiet" procedures to be monitored without the need to modify them. 43 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot SIR: S85-29 Abstract: Enable DCL READ command to extract fields from a record. Description: Currently the DCL READ statement returns the entire contents of a record into a DCL symbol. READ should be enhanced to be able to divide the record among several symbols. For example, READ FOO BAR(1:10), BAZ(13:15), ... would return characters 1 through 10 of the record in symbol BAR, characters 13 through 15 in BAZ, etc. In addition, a simpler, delimiter-based format could also be supported: READ/DELIMITER=";" FOO BAR,BAZ,... would extract the fields delimited by the specified character. SIR: S85-30 Abstract: Add /UIC and /IMAGE qualifiers to SHOW SYSTEM. Description: The SHOW SYSTEM command should allow the display to be limited by process UIC. This is much the same as the /BATCH and /SUBPROCESS qualifiers that currently exist. A /IMAGE qualifier should also be added which would display the image currently being executed by the process. SIR: S85-31 Abstract: Allow DCL to be extended with site-supplied lexical functions. Description: 44 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Each site has some peculiar function which needs to be accessible in DCL. Such a function is most conveniently implemented as a lexical function, so that its result value can be used in expressions, etc. It should be possible for the site to add such lexical functions to DCL. SIR: S85-32 Abstract: Enhance the SEARCH utility. Description: SEARCH would be much more useful if it allowed more elaborate specification of the pattern to be searched for. SEARCH should support some notation for complex pattern matching, much like UNIX regular expressions. Such a notation would allow "wildcard" matching of such things as alphabetic characters, numeric characters, "word" and "delimiter" characters, beginning of line, end of line, etc. It should also be possible to restrict the column positions in which a pattern matches. For example, SEARCH/MATCH=AND "ABC"/POS=1, "DEFG"/POS=27 would restrict the search for the patterns to the specified character positions. Ideally, SEARCH might use RMS keys if the file was indexed and hey coincided with the specified positions. Finally, SEARCH should be available through a callable interface. SIR: S85-33 Abstract: Add /EXCLUDE option to MAIL SEND command. Description: The VMS Personal Mail Utility provides distribution lists for sending mail to a group of users. It would be useful to be able to selectively exclude people named in distribution lists if mail is not relevant to them. This avoids the necessity of keeping numerous lists with only small differences. It should also be possible to take the 45 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot exclusions from a distribution list, e.g. To: @STAFF.DIS/EXCLUDE=@VACATIONS.DIS SIR: S85-34 Abstract: The DCL foreign command mechanism should optionally return an unedited command line. Description: The command line available through the LIB$GET_FOREIGN is converted to upper case characters by DCL. It should be possible to obtain the command line without such conversion. This would aid in the migration of programs from operating systems which use mixed-case command lines. SIR: S85-35 Abstract: Provide system-wide and job-wide DCL symbol tables. Description: The DCL symbol capability should be expanded in somewhat the same manner as the VMS logical name facility. It should be possible to define a class of symbols that are common to all processes in a job. This would simplify communication between a subprocess and its parent. Most sites define a large number of DCL symbols in the SYSLOGIN procedure. Login overhead could be reduced if a class of system wide DCL symbols was available. A suitably privileged user could make all the site-wide definitions in one place, and could insure that all changes occurred at the same time for all users. System Management ______ __________ SIR: S85-36 Abstract: 46 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot BACKUP should stop searching a save set when it is no longer possible to encounter the selected files. Description: Currently, the BACKUP utility will search an entire save set for files selected in a restore operation. As a result, multiple tapes may be processed even if the desired files were located on the first tape. BACKUP should make use of all available information about the ordering of files in the save set to avoid needless searching. At a minimum, this capability should be available when the ordering of files must be strictly alphabetical, for example an image mode save set. Ideally, BACKUP should support this capability even if the input specifier included a list of directories or files. SIR: S85-37 Abstract: BACKUP/LOG should display volume switch information. Description: The BACKUP /LOG and /LIST output should be enhanced to display messages indicating the occurence of a tape volume switch. In addition, an option is needed which causes only the volume switch messages to appear, along with messages indicating the files which immediately bracket and/or span the volume switch. These additional messages are needed to simplify the process of restoring individual files from multi-tape backups. SIR: S85-38 Abstract: Provide capability for ERF to run with input from MAILBOX. Description: The SYE utility provided a capability to specify INPUT FILE=MAILBOX which caused SYE to run continuously as a "real-time monitor" of ERRLOG entries. Thus SYE could be run as a detached process continuously logging to a terminal. Many system managers now depend on this capability. ERF, which is the VMS V4 replacement for SYE, does not provide an equivalent capability under user 47 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot control. This capability must be restored to VMS users and system managers. This capability is required independent and irrespective of any other facilities such as VAXsim. SIR: S85-39 Abstract: VMS should log the fact that one process was stopped by another. Description: VMS should make an entry in the accounting record of a process if that process is stopped by another process. The entry should show the Process ID of the process causing the termination. This would provide some measure of accountability and aid in tracking malicious users. SIR: S85-40 Abstract: BACKUP should release the tape drive before beginning a date recording pass. Description: During the backup of large disks and volume sets, the date recording pass can take 15 minutes or longer. During this time, the tape drive is unavailable for other work (such as beginning other backups). The BACKUP utility should have an option which allows it to dismount and deallocate the tape drive before it begins the recording pass. This would significantly reduce the elapsed time required for many backup operations. SIR: S85-41 Abstract: Improve BACKUP's capabilities for verifying the integrity of a copy. Description: 48 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot The BACKUP utility has two qualifiers to enable checking of a copy with the original - /VERIFY and /COMPARE. The /VERIFY qualifier, however will cause the backup operation to terminate if differences are found, regardless of whether or not that was intended. The /COMPARE qualifier requires another BACKUP command to be performed. It would be useful to provide an option of /VERIFY which would enable completion of a copy operation, even though there may be errors. This option would cause BACKUP to report which file(s) were different and would thus let the user decide whether or not to abort the operation. SIR: S85-42 Abstract: Add a soft error warning to BACKUP. Description: It is disconcerting to complete a multi-tape backup to discover that there were several hundred soft errors somewhere during the run. BACKUP should have an option which enforces a soft error limit. When this user specified limit is reached, user (or operator) intervention should be requested. The user should have the option of continuing in spite of the limit, aborting the backup, or restarting the current volume with a new tape. SIR: S85-43 Abstract: Expand STANDALONE BACKUP to allow the use of some subset of DCL. Description: The STANDALONE BACKUP utility requires the user to type the BACKUP command line manually. Often this command can be rather large and complex. In the hands of a less knowledgeable user, an error in the command line can have disastrous effects. It would be useful to be able to use a command file to invoke the utility. If some subset of DCL were available it would be easy to prompt the user through the BACKUP process. SIR: S85-44 49 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Abstract: Expand MONITOR to provide more information on kernel mode usage. Description: MONITOR should have an option which collects and displays additional information about kernel mode CPU usage. In order to tune a system, it is necessary to locate bottlenecks. MONITOR could assist by providing a breakdown of kernel mode time into such categories as image activation, XQP processing, paging overhead, scheduling overhead, QIO processing, etc. SIR: S85-45 Abstract: Provide an screen editor interface to AUTHORIZE. Description: VMS should provide a screen oriented extension to the AUTHORIZE utility. This would simplify the increasing complex task of adding and maintaining usernames. This facility should be based on the new TPU editor and should be user extensible to allow for local enhancements. Commercial __________ SIR: S85-46 Abstract: Enhance the ALLOCATE command. Description: Enhance the ALLOCATE command to enable a user to optionally queue the allocation request when all qualifying devices are busy. Device allocation should be handled by a queue manager similar to the VMS V4.0 print queue manager, and the allocation request queues should be made cluster wide to support HSC50 based RA60's and TA78's. User functions should include the ability to specify 50 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot characteristics required of a generic device, the automatic notification of allocation, the ability to delete an allocation request, the ability to examine the allocation request queue, and the ability to do other interactive processing while waiting for an allocation request to be granted. Operator functions should include the ability to mark failing devices as unavailable and the ability to force a deallocate. Manager functions should include the ability to define device characteristics and specify physical devices as possessing those characteristics. Device allocation and deallocation should place records in the accounting file so that charge back accounting can be done for allocated devices. A mechanism for avoiding deadlocks when multiple devices are allocated should be provided. Examples: $ ALLOCATE/QUEUED/WAIT TAPE$CLASS:- /CHARACTERISTICS=(DENSITY:6250) LOGICAL_TAPE (Queue an allocation request for a tape drive with 6250 bpi capability and wait until the allocation has completed.) $ ALLOCATE/QUEUED/NOWAIT/NOTIFY DISK$CLASS:- /CHARACTERISTICS=(RA60) MY_DISK_PACK (Queue an allocation request for an RA60 disk drive and return control to my terminal. Notify me when the allocation has completed.) $ ALLOCATE/NOQUEUED TERMINAL$CLASS:- /CHAR=(AUTODIAL,BAUD:1200 DIAL_OUT_MODEM (Allocate a terminal device with a 1200 baud autodial modem but don't queue the request. Give an error if all such devices are allocated.) SIR: S85-47 Abstract: Provide support for project accounting. Description: In every organization that we are familiar with, VMS users divide their time between two or more projects, and the set of projects that any one user works on changes with time. 51 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot In contrast, VMS authorization records impose an organization in which a user can belong to one and only one account. VMS should provide users with the ability to charge their computer resources to multiple projects, a feature which we refer to as Project Accounting. Project Accounting should include a SET PROJECT command to quickly change the current project being charged, and disk and CPU time quotas should be based on Project designation. Batch, Print, Network, and Detached jobs should inherit the Project designation from the process issuing the SUBMIT, PRINT, or RUN command. Project Management should be separated from the System Management and distributed in a hierarchical fashion. Disk quotas and CPU time quotas should be controlled by the Project Management. A system service should be provided which enables privileged programs to flush the accumulated charges of a process to the accounting log. SIR: S85-48 Abstract: Develop class based scheduling facilities for VMS. Description: Under VMS, a long, compute-bound batch job can prevent a lower priority batch job from getting many computes. With a Class-type scheduler, one can specify that a specific class of users get at most a fixed percent of the available computes; various methods are available for handling the "leftover" portions of the process (which exist when not all classes are on the system at the same time). Also, Class-type schedulers can emulate preemptive schedulers. The system should degrade "gracefully" under load, not suddenly. CPU time guarantees do not answer the problem entirely, since this concept really addresses the inverse of the above: the ability to specify that a given class gets AT LEAST a specified percentage of the processor. Such implementations would normally be under stricter administrative controls, to avoid over-subscribing of the available resources. With clustered systems, a class scheduler may rapidly become a necessity. One of the major market needs is for machines to act as compute servers, so that entire machines 52 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot need not be dedicated to single applications. This will not be feasible unless resources can be partitioned in a definable and reproducible fashion. SIR: S85-49 Abstract: Implement a tape volume management system. Description: As systems get larger, they will support more and more users. similarly, disk technology will result in larger and larger disks. Both changes will generate significantly more usage of tapes for backup, archiving, intersystem interchange, etc. It dos not take long for several hundred tapes to accumulate. A library like this is difficult, if not impossible to manager manually, A tape management system would track tape usage, indicate which tapes are free, act as a locator tool and generally assist in tape management. SIR: S85-50 Abstract: Provide a 3279 work station emulator for the VT241. Description: Many large companies operate in a mixed vendor environment including one or more IBM systems. Most such sites have in place mechanisms for performing file transfers between the systems. It would also be useful to be able to initiate interactive systems to the IBM through a VAX. This would allow use for use of existing terminals both at work and at home. DEC's 3271 Protocol Emulator is a step in the right direction. This capability should be extended to support the IBM 3279 color and device attributes on the DEC VT241. SIR: S85-51 Abstract: Add a PRINT qualifier to line number listings. Description: 53 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot It is sometimes useful to have a listing of a file that includes line numbers. This is the case where errors in a file are identified by line number. While it might be possible to add this capability via a user modified symbiont, it seems that such a capability is important enough to be a supported feature. SIR: S85-52 Abstract: Add wildcard support to the ACCOUNTING utility. Description: The ACCOUNTING utility should allow the use of "*" and "%" wildcards in all selection fields that make sense. This would allow easy specifications of groups of values which would otherwise be difficult to enumerate, and perhaps require multiple runs of the utility. SIR: S85-53 Abstract: ACCOUNTING should produce accurate histograms. Description: The ACCOUNTING utility /SUMMARY=(HOUR,USER)/REPORT=(ELAPSE) lumps the total elapsed time into the hour slot in which the process or image terminated. This is clearly inaccurate, and necessitates additional work to obtain an accurate picture of the workload. The utility should properly prorate the elapsed time generating this report. Languages and Tools _________ ___ _____ SIR: S85-54 Abstract: TECO should be provided as a 100% native mode image under VMS. 54 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Description: An enormously powerful, general purpose utility is provided with VMS. It is also used quite often as a text editor. It is called TECO. Currently, TECO is implemented as a PDP-11 compatability mode program, embedded in a native mode image which performs its I/O and operating system interface. Besides the obvious benefits of increased execution speed, a full native mode TECO would allow its use on VAX's not supporting compatability (e.g. MicroVAX I). Also, it would provide a solid foundation for the implementation of new features in TECO (i.e. some of the TECO-10 constructs, callable TECO, etc.) Additionally, consideration should be given to the unique ergonomic attributes of the new VT200 series terminals. Give the placement of the ESC and angle bracket keys, a general purpose character remapping facility inside TECO might be the most flexible solution. SIR: S85-55 Abstract: Compilers should have a switch that optimizes compilation, ___________ in addition to the switch which optimizes compiled code. Description: In an educational environment the running of compilers far exceeds the running of compiled code. A switch is needed to direct the compiler to produce the code as quickly as possible. This switch must go beyond what the /NOOPTIMIZE does, and is particularly desired for FORTRAN, BASIC, and PASCAL. SIR: S85-56 Abstract: Provide a /INCLUDE qualifier on compilers to specify where the compiler should look for include files. Description: Source code from other sites does not always contain logical names for include files. This necessitates having include files in the same directory as the rest of the 55 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot source code. The /INCLUDE qualifier could be used to facilitate organizing source files into different directories. SIR: S85-57 Abstract: Provide an option to VMS compilers and RUNOFF to produce an output file that contains both the source code in it's unmodified state and the error messages. Description: It would be very convenient to correct syntax errors in source files if the location of each error was marked in the source file. With a marked up source file, a full screen editor could be used to search for the next error message, remove that error message, and correct the syntax. Errors would be marked with unique markers to facilitate searching. SIR: S85-58 Abstract: Provide a way to debug in a shareable image. Description: It is not possible to use the debugger on a shareable image. For tracing problems within a shareable image, this facility would be very useful. SIR: S85-59 Abstract: EDT should display a warning when EXIT will cause a change in file structure from indexed to sequential. Description: EDT will allow manipulation of the data records in an RMS indexed file. However, the user is not warned that EXIT will create a sequential output file. This can cause severe performance problems for applications, such as DATATRIEVE, which do not care what file structure is in 56 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot use. SIR: S85-60 Abstract: Provide a way in EDT to search for the next occurence of a string that was just deleted. Description: It is desired to locate the next occurence of a string that was just deleted. This might be implemented via defining a key. The editor must "remember" the deleted string when moving from buffer to buffer. SIR: S85-61 Abstract: Improve the way EDT does buffer operations. Description: There are several inconvenient features in the way EDT manipulates buffers: 1. EDT needs to be able to manipulate buffers without going into those buffers (e.g. read file XYZ.DAT into buffer TMP and remain in the main buffer). 2. When entering a buffer, you should be placed at the beginning of the buffer, instead of the end. 3. The entire contents of a buffer should not be displayed when you enter that buffer. SIR: S85-62 Abstract: FORTRAN needs a format specifier that will insert a digit separator into long numbers. Description: 57 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot A FORTRAN format specifier is needed to insert a digit specifier into long numbers. This capability would be especially useful for business applications. The readability of FORTRAN output would be enhanced by this feature. Security ________ SIR: S85-63 Abstract: User-controllable mechanism needed to allow other users to access a file only via a user-defined image. Description: Non-privileged users sometimes need to give other non-privileged users controlled access to data files through a program. Through this facility any user would be able to control who could access his data files and what kind of access they may have. In the current system, in order to allow another user to add a record to a file, that user must be given WRITE access to that file, which means he could alter existing data or delete records from the file. Presently this requires the system manager to install the program with privilege, which is both an administrative nuisance and a security problem, as the privileged image would also have access to other system data files as well as the intended files. This mechanism should be under user control, i.e., the user should be able to specify which images could access a file. For example, the UIC of the image and data file should probably be required to match before access would be permitted. This could be accomplished by an option on the compiler or linker when the image was being created. It could also be implemented by allowing the system manager to install an image with a particular Identifier (VMS 4.0) and then setting up the access control list for that file to permit access by that Identifier. This would be less flexible but would permit a user to allow access from images other than his own, e.g., a data base manager. SIR: S85-64 Abstract: 58 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Implement government standard security classifications for files (i.e., unclassified, confidential, secret, and topsecret) and control access to files based on individual user's security clearance. Description: Many VAX systems are being operated by government agencies or contractors and either are processing or need to process classified data. Such a facility would make system management much easier for existing systems and would encourage more VAXes to be used for classified processing. The system manager should be able to specify a security level for each user account using the AUTHORIZE utility. When a file is created, it should be given the security level of the creating process. If the file is edited or copied, it should retain it's classification. A utility should be provided to allow a person with a (SECURITY) privilege to change the classification of a file. SIR: S85-65 Abstract: End-to-end DES encryption should be provided within DECnet-VAX. Description: The VAX/VMS system should support end-to-end DES encryption within DECnet-VAX with a separate DES key being used for each DECnet logical connection. This should be implemented at the NSP level, so that it is transparent to the user. The system manager should be able to activate or deactivate DES encryption between his VAX and any other VAX (that supports that feature). Privileged users on intermediate nodes can read and/or modify data being routed through their nodes or observe data in transit across an Ethernet, and not all nodes in a large DECnet network are equally trustworthy. End-to-end DES encryption would serve to protect this data in transit. Also, DES might be used to protect need-to-know access to classified data in a network. SIR: S85-66 Abstract: 59 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot Better node authentication should be provided by DECnet-VAX. Description: The node authentication provided by DECnet-VAX in the form of node transmit and receive passwords is woefully inadequate. Not only is it easily circumvented, but it is only applicable to adjacent nodes. A better node authentication capability is desired, perhaps one that is encryption based, so that a system can have a high degree of certainty that the nodes with which it is communicating are who they claim to be. Note that it is not necessarily desired that all data be encrypted, as that may entail a high overhead. Also, although this request pertains to DECnet rather than simply to VMS, it is necessary to have adequate node authentication within DECnet in order to ensure the security of a VAX within a DECnet network. Large Systems _____ _______ SIR: S85-67 Abstract: VMS should implement tape automatic volume recognition and provide the security normally associated with volume labeling. Description: VMS should provide a complete implementation of automatic volume recognition for tapes, that may be enabled/disabled by the operator on a per drive basis. This means that (with AVR enabled), when a tape is mounted, the system checks possible labels and honors mount requests without operator intervention, if possible. If a job needs 4 tapes, the operator can mount them all if enough drives are available and then forget about them until somebody else needs the tape drives. It should also be possible for a user to request a tape mount based solely on the tape's label and density. The user should not be required to know what physical devices implement a particular tape density on a particular system. VMS should also support a "visual id" or "slot number" which is displayed in all operator messages related to the mount. It should be possible to operate a VMS system in a mode where all tapes are under system/operator control. This means that they are pre-initialized and users are not 60 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot allowed to change the labeling on the tape without special privilege. The BACKUP utility must also conform to such labelling restrictions, thereby insuring that the BACKUP data is written onto the proper reels. VMS should require explicit operator intervention for unlabeled tapes. It is not acceptable that an unlabeled tape which happens to be on a drive be automatically assigned. SIR: S85-68 Abstract: Provide a true file archiving system for VMS. Description: VMS should provide an archiving/restoration facility for disk backup which is as automatic as possible. It should make possible a very short latency period between the time of file creation and the time when a file is backed up for safety. It should respond to users' requests for restoration of files with the least possible uncertainty or ambiguity as to the files' whereabouts, and should also enable safe, reliable reconstruction of entire disk structures. A new approach is needed which eliminates as much as possible the need for human (particularly operator) intervention in the process, and which does not disturb the continuous operation of the system (i.e. the archiving and restoration operations must take place on line during normal timesharing operation). SIR: S85-69 Abstract: Provide intelligent help and command/filename completion. Description: A command-and-filename completion and integral help facility should be created, along the lines of the TOPS-20 Command JSYS. It should become a part of Digital's standard for command languages. Command input processing from hardcopy terminals should be particularly addressed. Help is available on VMS, but it would be useful to have this information available as the command is being typed, where it is necessary to get the next option to be entered. TOPS-20 also provides for automatic command completion, fill in of keywords, and filename completion. The latter 61 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot will become particularly important on VMS with the advent of long file names. SIR: S85-70 Abstract: Provide for single command initiation of the edit, compile, link, execute sequence. Description: VMS should have COMPILE, LOAD and EXECUTE commands, which work as in TOPS-10/20 to provide successive invocations of compilers, linkers/task builders, and executions. The system automatically determines when it is necessary for a source program to be recompiled. Editors should have the ability to return to the compilation step, and compilers the ability to call editors, as a rapid means of interactive debugging. SIR: S85-71 Abstract: Provide for a DELETE at logoff capability. Description: VMS should provide a feature which allows files to be "deleted" by marking them for deletion at logout. This would allow a user making a mistake to reverse the error with an UNDELETE command. It should also be possible for the user, or the operator, or the file system to initiate an immediate cleanup of such deleted files if necessary to free disk space. SIR: S85-72 Abstract: Allow mixed 32 and 36 bit systems on a CI. Description: Many sites are faced with the need for coexistence and migration between VAX's and DECsystem 10's and 20's. It should be possible for VAX's and 36-bit systems to coexist 62 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot on the same CI. One HSC-50's should be able to serve both types of system with disks. This would allow HSC-50's and disk spindles to be easily moved between the two types of systems as workload required. It is not necessary that either system be able to read the other's file structures. SIR: S85-73 Abstract: Provide time stamping in batch jobs. Description: VMS should provide a command which will cause each line of a batch job log to be time stamped. This would allow events in the job to be correlated with outside events. It also provides a solid record of the progress of the job through its various steps. Miscellaneous _____________ SIR: S85-74 Abstract: Provide a service which returns information about DECnet. Description: VMS needs a system service to provide information about DECnet. As DECnet becomes an integral part of VMS, it is only natural to provide a system service in the style of $GETJPI or $GETSYI. $GETNET would provide information about the network content. Currently, the only way a program or procedure can obtain information about the network is to do either a "SHOW NETWORK" or read the DECnet database. $GETNET would provide a clean interface between DECnet and user programs. Suggested features include: 1. Use an item list in the form of $GETJPI and $GETSYI. 2. Provide information by node name or number. 63 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Ballot 3. Provide a wildcard capability such as $GETJPI provides for processes. 4. Be able to request information from either the volatile or permanent databases. The information that would be of use includes: 1. Node name or number 2. Remote operating system (VMS, RSX, etc.) 3. Version number of remote operating system and remote DECnet. 4. Network device. 5. Current node status (reachable or not) 6. Node counters. 7. Other information that is currently in the database. This service should also be available as a DCL lexical function. Such a facility would make it very easy to write programs and procedures which collect statistics on network operation. It would also simplify creating complex network applications which must function in a highly dynamic network. Such functions as message and file store-and-forward requires that the application easily obtain information about the network status. At a minimum, any existing program interface which can provide this information should be documented. 64 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX Systems SIG Spring 1985 SIR Ballot VAX Systems SIG Spring 1985 SIR Ballot Questionnaire DECUS membership number __________________ My VAX experience level (check one): Wizard ____ Expert ____ Knowledgeable ____ Normal ____ Novice ____ ------------------------------------------------------------------ Our site uses the following VAX models (check all that apply) 8600 ____ 11/782 ____ 11/780,11/785 ____ 11/750 ____ 11/730,11/725 ____ MicroVAX ____ Our site uses the following operating systems (check all that apply) VAX/VMS ____ VAXelan ____ ULTRIX ____ UNIX (tm) ____ RSX-11 ____ RSTS ____ RT-11 ____ IAS ____ TOPS-10 ____ TOPS-20 ____ Other ____________________________ We are currently running VMS Version __________ (if applicable) ----------------------------------------------------------------- We use VAX's in the following applications (Check all that apply) Business EDP ____ Software Development ____ Education ____ Computer Science Research ____ Real-Time Processing____ CAD/CAM ____ Service Bureau ____ Hardware Development ____ Scientific/Engineering ____ Office Automation ____ Other ____________________________ Our principal programming language is _________________________ 65 PAGESWAPPER - February 1985 - Volume 6 Number 8 VAX Systems SIG Spring 1985 SIR Ballot VAX SYSTEMS SIG SPRING 1985 SIR BALLOT Tally Reminder: The total number of points (absolute value) which you allocate on this ballot may not exceed 100 points. No more than 10 points may be given to any single SIR. YOUR BALLOT MUST BE RECEIVED BY APRIL 15 TO BE COUNTED. SIR Number: Points: ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ ___________________ __________________ Mail to: Mr. Gary Grebus Battelle Columbus Laboratories Room 11-6011 505 King Avenue Columbus, Ohio 43201 USA 66 PAGESWAPPER - February 1985 - Volume 6 Number 8 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: PAGESWAPPER Editor, DECUS, 249 Northboro Road (BPO2), Marlborough, MA 01752, USA 67 PAGESWAPPER - February 1985 - Volume 6 Number 8 INPUT/OUTPUT Submission Form Tear out to submit an I/O item PAGESWAPPER Editor DECUS 249 Northboro Road (BPO2) Marlborough, MA 01752 USA 68 PAGESWAPPER - February 1985 - Volume 6 Number 8 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) 69 PAGESWAPPER - February 1985 - Volume 6 Number 8 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories Room 11-6011 505 King Avenue Columbus, Ohio 43201 USA 70