PAGESWAPPER It's Time for Tapecopy Submissions by Joe Bingham, VAX Systems SIG Librarian It's time to get your submissions ready for the tapecopy project for the Cincinnati symposium. As usual the VAX Systems SIG will be collecting submissions for the tape at the symposium, putting the tape together after the symposium and distributing it to LUG librarians via a tree distribution scheme. There is one major change to the distribution scheme for this symposium: the nodes in the Northeast region will not be on the tree. Instead they will get the tape through DECUS's National LUG organization. If you want to make a contribution to the tape, please follow these guidelines: a. Construct an AAAREADME.TXT file for your submission. Include your name, address and phone number, a note concerning your willingness to accept phone calls or answer mail concerning your submission and a short description of the submitted material. It will help me put the tape together if you will make this file a Runoff file and include the .RNO file on your tape. I have provided a file, [VAX000]TEMPLATE.RNO, on all of the recent tapes with the necessary runoff commands in it. b. Include documentation. Use a .DOC file extension for your documentation files. PAGESWAPPER - May 1984 - Volume 5 Number 11 It's Time for Tapecopy Submissions c. Include sources. The way you do something is frequently more useful than what you are doing. E. g. a program calling the Watzit system service might be very helpful to someone trying to use that system service for the first time. Also, security-conscious system managers and system programmers are leary of running programs which they did not compile and link on their own machines. d. Include necessary libraries but do not include superfluous libraries or unused and undocumented modules. e. Submittors sometimes forget that their program includes or links to something on another directory. Do not make that mistake. f. Other easily overlooked aspects of the environment are symbols and logical names. Be sure to describe them or include a command procedure to set them up. g. Before making the tape, clean up the directories you are going to copy. Do not include material which adds to the bulk but not the utility of your submission. h. Be sure you initialize your tape for 1600 bpi density. It is almost always hard to handle other densities during the symposium. i. Use either COPY or BACKUP to make the tape (BACKUP preferred). Indicate the number of files on a label on the tape and on the submission form. A hard-copy directory or BACKUP listing is nice to have. j. Turn in your tape at the Library Booth Monday or Tuesday. You will have to sign a release form so be sure that you are authorized to do so or bring a properly executed release form with you. Tapes should be picked up at the Library Booth on Thursday or Friday. SOMETHING NEW FOR CINCINNATI. You will be able to send me mail on one of the VAXs at the symposium. So, if you have something to say about Tapecopy or my role as VAX Systems SIG Librarian it will be convenient for you to do so. I expect the name of the account to be VAXTAPE. By the way if you have an account on the DECUS Communications System VAX you can send me mail anytime. My username is BINGHAM and I check my mail at least once a week. Joe Bingham ManTech International Corporation 2320 Mill Road Alexandria, VA 22314 (703) 838-5600 and ask for the phone number of my on-site location. 2 PAGESWAPPER - May 1984 - Volume 5 Number 11 In this issue... In this issue... It's Time for Tapecopy Submissions . . . . . . . . . 1 In this issue... . . . . . . . . . . . . . . . . . . 3 Editor's Workfile . . . . . . . . . . . . . . . . . 4 Trials and Tribulations of Running IAS on Your VAX! 5 More BECOME.COM . . . . . . . . . . . . . . . . . . 7 Westinghouse Report on Fall 1983 Symposium . . . . . 8 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . 47 VAX System SIG Committee List . . . . . . . . . . 50 INPUT/OUTPUT Submission Form . . . . . . . . . . . 53 System Improvement Request Submission Form . . . . 55 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). 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. 3 PAGESWAPPER - May 1984 - Volume 5 Number 11 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor I received a copy of a Hughes Aircraft Company memo written by P. Bjorndahl with a mechanism for a process-specific debug prompt (the memo was received in hardcopy form, so is not reproduced in full). Essentially the idea is to make a separate copy of the debugger and patch it, for instance with: PATCH>d/as 331df NEW> 'DB1>' NEW> exit PATCH>d/as 331e6 NEW> 'DB1>' NEW> exit PATCH>update PATCH>exit (note that the string above should probably not exceed 4 characters) And then at runtime in a DCL command procedure run in the subprocess before starting the image: $ DEFINE LIB$DEBUG dirx:DEBUG Looks like a great idea for those who find themselves needing to distinguish multiple debuggers running from the same terminal. DEC ought to do it in source giving (as a user option) the first n (user-specified) characters of the process name. In the past few months I seem to have been getting a lot of submissions and offers of submissions regarding optimizing Fortran I/O under VMS. My inclination is to publish them, providing they are not precisely duplicative of one another. I have not, for example, gotten any angry letters from readers demanding that we lay off the Fortran. Then, again, those of other religious persuasions may be sitting back smugly with the knowledge that THEIR chosen language has perfect I/O facilities. Coming in June to a Pageswapper near you -- we plan to have an article on optimizing the operation of an FPS AP-120B array processor on a 780. The co-authors are Magdy A. Eletreby and Chuan C. Kao, the latter who was victimized in March when I stole all his plus signs. It is so nice to have forgiving contributors! 4 PAGESWAPPER - May 1984 - Volume 5 Number 11 Trials and Tribulations of Running IAS on Your VAX! Trials and Tribulations of Running IAS on Your VAX! subtitle: How not to BREW a VAX! By Art McClinton MITRE Corporation A few of you probably will remember the April fools article that I published several years ago in this same journal. Just in case you do this article is true and although it sounds like an April fools joke, it is not. Let me set the stage. I work in a mixed vendor shop. We have a VAX 11/780 running VMS, and 5 PDP 11's running IAS. Different repair people come to fix the machines. Also different software people come to talk to us about software. We have had no problems with the IAS operating system. It supports all of the peripherals that we have and it does not crash. Well almost never; once DEC missed two consecutive PM's and after 78 consecutive up days the main real time application found an internal design flaw and crashed the machine. We now reboot every 30 days whether DEC shows up or not. Back to why this is being submitted to the VAX SIG newsletter. Last January we received an update to IAS DECnet. It showed up on a BRU tape! This might not seem strange to you former RSX 11M users, but for us using RSX 11-D or IAS this was indeed a first. We are still running IAS 3.0 and that does not include BRU. We were at a loss as to what to do. A quick call to DEC resulted in the advice that if we upgraded to IAS 3.1 that it included a copy of BRU. Having heard so many war stories about the bugs introduced in this release we tried to run BRU under IAS 3.0. This did not work. Remembering a Pageswapper article about how to run BRU on your VAX, and being of unsound mind I loaded the BRU from the IAS 3.1 distribution onto the VAX and tried to run it in compatibility mode. It immediately came up and every thing seemed fine. We dumped a short BRU tape onto a scratch pack and looked over the data. Next, I turned it over to a co-worker and left for a class I was taking. After class I went home and found a message from my computer operator to please come back to the office. It seems that BRU, if you do not set the switches correctly will initialize a pack and write the tape to the first n blocks of the pack. My user RP06 had some how become the target of a 1000 block BRU tape. Since it was a Friday I set in motion the procedure to restore the backup disk and incrementally add the files of the week since the disk was created. It was during this period that I found the hole in my BACKUP procedure. The tape drive used by 5 PAGESWAPPER - May 1984 - Volume 5 Number 11 Trials and Tribulations of Running IAS on Your VAX! the operator was bad and I could not read any of the BACKUPs. The logs created during the backup indicated the errors but the operator had merrily filed them without reading them. I made a mental note to write a backup log verification program that would run after backup in the future to mail me a status message, and went about the process of deciding what to do next. I remembered a talk at a DECUS concerning the ODS-1 and ODS-2 structure. At this point I considered BRU pretty odious too so I deleted it from my system pack. Next I went out to get some breakfast. While feasting on scrambled eggs and coffee I decided to try to repair the broken disk. After all the master index is in the center of the volume and I had an image copy from one week before. Since I have 2 RP06's, I mounted the broken pack on one drive and the good pack on the other. I mounted both of them foreign and write protected the good but old pack. Next I decided that I needed to write a program to examine the two packs and copy data from one to the other. After only a moment's pause I realized that such a program had been delivered with VMS 1.0 of the system. It is called FLOPPYCPY. With only a one-line modification to have it stop copying after 1000 blocks, rather than go to the end of the volume, I was ready. A quick assignment of the logical name CSA1: and I was ready to back up the biggest console floppy. Three minutes later, RP06's are much quicker than the console floppy, and the two disks were identical for the first 1000 blocks. ANAL/DISK/REPAIR was next run 3 consecutive times on the disk. This cleaned up the disk. I did lose two user directories on the front of the disk but most of the files were in SYS$LOST so it was easy to give them back to the users. PS, my co-worker is upset because I did not mount the ODS 1 disk he created and print the DECnet update listing that he was trying to pull from the BRU tape. The moral of this story is: 1) If VMS says you do not have privilege, do not log on as SYSTEM and try it again. 2) If you do get in a bind, think a little before you give up the case as being hopeless. Try to remember that there is more than one way to reach the goal. 6 PAGESWAPPER - May 1984 - Volume 5 Number 11 More BECOME.COM More BECOME.COM THE RECORD 150 River Street Hackensack, NJ 07602 March 23, 1984 Larry Kilgallen PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 Dear Larry: In the file BECOME.COM presented in PAGESWAPPER Volume 5, Number 7, I referred to a file SYS$VPWFILES:TESTFILE.COM which was not defined in the article. This file comes from the set of VPW programs submitted by James Downward on the VAX SIG tapes; persons who have implemented that sub-system should have had no difficulties using BECOME.COM. I have had several phone calls and letters, however, from people who wanted to use BECOME.COM but were unable to make it work without TESTFILE.COM. The contents of TESTFILE.COM are given herewith. The file need not reside in a directory logically named SYS$VPWFILES; that just happens to be where it is found on our system. CONTENTS OF TESTFILE.COM ________ __ ____________ $ Spec = "" $ Spec = F$SEARCH(P1) $ IF Spec .EQS. "" THEN EXIT 3 $ EXIT 1 For the information of people using BECOME.COM, since I wrote it I have found a program called SWAP.EXE on the VAX82B SIG tape which does essentially the same thing as my command procedure and does it much faster. It also renames the process; e.g. if you are WATSON and say "$ SWAP JONES" your process name becomes "JONES". SWAP.EXE was found in [VAX82B.MELBUNIV.SWAP]. Sincerely, Allen A. Watson Manager, Systems Technology 7 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Westinghouse Report on Fall 1983 Symposium Las Vegas, Nevada October 24 - October 28, 1983 Written and Edited by Almon Sorrell and Marty Adkins with contributions by Robert Lebherz Westinghouse Electric Corporation Baltimore, Maryland February 2, 1984 INTRODUCTION Purpose This report covers the Fall 1983 DECUS (Digital Equipment Computer Users Society) Symposium held in Las Vegas, Nevada from October 24 through October 28, 1983. The report was edited by Almon Sorrell and Marty Adkins, with contributions from Robert Lebherz. The report is not organized chronologically, but rather by topic, since this seemed to be the most useful means of conveying information to the reader. 8 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Scope This report addresses the sessions that are of greatest interest to VAX users. It may be interesting to note that over 5300 people were in attendance and that there were literally hundreds of formal sessions which were scheduled in 13 major rooms concurrently. Those sessions also included presentations on RSX-11, RSTS-E, as well as sessions oriented toward the business user, site preparation, graphics users, etc. Additional informal sessions were held continually in "camp grounds" where users and developers could meet for one-on-one discussions. Organization The top level organization of the report consists of 8 categories: VMS Futures (Version 4), VAX Cluster Concepts, Computer Security, VMS Problems, VAX Information Architecture (Datatrieve, FMS, TDMS), Graphics, Networks and Communications, and Hardware. Other Material There were two volumes of handouts for the VAX/VMS sessions which contained hard copies of the presenters' slides or viewgraphs. Where reference to these are appropriate the symbol "VSIG" will refer to the VAX Systems SIG Handout. Similar handouts were prepared by the RSX SIG (RSIG), Network SIG (NSIG), Datatrieve SIG (DSIG), Graphics SIG (GSIG), and Languages and Tools SIG (LSIG). Future Symposia The Spring '84 DECUS symposium will be held at the Cincinnati Convention Center from June 4 through 8, 1984. The Fall '84 symposium will be held at the Anaheim Convention Center in Anaheim (home of Disneyland), California from December 10 through 14, 1984. 9 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium General This symposium was held at the MGM Grand Hotel in Las Vegas. The hotel itself is laid out in the form of a large "T". Once again, lunch was served in a large tent on the grounds of the hotel. Unfortunately, the lunch area was at least a 10 minute mad dash away from anything else! The exhibit hall was at one end of the top of the "T", the major VAX session meeting rooms at the far end (about 1 block), with most of the remaining rooms on the 26th floor at the bottom of the "T". Therefore, a tremendous amount of time was spent (wasted?) running through the casino area, trying to get from one session to the next, or even worse, trying to fit lunch into one's schedule. DEC's exhibit area was large and well-stocked as usual. It was amazing to see the exhibit area transformed overnight from a mass of crates lying everywhere on Sunday, to a large collection of well-organized working computer systems by Monday morning. New equipment on display included the MicroVAX I, the VAX-11/725, new VT-220, VT-240, and VT-241 terminals, and communications servers. Most of the computers were connected through DECnet and included two 730s, two clustered 780s using the HSC50 running a pre-Field Test version of VMS V4 (X28J), several 750s, a DEC-20, numerous PDP-11s, and several PRO-350s running Ethernet. A video projection system extolled the features of the new VT2xx family of terminals. Absent from this symposium was the well-stocked bookstore usually run by A&SG (now the Installed Base Group). Instead, there were sample copies of some documentation and order-takers to place orders (ours finally arrived at the end of November and was partially incorrect!) Many people voiced unhappiness at this change of policy, and we would certainly prefer the approach of buying things on site and taking them with us! DISCLAIMER All information reported here is believed to be correct and is based upon information related in good faith to the authors. Every attempt has been made to check this report for accuracy and correctness, and any additional information gathered since the symposium which bears on topics presented there is also reported. Neither the authors nor Westinghouse accept any other responsibility for the contents of this report. 10 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium VMS VERSION 4 The exhibit area where the VAXcluster was set up was always crowded. Aside from the presence of the cluster system, however, the big "draw" was the fact that the machines were running VMS Version X28J - a pre-release V4. This marks the first time that DEC has publicly demonstrated software this far ahead of formal announcement and was appreciated greatly by those attending! It also gave users a chance to experiment with some of the new features being described in the various presentations. As usual, no public commitment was made as to the availability date of V4. Loadable Code New to VMS is the concept of "loadable code." This is operating system code which is not necessarily loaded at every installation. This allows paring down the size of VMS in cases where certain features are not needed, and also allows "customizing" VMS in some cases. Examples of loadable code are the Recovery Unit Facility (RUF), Common Journaling Facility (CJF), and the code which implements the erase pattern for Erase-on-Delete files. The advantages are obvious. The disadvantage is that if a package relies on the presence of a particular module of loadable code, and a specific site has chosen not to load it, the package will not work. The most likely place for this to cause trouble is the CJF/RUF. Common Journaling Facility The Common Journaling Facility (CJF) (VSIG 187ff) was created to "provide necessary mechanisms for protecting data integrity (and) to provide general journaling capability." As mentioned above, CJF is implemented as loadable code. The CJF services provide a user interface to the journal driver and to run-time journaling functions. The journal driver controls most operations on journals and all cluster journaling activity. A journal ACP (JNLACP) is used to perform complex journal functions with a utility (JCP) to setup and control journaling activity, much like NCP is used for DECnet. 11 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium A journal is basically a shared, protected, secure logical device which appears similar to a mailbox and may be used by an application or indirectly through a recoverable facility, such as RMS. A journal file is a standard Files-11 structure which may reside on either disk or tape. Disk files have a 1:1 relationship to a journal device, while tape files may contain information from more than one journal device. There are four types of journals: 1. AI - After Image: FIFO device for roll forward recovery processing. E.g. restore a week-old backup copy of an object to its state prior to a head crash. 2. BI - Before Image: LIFO device for roll back recovery processing. E.g. restore an object to the state it was at 9 PM yesterday. 3. RU - Recovery Unit: Circular data container for storing information necessary to assure atomicity (complete or not-at-all) of a set of operations on an object. 4. AT - Audit trail: FIFO or LIFO device for recording audit information such as security audit, or RMS file activity. In a cluster environment, journal devices appear on all members of a cluster as local devices. Cluster journal devices have a master/slave relationship where the master resides on the member where the journal was created. If a cluster member which contains a master journal device fails, another member of the cluster will be chosen as the master for the journal device. RMS will be the first DEC facility to use CJF and will support all four types of journaling for sequential, relative and ISAM files. Recovery Unit Facility The Recovery Unit Facility (RUF) (VSIG 196-200) complements the journaling facility (CJF) described above. As such it is the entity responsible for coordinating the activities of recoverable facilities which implement recovery units. It creates and provides access to RU journals and provides the environment for the processing of interrupted or canceled RUs. Services provided by RUF include: 12 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium RUF$START - initiate a recovery unit RUF$END - complete a recovery unit using two-phase commitment RUF$CANCEL - abort a recovery unit (rollback) RUF$MARKPOINT - establish an intermediate recovery point within a recovery unit to which a rollback can occur RUF$RESET - roll-back modifications made since a previously specified markpoint RUF$DCLRUH - declare a recovery unit handler RUF$CANRUH - cancel a recovery unit handler RUF$PHASE1 - initiate Phase 1 of recovery unit completion RUF$PHASE2 - initiate Phase 2 of recovery unit completion RUF$STATUS - determine if a recovery unit is currently active Recovery unit journals must reside on the disk logical volume which contains the objects it will be used to protect and is shared by all users accessing recoverable objects on the same logical device. The two-phase commitment mentioned above is divided as follows: 1. All information necessary for BOTH completion AND abandonment of all modifications to recoverable objects modified during the recovery operation must be preserved in stable storage. All modified recoverable objects must remain locked from access by other processes until processing of the RU is completed. 2. Release of the storage used to preserve completion or recovery information and of the locks on recoverable objects. Files may be marked to determine the (default) type of recovery/journaling to be applied to them. This will be a header attribute which will be shown via a DIRECTORY/FULL. 13 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Checkpoint/Restart Checkpoint/Restart (VSIG 201-206) is an extremely important new capability being added to VMS. It allows a process to periodically save its state, such that if the system fails due to a crash (or planned shutdown), previous processing will be protected. Thus, long-running, computation-intensive jobs such as simulations, IC layout & verification, etc. will be able to protect their investment in computations. The system must be properly configured in order for checkpointing to work - the CJF & RUF must be loaded and there must be a secondary paging file (all checkpointed processes MUST use the secondary paging file). The user places calls to CHK$CHPNT() wherever a checkpoint is desired. If the run fails, the user invokes the checkpointed image via $ RUN/RESTART. The detailed process by which checkpoint functions is described in the VMS handouts. One major constraint which users should ALREADY be observing -- there must be NO PHYSICAL DEVICE NAMES -- use logical names.v Checkpointing is not the same as providing a "rollout" facility which has been requested for several years. A rollout facility would allow the system to "snapshot" its entire context, stop (say for planned maintenance), and then restart at the same point as where it left off. VMS developers say that this is almost impossible, and gets even worse with the advent of clusters. Checkpoints MUST be user-invoked. Neither the System Manager, nor the great VMS guru, nor even the Great WOMBAT himself can force a checkpoint down a process's throat! Checkpointing is said to cause the process to incur about a 5% overhead (a small price to save many hours of CPU time!) Terminal Driver As usual, substantial (read GREAT) changes/improvements have been made to the terminal driver for the "next major release." New features include: o Command line editing - How many times have you typed a 65 character command, only to make an error on the 64th character and not notice it until after has been typed? Now you can EDIT that line with a subset of EDT. o How many times have you wanted to recall a previous command and re-issue it (or edit it)? Well - now you can recall the last 20 commands to DCL. This is implemented in two levels - DCL can recall the last 20 commands but the terminal driver itself saves the last 14 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium command, thus it can be recalled from ANY program. o Detached Terminals - Ever want to ALLOCATE a tape drive from a terminal remote from the VAX, then be able to go into the machine room, hang your tape and log in on a terminal there and do your tape processing? Now you can - it's called a detached terminal. This also allows a user who's had his terminal disconnected during a dialup session to dial back in and resume his process (great for noisy lines!) In effect, it's like a CTRL S had been performed. VMS developers assure us that they have taken security precautions here. The process will only stay around a predefined length of time (you got it - another SYSGEN parameter!) before dying. o Field Validation - per-character validation is now possible and will be used by FMS/TDMS. o Broadcast enhancements - BREAKTHRU mode will break through any existing I/O operation. It will wait 30-60 seconds for ^S to be cleared before forcing the terminal to accept output. o The Port/Class interface has been formalized and may be documented in V4. o Improvements have been made to the autobaud algorithm. o Optimizations have been made which should benefit block mode and micros transferring large amounts of data. This bypasses much of the checking which now takes place. o A new characteristic (PASSTHRU) has been established - this transfers data much like PASSALL does now, but honors ^S & ^Q. o Secure Server Key - this also comes under the heading of Security and is designed to thwart "password-grabber" programs. When this mode is enabled, hitting the BREAK key causes ANY application to abort or disconnect. It then starts LOGINOUT. o Users of the systems in the exhibit area noticed that typing ^Y produced the message "INTERRUPT" in reverse video, rather than the cryptic ^Y. Similarly, ^O produces "OUTPUT ON" or "OUTPUT OFF". This was originally done as an April Fool's joke, but developers thought it was neat and decide to keep it. o Ever wanted to define your own prompt string instead of "$ "? Now you can - either on a system or process basis. (Rumor had it that this was another joke pulled 15 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium on Kerbey Altmann, a VMS developer and BASIC freak. The prompt on his system was changed to "Ready" - once again, people thought the "joke" pretty neat and decided to keep it.) o A few terminal driver performance notes - A DMF32 using formatted output saturates the system at an aggregate rate of 50KB/sec, but unformatted (QIO/PASSALL) goes to 250KB. DCL Internal Routines o SET UIC [VMS,GEORGE] - sets the UIC to that of the user GEORGE in the VMS group. o SET VERIFY=([NO]PROCEDURE,[NO]IMAGE) - new "image" verification echoes input data lines to SYS$OUTPUT. o SPAWN - new options from command level: - /LOGICAL_NAMES - controls copying of process tables and names to the subprocess. - /KEYPAD - controls copying of key definitions created with SET KEY and DEFINE/KEY. - /SYMBOLS - controls copying of local and global symbols. - /PROMPT, /CARRIAGE_CONTROL - specifies the prompt string for the subprocess. - /CLI=cli_filespec - selects the CLI for the subprocess. Side effect is that no parent context is copied. - /NOTIFY - causes broadcast to parent terminal when subprocess completes; used with /NOWAIT. 16 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Lexical functions Several new lexical functions are introduced in V4, while a couple have been enhanced: o F$CVTIME - the input time string may now be in any valid time format. Also, you may specify the output time format, and what field of the output time you desire - DATETIME, DATE, TIME, MONTH, DAY, YEAR, HOUR, MINUTE, SECOND, HUNDREDTH, and WEEKDAY. e.g., $ NEXT = F$CVTIME("TOMORROW",,"WEEKDAY") $ SHOW SYMBOL NEXT NEXT = "TUESDAY" o F$EDIT(string, edit_list) - performs various string edits - COLLAPSE, COMPRESS, TRIM, UNCOMMENT, UPCASE. o F$ELEMENT(element_number, delimiter, string) - helpful in string parsing. o F$ENVIRONMENT(item) - returns the value of the specified keyword - CAPTIVE, CONTROL, NOCONTROL, ON_CONTROL_Y, ON_SEVERITY, DEFAULT, DEPTH, MAX_DEPTH, PROCEDURE, INTERACTIVE, MESSAGE, PROTECTION, OUTPUT_RATE, KEY_STATE, PROMPT, PROMPT_CONTROL, VERIFY_IMAGE, VERIFY_PROCEDURE. The most frequent use of this function is for saving the previous process state before temporarily changing it. o F$GETDVI - now can retrieve the many terminal-dependent characteristics by name - e.g., "TT_DECCRT". o F$GETSYI - now can return information on node parameters in a VAXcluster. o F$MODE - has a new return value of "OTHER" (detached, etc.). o F$TRNLNM - corresponds to new system service. Accepts argument of "CASE_SENSITIVE" or "CASE_BLIND". o F$TYPE - returns the type of a symbol - INTEGER, STRING, . o F$VERIFY(procedure_value, image_value) - saves state of procedure verify flag, and optionally changes state of procedure and/or image verify. 17 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium EDT The field test manual for EDT V3.0 was available for inspection. I wish I could say I was pleased with all I read. Remember the Anaheim Fall 82 DECUS Editor survey? Supposedly, the two most desired EDT enhancements were "learn mode" (ala KED), and an overstrike mode. Well folks, no such luck. Moreover, this is it for EDT evolution! All current development is targeted toward an unspecified sophisticated environment editor. However, there are some improvements in EDT V3 worth noting: o By default, EDT startup will now look for a system-wide initializer file SYS$LIBRARY:EDTSYS.EDT. No error occurs if it is missing. Also, a new command, "SET COMMAND ", permits chaining of these command files. A similar command, "SET HELP ", can specify a tailored help library. o EDT is now callable as promised. To make its called behavior a little more transparent, new commands have been added: SET PROMPT, SET (exit)SUMMARY, SET FNF, SET TERM/SCROLL, SET REPEAT, SET AUTOREPEAT, SET WORD NODELIMITER. o Many of the changes are to accommodate the multi-national character set, and to create a WPS atmosphere. o At DCL command level, a new /[NO]CREATE switch will prevent the familiar "file does not exist" and required quit and retry, all because of a typo. o Although nothing in print confirms it, EDT will now make use of the ANSI screen edit functions, if the /EDIT_MODE characteristic is set. This should reduce the number of I/O operations. I did not discover whether other optimizations had been made to eliminate needless screen repaints, and cursor bounce. 18 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium VMS System Services Logical Names The most staggering change in V4 system services is the further generalization of logical names. Remember when life was simple and you only had process, group, and system tables? Well, now you may create your own tables, giving them any (logical) name you like. All table names become prefixed with "LNM$", e.g., LNM$PROCESS, LNM$SYSTEM, and LNM$GROUP. There are also two logical name directory tables - LNM$PROCESS_DIRECTORY and LNM$SYSTEM_DIRECTORY. When you create a new table, the table name gets entered in the specified directory table. You can also specify the parent table of your new table, as well as the protection. Why? For communication with other processes in your job's process tree or in the world! Furthermore, tables and logical names now carry attributes: o NAME_ATTRIBUTES - CONFINE - do not copy this name (table) during a SPAWN operation. - NO_ALIAS - No logical names (tables) with the same name may be created in an outer access mode. o TRANSLATION_ATTRIBUTES - CONCEALED - the equivalence string is a concealed physical device name. - TERMINAL - do not continue iterative translation. One of the most powerful additions is the "search list". You may assign the same logical name to more than one equivalence string. A numeric index distinguishes the order: $ ASSIGN DISK1:[DIR1] MASTER $ ASSIGN DISK2:[DIR2.SUB1] MASTER /TABLE=LNM$PROCESS $ SHOW LOGICAL MASTER 0 "MASTER" = "DISK1:[DIR1]" (LNM$PROCESS_TABLE) 1 "MASTER" = "DISK2:[DIR2.SUB1]" (LNM$PROCESS_TABLE) 19 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium $ DIRECTORY MASTER:SPECIFICATION_FILE.TEXT Directory DISK1:[DIR1] SPECIFICATION_FILE.TEXT;1 Total of 1 file. Directory DISK2:[DIR2.SUB1] SPECIFICATION_FILE.TEXT;2 SPECIFICATION_FILE.TEXT;1 Total of 2 files. The standard services $CRELOG and $TRNLOG are still the same, but have been supplanted with $CRELNM and $TRNLNM, plus $CRELNT to create a table. SHOW LOGICAL now has many options; if you don't specify which table to search, it searches LNM$DEFAULT_SEARCH, which is normally a search list of LNM$PROCESS, LNM$GROUP, and LNM$SYSTEM. $BRDCST -> $BRKTHRU(W) The $BRDCST service has been superceded by the $BRKTHRU and $BRKTHRUW services. Breakthrough performs the same function with the following differences: o A list of terminals may be specified for output. o A request ID may be specified. o Most importantly, the service completes asynchronously. The call arguments are similar to a QIO call. This includes an event flag, iosb, ast address and parameter, and a timeout value. No longer will your process hang in MWAIT because of a hardware error. $SNDxxx -> $SNDJBC(W) A new service, "Send to Job Controller" ($SNDJBC) supercedes $SNDACC and $SNDSMB, and is the preferred way to perform any job, queue, or accounting functions. The W(ait) form completes synchronously unless the requested function is a pause queue, stop queue, or abort job operation. (There is no way to synchronize completion of these operations.) To synchronize to the completion of a particular job, the caller can specify the SJC$_SYNCHRONIZE_JOB function code. 20 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Miscellaneous System Service Changes o Several services that require an event flag argument now have an "XXX-and-wait" variant: $BRKTHRU(W), $ENQ(W), $GETDVI(W), $GETJPI(W), $GETLKI(W), and $SNDJBC(W). o $ERAPAT - returns the current security erase pattern for overwriting memory. o $FILESCAN - searches a string for a filespec and parses its components. o $GETLKI(W) - gets clusterwide lock information. o $SYNCH - checks the completion status of a previous asynchronous system service; you provide the EFN and the IOSB address. Miscellaneous V4 Changes o File naming conventions have been expanded such that filenames may contain the underscore character (_), and have a maximum length of 253 characters. The 253 characters may be allocated in any fashion within the following limits: - Node name - 6 characters max - Device name - 15 characters max - Directory name - 39 characters max (8 levels) - Filename root - 39 characters max - Filename extension - 39 characters max o The stucture for the PID (Process Identification) is changing. In the past, one could use the lower 16 bits of the PID and be assured of uniqueness. One should make NO assumptions about the structure of the PID, only that it is guaranteed to be unique throughout a VAXcluster. o TECO will be a supported editor (language??) under VMS V4. 21 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium o UICs will use all 32 bits. VAX CLUSTER CONCEPTS Since this topic was covered in depth at the previous DECUS and in our previous trip report, this report will reflect only new or more detailed information, and will not attempt to discuss the entire topic of VAXclusters. MASSBUS Disk Support While the VAXcluster is principally geared toward the use of the newer SDI disks (RA60, RA80, RA81) with the HSC50, it is possible to also use MASSBUS disks (or RA-series drives on UDA50s) either as local disks OR as shared disks if they are dual-ported. In order to be shared, the disks must have the same device and controller name on both systems, e.g. DBA1. Local disks will be supported by the MSCP server under VMS V4. This also includes the volume-shadow capability, as long as the disks are RA-series on a UDA50 controller. Thus, there is no necessity to have an HSC50 in order to run a cluster. It is certainly desirable, however, since the server introduces considerable software overhead. Note that although the RA-series disks are all "dual-ported", this is true only in a static sense. This is because the "online" packet message sent from the drive to the controller takes almost one minute to execute in order to allow for inconsistency checks and for the re-vectoring of bad blocks. This precludes any type of dynamic shift of control from one processor to another. VMS V4.0 Cluster Software Features Many of the features of the cluster system cannot be enjoyed until VMS V4.0 is available. The demo systems at this symposium were running a pre-Field Test version of V4 to demonstrate these features. 22 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium SHOW CLUSTER A "SHOW CLUSTER" command has been implemented which allows a cluster manager to display the current status of the cluster. This may be run either as a one-shot, or continuously to monitor the cluster. The display can cycle between displays of the local port information or cluster-wide data. Part of the identification of the individual nodes within the cluster is set via dipswitches in the CI (0-15). The other is the System Identification which consists of up to 48 characters. Both of these MUST be unique. Connection Manager The Connection Manager is that portion of the software which determines who currently is a member of the cluster and is responsible for synchronizing cluster state changes (nodes coming or going). It is also responsible for queueing messages for possible delivery to a node after re-connection. Distributed Lock Manager The full implementation of the Lock Manager services (initially implemented in V3.0) provides $ENQ and $DEQ as cluster-wide synchronization primitives. As such it is used by the file system, RMS, job controller, etc., as well as by individual application programs. Distributed File System / RMS Under V4 there will be no FILES-11 ACP as in previous VMS versions. Instead the file system will be mapped into the user's P1 address space. There is no more single-threaded code to serve as a bottleneck to disk access and no context switching. All file sharing capabilities which now exist are extended to be available across the cluster. Any cluster-available disk appears to a process as though it were a local disk. 23 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Distributed Job Controller The Job Controller went through some significant "munging" on the way to V4. It now makes use of the distributed lock manager and file system. Job controllers on each system make use of a shared RMS file for the batch and print queue database. This results in cluster-wide batch and print queues allowing any system to access a physical printer within the cluster, and similarly to enable a single machine to be configured to run all batch jobs. The job controller will normally choose the batch queue with the lowest ratio of jobs running to job limit. Cluster Journaling and Recovery The topic of journaling and recovery are covered in detail elsewhere. The major extension within the cluster environment is that journals are mastered by a single system but are accessible from all systems in the cluster. After a system failure, journals are remastered on other systems and processing continues after recovery has been completed. Clusters and DECnet DECnet must be installed and running on every system in a VAXcluster. It may operate over the CI, which allows the user to avoid purchase of a separate communication medium for DECnet. The impact on the CI is minimal. DECnet is not required because any cluster component relies on it, but rather because it provides many features which cannot be performed any other way. System management requires the use of SET HOST. 24 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Cluster Management Considerations Digital intends that the cluster be managed as a single entity. For a user to be able to login on any machine in the cluster requires coordination of UAFs within the cluster. It is probably easier to use a single UAF on a shared disk - note that this need not be the system disk if the logical name SYSUAF is used. Although multiple VMS systems may be booted from a single disk using parallel system directories, there are performance considerations which suggest that separate disks are a better solution. Certainly secondary swap and page files should reside elsewhere. Putting multiple systems on the same disk is bound to cause disk arm contention. All systems must run the same VMS version and update. Layered products will probably have to be installed separately on each system. COMPUTER SECURITY Definition: Hacker "That kid with a (microcomputer), an auto-dial modem, and YOUR system." Network Security - Proxy Logins The session on VMS DECnet Proxy Login (VSIG pp. 280-286) was very similar to the one at the previous DECUS, so the details will not be repeated here. The handout does present the material more clearly this time around. One correction should be noted - the proxy mechanism interferes with the MAIL and PHONE utilities. To disable the use of proxy for these objects, issue the NCP commands: 25 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium NCP>DEFINE KNOWN OBJECTS PROXY BOTH NCP>DEFINE OBJECT MAIL NONE NCP>DEFINE OBJECT PHONE NONE NCP>DEFINE OBJECT DMLISTEN NONE NCP>DEFINE OBJECT TASK OUTGOING Miscellaneous Tidbits on VMS Security The following items were noted in the VAX Security Working Group session: o Instead of removing usernames from the UAF, set the DISUSER, DISNETWRK, and CAPTIVE flags. Also restrict the allowable hours for login to none, and delete the login directory. What this buys you is that failed logins for this account will include the username in the accounting record, instead of "". o All user accounts should have the DISCTRLY flag set to prevent a "hole" in the login sequence. Also remember that DISUSER affects only INTERACTIVE logins, and DISNETWORK affects only SET HOST. To prohibit all uses, you must use hour restrictions as noted above. o DEC SPS in Albequerque, N.M. sells a relatively inexpensive patch to LOGINOUT called "INTERLOCK". If the number of failed login attempts exceeds a SYSGEN threshold, the account is DISUSER'd. Or you can wait for VMS V4 which includes this capability. Security Mechanisms in VMS V4 VMS Version 4 introduces significant new capabilities in the area of system and data security. Areas being addressed include additional protection at login time, file access control, increased password security, protection against data scavenging, and security auditing. Terminals may be enabled for security reporting, just as terminals may now be enabled for operator messages. 26 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Login Protection o Blind login capability - No sign-on messages are displayed until a system-wide password is entered (with timeout). The user does receive a bell to acknowledge autobaud detection. This approach is intended to counter the hacker searching by machine characteristics. o Break-in Detection - A "suspect record" will be written to all security terminals after a Sysgen-settable number of sequential failures have been logged. This will show the terminal, username, network node, etc. There are also thresholds selectable for beginning "evasive action" and disabling the target account. (What's a new VMS release without new Sysgen parameters?!) o Date and time of last login will be displayed after successful logon. Password Security Passwords can have expiration dates and minimum password length can be enforced. Automatic password generation may be available. Access Control Lists (ACL) As mentioned in earlier reports, V4 will have the capability of specifying Access Control Lists (ACL) in addition to the present "SOGW" protection. An ACL specifies the access of an "agent" to an "object" and consists of an ordered list of identifiers and types of access. The first matching entry in the list determines the type of access granted. Users of the Common Data Dictionary (CDD) should be familiar with the concepts. If no ACL corresponds to that of the agent, protection reverts to the file protection mask (SOGW). 27 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium File Attribute Propagation The default protection and ACL applied to a file will follow a hierarchical order. If none is specified, the protection will be that of: 1. Previous version 2. Directory default 3. Current process default Data Scavenging There has long existed a problem referred to as "data scavenging". This refers to methods for obtaining data to which one has no rights by reading "erased" data, such as "deleted" file areas on the disk. This will be plugged by "Erase on Delete" and "Erase on Extend" attributes which may be attached to a file, a volume, or invoked by the user. The erase pattern is being implemented in loadable code so that a sufficiently privileged user may select the specific pattern, number of overwrites, etc. which are to be performed. Non-Discretionary Controls This class of controls concerns actions taken which are outside the control of an object and pertain to security/integrity levels. This prevents a user from "downgrading" classified materials, or "upgrading" non-trustworthy programs. These may be implemented in V4, although it was somewhat doubtful. VMS PROBLEMS & WORKAROUNDS o Problem with UDA50/RA disks - if the boot device is write-protected, VMS will BUGCHECK with "unexpected system service exception". The signal array in the console trace will contain a code of "444" (page read error). 28 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium o Occasionally users run into disk quota limits and EDT is unable to create its workfile (EDTWORK.TMP). EDT first tries SYS$LOGIN, then the current directory, then gives up. You can override the defaults with $ASSIGN /USER SYS$LOGIN". o CONVERT currently has a problem converting from a file with Variable-length records and Fortran carriage control to a file with fixed-length records and CR control - the last character is dropped. The workaround is to break the operation into two steps: Var/For -> Var/CR -> Fixed/CR. o LOGINOUT currently thinks a process is INTERACTIVE if SYS$INPUT = SYS$OUTPUT = a terminal. This is incorrect for "$ SPAWN @TEST". Fixed in V4. o The VAX Debugger cannot examine G/H floating variables if the VAX does not have the KE780 microcode option. DEBUG uses its own condition handler, NOT LIB$ESTEMU. o You may have noticed that the FDL$xxx symbols are not defined in any libraries. To get them do the following: $ LIBR/LIST=file SYS$LIBRARY:IMAGELIB/NAMES $! Make FDL.MAR containing .GLOBAL FDL$_xxx .entry START,M MOVL FDL$_xxx,R1 ... etc... RET .end START Now assemble and link, then retrieve the symbols from the link map. (Whew!) o AUTOGEN still has an incorrect formula of _____ GROWLIM=FREELIM-1 instead of GROWLIM=FREEGOAL-1. The subtle difference can cause your system to swap itself to death, as working set loans are granted even though the free list is depleted. Although we SPR'd this one last April, and resubmitted it in September, we have yet to get a response, and it has yet to be fixed! Four VMS developers at the last two DECUS all agreed that this is a bug. Another nasty problem in SYSGEN/AUTOGEN is that AUTOGEN does not look for the existence of secondary page and swap files. Consequently, it decides that your primary files are too small and invokes SYSGEN to create new ones. But SYSGEN first attempts to extend the existing ones. Since AUTOGEN does not specify the /CONTIG option, the extension is a fantastic garbage collector, creating horribly fragmented files. This can prevent the system from rebooting! 29 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium o SORT likes to have lots of virtual address space, and at invocation, it attempts to get about 8 times your current working set size. If it fails, it gives up! The only workaround is to lower your working set manually before calling or invoking SORT. Otherwise you run out of PGFLQUOTA or VIRTUALPAGECNT. SORT also needs scratch disk space of about 3.5 times the size of your input file(s), plus space for your output file. The error messages produced are rather obscure and don't point you in the right direction. VAX INFORMATION ARCHITECTURE DATATRIEVE A session on Datatrieve Optimization produced the following comments/reminders: o For domains where alternate keys will be used, define the most frequently queried unique field as the Primary key. o In a CROSS operation, Datatrieve does not use the key while scanning the first domain specified. It walks sequentially through all records, but will use keys into the succeeding domains. Therefore, if one domain is indexed by the field over which the cross is being performed, specify that domain second. If both domains are indexed by the cross field, specify the larger second. For multiple domain cross, follow the above rules iteratively. o In using FOR loops, put the domain that has the key field in the innermost loop. For example: FOR A IN A_DOMAIN BEGIN FOR B IN B_DOMAIN WITH B.KEY=A.KEY o Datatrieve procedures are NOT really equivalent to subroutines. They are stored as unprocessed statements and must be re-interpreted EACH time invoked. 30 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium o When using nested procedures, have a single procedure perform all necessary READYs so each procedure doesn't have to re-READY. Close all domains at the very end of the set of procedures. o The DEFINE FILE command provides an easy way to create files - NOT NECESSARILY AN EFFICIENT WAY! The default values for a file created with DEFINE FILE are: - ALLOCATION = 3 blocks - EXTENT = 0 - BUCKET = 2 (if the record is less than 2 blocks, or next larger number of blocks than the record) - GLOBAL BUFFERS = 0 Therefore, it is probably wise to use the RMS utilities such as EDIT/FDL, CREATE/FDL, and CONVERT to create the actual files if performance is of concern. On the other hand, DEFINE FILE is a very quick way to get started and data entered may always be transferred to a more efficient file structure using CONVERT at a later date. NETWORKING AND COMMUNICATIONS DECnet Performance A number of performance improvements were incorporated into DECnet 3.1 and more are in store for DECnet 4.0: o Both receiver and transmitter pipelining, and the use of larger buffers has made file transfer much more efficient, especially in the one-hop case. Combine this with the speed and intelligence of the DEUNA, and the data really moves! But remember that extra buffers mean extra pool, and that requires extra BYTLM for the user. o Under DECnet 3.1 and Ethernet, task-to-task transfers occur at 120 blocks/second or 80 ms per block. o MAIL will use 512-byte buffers for more efficient message transfer. o The new Command Terminal Protocol (CTERM) is vastly more efficient, plus it works across heterogeneous systems. The new version is timer-based, so it typically collects several QIOs and combines them into 31 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium one network QIO. There is no longer a separate I/O status block (IOSB) returned from the destination, with its accompanying ACK. This greatly reduces the number of packets in both directions. o Users complained that the DMP11 works poorly as a multidrop interface. DEC points out that the device is very parameter-sensitive, and that the documentation is void in this area. The best guide to setting multidrop parameters is a DEC Small Buffer article (an internal document available to DEC Software Specialists). o The Computer Interconnect (CI) is currently seen by DECnet as a multidrop device, so that messages actually pass through a router! This will be fixed in DECnet 4.x. Network Miscellaneous The following tidbits were heard at the Network Q & A session: o The DMF32 synchronous port DOES NOT WORK properly under ____ ___ ____ DECnet. The problems are not speed-dependent, nor processor-dependent. The solution will require both hardware and software changes. The DMF32 has two (unreleased) ECOs that correct the hardware side. Rev. H includes a different line receiver on the sync port, for better noise margin when the card is installed inside a 730 CPU cabinet. Rev. J replaces 9 PROMs and also supports X.25 (PSI 2.1) hardware framing. The software solution is still being sought but is expected to be available by the time the DMF32 rev. J boards are in the field. o Will a DMR11 work properly under DECnet-VAX if its microdiagnostics are enabled? One panelist said it should. Another said DEC had to disable it to get a DMR11 working in the exhibit area! Does anyone know??? o EDT is much more "usable" under PSI 2.1. Only FMS 2.0 will work correctly under PSI. o At the mere mention of the DMP11, the room reverberated with sounds usually reserved to canines! o This user reported that under DECnet 3.1, the NCP command "ZERO KNOWN NODES" no longer works - the Executor counters are cleared, and an "unrecognized component" message is issued for all other nodes. A 32 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium DECnet developer studied the supplied printout, and later believed it to be a bug affecting only networks without area routing (non-Ethernet). o To perform a "SET HOST" from within a command procedure, all DCL commands must NOT start with a "$". ___ Also, in VMS 3.2, a bug limited all such lines to 12 characters. During the DECnet VAX Tutorial session, the following comments were made regarding DECnet/Ethernet: o Ethernet can be used by both DECnet and other applications (protocols) without interference - good news for all you out in PC-land! o Using Ethernet in a 780-780 file transfer with a buffer size of 1498 (no other users on system), a maximum transfer rate of 1.4 Mbits was observed. o It was also observed that it is faster to "push" a file from one node to another than to "pull" it - translation: if a file is on your node, send it to the other node, don't have them copy it. GRAPHICS DEC displayed/announced/"pre-announced" several products of interest to the graphics user at this session. These included the new VT240, VT241 graphics terminals, VAX GKS/0b software, VAX-11 ReGIS Hardcopy, and plotting software for the LN01 Laser Printer. The terminals are discussed in the hardware section and the software is covered below. VAX GKS/0b VAX GKS/0b is DEC's initial implementation of the Graphical Kernel System, currently a proposed ISO/ANSI standard, expected to be accepted in 1984. As such, it is a "viewing level" system, meaning that it hides the direct interface to the hardware, but does not implement such functionality as bar or pie charts, etc. The advantage of having "yet another" package for graphics is that GKS is being supported by most major computer and graphics hardware vendors, as well as many software houses. Since GKS is device-independent, and the call 33 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium interfaces are standardized, an application becomes far more transportable across computers and graphics devices. The initial offering from DEC, level 0b, supports VT125, VT240, and Tektronix 4010 devices, as well as the ISO metafile. No true hardcopy devices such as plotters, laser printers, etc. are currently supported. At this time, one must dump the screen to an attached hardcopy device such as an LA100. The driver interface is not currently being made public. GKS/0b is currently in Field Test and is expected to be available in early 1984. VAX GKS/0b is packaged as a VMS shareable image and follows the proposed conventions for Fortran binding (subroutine calls). It also follows the conventions for language independence, i.e., it can be invoked from other languages by calls to GKS$xxx. VAX GKS/0b provides six basic output primitives: o Polyline - connected lines o Poly-markers - markers at data points o Text strings - both 7 and 8-bit codes o Fill areas - polygons which may be hollow, filled, or cross-hatched o Cell arrays - rectangular raster-like array o GDP - an "escape" mechanism to allow access to unsupported hardware capabilities. Each of the output primitives also possesses attributes, such as color, thickness, texture, etc. Various fonts may be specified and take on additional attributes such as height, alignment (centering), and orientation (angle). Input primitives allow the use of: o Locator - point on screen, for example the location of a crosshair o Stroke o Valuator - joystick, thumbwheel o Choice - integer value from devices like pushbuttons o String - text from a keyboard. 34 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium VAX-11 ReGIS Hardcopy A "flyer" on this product was found in the exhibit area. It is "a software utility that provides an on-line method for producing hard-copy images of combined text and graphics from ReGIS input. Without requiring the use of a ReGIS terminal first,..." from an ASCII file containing embedded ReGIS codes. It supports the LA12, LA50, LA100 and LXY11 and is available through Digital Software Services. LN01 Plotter Utility Late in the symposium, the people in the LN01 demo area began showing copies of plots produced by their printer. When asked, they replied that they were produced by a package called (I believe) "LNPLOT" or "PLOTLN". This product translates either ReGIS or PLOT-10* graphics calls into images which can be plotted on the LN01. It was somewhat disconcerting to have the representative reply to the question, "Are you talking with the implementors of VAX GKS about support for the LN01?" and have the person reply "What is GKS?". It seems that there needs to be more in-house dialogue between hardware and software groups and less proliferation of "own-product" software. HARDWARE VAX CPUs The big news regarding VAX CPUs at this symposium was the announcement of the MicroVAX I. This is a true VAX architecture machine packaged in a PDP-11 Q-bus system unit. There were two MicroVAXs in the exhibit area performing REAL-TIME control functions. There was also a VAX 11/725 on display. There were "serious rumors" of a "turbo-charge" kit for existing VAX 11/780s to increase their CPU speed. No announcement was made of the long-awaited high-end VAX. _______________ *Plot-10 is Registered Trademark of Tektronix, Inc. 35 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium MicroVAX I MicroVAX I Hardware Perhaps one of the most amazing facts about the MicroVAX I, and one which evinced great pride from the product manager, was that the whole project was completed in just 18 months. This included the development of the hardware CPU, the necessary modifications to VMS, new microcode instructions, and final testing. This was accomplished by staying with existing PDP-11 hardware as much as possible. Thus, the MicroVAX I uses the 22-bit Q-bus, dual RX50 diskette drives from the Pro-350 and Rainbow machines, 256KB and 512KB memory boards, and existing packaging and power supplies. The system also uses the RD51 10-MB Winchester as well as a new 28-MB drive coming soon. The 8-slot backplane is utilized as follows: o Slots 1,2 - CPU - includes system console @ 300, 1200, 9600 or 19.2K baud o Slot 3 - Reserved o Slots 4,5 - 512KB Memory Boards o Slots 6,7 - 2 Quad or 4 dual modules such as DZ11V or DEQNA o Slot 8 - disk controller The CPU is rated at about 35% - 40% the power of a VAX 11/780 - BUT - this is effectively slowed down by the access time of the small disks, so it is about the same as a 730 with RL02 disks. This version was implemented using custom VLSI chips, one of which is of the same complexity as 8-2901s plus 48 32-bit registers and a barrel shifter. A single chip version is in the works and may be discussed at the solid state circuits conference in February '84. MicroVAX I and VMS The only significant departure from current VAXs as far as VMS is concerned is that there is no compatibility mode and thus no capability for running RSX tasks. In one session, the remark was heard that "after 1985, VAXs may not implement compatibility mode in microcode." Similarly, some of the instructions implemented by the MicroVAX I have moved from microcode to "macro-code". These include most of the character instructions (MOVCx still in microcode), packed decimal, and EDITPC, CRC, etc. The "default" double precision format is "G-floating", with "D" and "H" being emulated in software. According to one of the developers, it took only four days to get VMS running on 36 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium the MicroVAX I. VMS will probably be sold in both runtime environment and application development forms. Supposedly, the stripped-down VMS fits on only 6 floppies (400KB each). MicroVAX I and VAXElan VAXElan is a new product for the MicroVAX which should be of great interest to potential real-time or distributed users. This is a layered product which runs on the larger VAXs to develop stand-alone, statically defined software systems. VAXElan is a Pascal based language which supports both multitasking and multiprogramming and supports total transparency for network operations. The compiler is "suitably extended to eliminate the need for other programming languages (including assembly language)... (and) is the primary implementation language of the VAXElan toolkit." VAX 11/725 The VAX 11/725 is basically a repackaged 11/730 CPU with a non-extendable Unibus. It currently features a new disk drive dubbed the RC25 which features 26MB fixed and 26MB removable Winchester media, and two TU58 tape cartridges. Larger disk drives are planned in the future. It will be available with up to 3 MB of memory, a floating point accelerator (FP730), and other standard Unibus peripherals. It is sized for "under-desk" placement at 17.5" wide, 24.5" high, and 28.5" deep. VAX 11/780 "Turbo-charge" Kit Strong rumors were afloat (which were not contradicted by VAX product management) that a 11/780 CPU upgrade kit would be offered shortly. Allegedly, this upgrade would replace the KA780 CPU boards and would offer a 2:1 speedup of the CPU only. ___ ____ This does not affect the memory controllers or I/O, so the actual improvement in performance would be strongly dependent on job mix (expect about 1.5). Rumor also has it that this product may be announced in early 1984. 37 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium UNIBUS If your system has UNIBUS troubles, check the revision levels of your DW780 UNIBUS adapter boards. The latest are M8270 rev D, M8271 rev E, M8272 rev D, M8273 rev C, and M9044 rev B. MASS STORAGE RA60 Disk Drive The good news was that the problems which have been holding up shipments on the RA60 seem to be pretty well straightened out. The bad news is that quantity shipments are still not expected until Spring '84. RC25 Disk The RC25 storage subsystem is based on eight-inch Winchester drives. It consists of one fixed and one removable volume, each holding 26MB. The removable volume is essentially a cartridge which is inserted from the front. The RC25 controller performs internal data buffering and seek optimization with a peak transfer rate of 1.25MB/sec and an average seek time of 20 ms. The RC25 was shown as part of the VAX 11/725 on display. HSC50 Disk Server The HSC50 is alive and well and was used to run a two-VAX cluster in the demo area. It was interesting to find out that the HSC50 uses seventeen 2901 processors, a DEC F11 CPU, and 1/2MB memory. It can process a 1000-deep command queue and has 128K-words of data buffering. The powerfail problem still exists: it takes over four minutes to reload the HSC50 monitor program from the TU58 console device in the event of powerfail or system failure. No plans have been made to supply battery backup for this unit, although a number of requests have been made for this feature. In one of the 38 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium sessions, a VMS developer commented that this really didn't make too much difference since the RA-series disks take about two minutes to spin up and come on-line after a power fault. In addition, multiple disks are power-sequenced to prevent large surges from occurring when several start at once. This should effectively overlap the time required to reload the HSC50! TA78 Tape Drive The TA78 tape drive is still not available for delivery for VAX/VMS/HSC50 systems. The reason given is that the microcode for the HSC50 will not be available until Summer '84, together with VMS V4. It is possible to upgrade a TU78 into a TA78 by purchasing a TA78-UG upgrade kit. MEMORY The Installed Base Group now has a trade-in plan to swap old 16K VAX memory for 64K memory boards. They will even accept non-DEC memory. TERMINALS - VT2xx Family The recently announced low-profile VT2XX series of terminals were available for public scrutiny. There are currently three models available with varying degrees of graphic capabilties. However, since there are many features common to all three, it will be simpler to list the differences later. The keyboard and crt are the same as found with the PC-100 (Rainbow) and the PRO series personal computers. In addition to the full VT100 compatibility there are multiple enhancements: 1. Glare-free crt screen. 2. Phosphor color choices of white, green, or amber. 3. Twenty programmable (256 chars maximum) function keys which can be downloaded from the host or entered manually. Unfortunately, these are NOT saved in non-volatile memory! 4. Selective erasing - useful in forms management since the form can remain on the screen and only the fields will be cleared. This can be done without repainting the entire screen. 39 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium 5. Setup - very friendly compared to the PC which was an attempt to improve on the VT1XX setup. It consists of multiple levels of English language menus. All terminal characteristics can be set without "bit twiddling" since all options are fully documented on the screen. 6. Up to 15 different keyboard configurations supported including DECMATE. 7. Full 8-bit code support - 256 characters vs 128. Unfortunately, as a by-product of this feature, the "ESCAPE", "BACKSPACE", and "LINEFEED" keys, normally positioned in the top row of function keys, are UNAVAILABLE except in the VT100 emulation mode. This ___________ may impact products relying on these keys, such as FMS, TDMS, and various editors. 8. CRT "burned image" protection - after 30 minutes of inactivity the screen will blank out and depressing any key will refresh it. 9. Green indicator light for power on state - absent on the PC's. 10. EIA and 20 milliamp interface. An optional auto answer/dialup modem is available and the terminal can store two phone numbers or the number could be entered from the keypad. The printer port is bi-directional so there is the possibility of attaching a digitizer or bar code reader. All members of the VT2xx family share the above characteristics. The VT240 and VT241 are extensions which include graphics capabilities. These terminals are bit-mapped with an 800 X 240 by 2 plane resolution. The black and white VT240 allows 4 shades of grey while the VT241 supports full color graphics. Both the ReGIS and Tektronix 4010/4014* protocols are supported in addition to the intermixing of text and graphics (similar to GIGI). Unlike the VT220 and 240, the VT241 CRT is mounted on top of a small box so it will require more space wherever it is located. This box is attached to the terminal and keyboard via cables. There are plans afoot to lengthen these so that the "guts" can be placed under the terminal table or desk. 40 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Buses During a presentation on VAX Buses, the comment was made that ex-Digital V.P. Gordon Bell had become concerned that there were too many different buses within Digital and that henceforth, there would be no new buses. So now, we have interconnects! Anyway, the presentation focused on the various features of the current buses, and upon the needs for future interconnect methods. UNIBUS The UNIBUS is the oldest of DECs buses and formed the heart of the PDP-11 series machines. Its features include: o 18 bit address o 56 signal lines, separate address and data o 4 interrupt levels o Single bus arbitrator o Asynchronous, multiple backplanes within 50 feet o 1-2 MB/sec bandwidth Q-BUS The Q-BUS was introduced with the LSI series of PDP-11s and is now the standard bus within the micro PDP-11 machines. Its features include: o 22 bit address o 44 signal lines with multiplexed address and data o Single bus arbitrator o Block-mode DMA o Asynchronous, multiple backplanes within 16 feet o 1-3 MB/sec bandwidth 41 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Intra-system bus Intra-system buses typically change and must be re-engineered for each CPU. Thus the VAX 11/780 SBI is not the same as that on the /750 or /730, and adapters must be used to attach to different external devices. This gives rise to the MASSBUS Adapter (MBA), UNIBUS Adapter (UBA), DR32, etc. Features of the SBI are: o 30 bit address o 84 signal lines o 4 interrupt levels o Distributed arbitration within each adapter o Synchronous with 200 ns. clock o Parity, queueing, maximum of 16 bus attachments o 13.3 MB/sec bandwidth Computer Interconnect (CI) The CI is a 70 Mbit/sec dual link designed to connect multiple VAX CPUs within a cluster with a maximum radius of 45 meters. The CI forms the heart of the VAXcluster since it is the medium for all inter-CPU communication. Desired Characteristics for New External Bus Thus far, Digital has not settled (publicly) on a new external bus (oops, I mean interconnect), but has laid out a set of desired characteristics including: o 30 bit address o Bandwidth > 10MB/sec o Processor - memory and I/O interconnect as well o Standard interface with LSI chips o Support requirements of VAX architecture - namely interlocked read, write, interrupts o Must be able to support multiple processors - cache, interrupts o Reliability features - parity and consistency checks This bus would be the system bus for small systems, and the I/O bus for larger systems. It would also be the primary bus for general purpose interfaces to terminals, disk, communications equipment, etc. In addition, there would probably be a UNIBUS adapter for migration of existing controllers. 42 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Miscellaneous In the Q&A which followed, the comment was made that "new processors will probably NOT have MBAs." VAX/VMS SIG FALL 1983 HANDOUTS Table of Contents PART 1 ____ _ Roadmap to Sessions 1 Questionnaire 21 PART 2 ____ _ VAXcluster Technical Concepts I 1 Productive Programing with Basic 2 VAXcluster Technical Concepts II 29 Connect to Interrupt with DMA 30 Network Working Group 55 Internals Working Group 56 Particle Accelerator Control 57 SCRFT -- How to Use Foreign Terminals Under VMS 61 UNIX* Command Line Parsing 66 Distributed Lock Manager 71 New Mass Storage Architecture 92 Eunice Experience at University of Texas, Austin 138 RMS Tutorial 140 VMS Image Accounting 157 New Compiler Directions in BASIC 163 VMS Data Integrity 187 _______________ *UNIX is a trademark of Bell Laboratories 43 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium Recovery Unit Facility 196 Checkpoint/Restart 201 Performance Monitor for User Programs 207 VMS Performance Management 216 Using New BASIC Features 251 PART 3 ____ _ Mechanics of Proxy Access 280 VMS Terminal Services 287 Practical Approach to VMS Environmental Security 297 VMS Shareable Images 305 Shareable Images for Large User Libraries 330 User Written System Services 333 RMS I/O from C 335 VMS Realtime Performance Test Results 345 DECNet Tutorial 365 VMS Tool Cooperation: A Case Study 403 Introduction to VMS System Management - Tutorial 413 44 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium DATATRIEVE SIG FALL 1983 HANDOUTS Table of Contents Interfacing to VAX-11 Datatrieve via COBOL 1 Datatrieve Application Design Workshop 13 Using Datatrieve-11 to Schedule "Spacesuit" 48 Assignments VAX-11 Datatrieve in Government Financial 52 Management Operations Datatrieve Record Definition Tutorial 91 VAX-11 Datatrieve with Forms Tutorial 113 Multidomain, Multirecord-type Datatrieve-11 140 Data Bases LANGUAGES and TOOLS SIG FALL 1983 HANDOUTS Table of Contents ADA Language System 1 A Structured Language for Commercial Applications 41 Software Development Environment Plan 46 Writing Transportable Software on a VAX 51 Hard Hat PASCAL 53 SAMPLE: Software for VAX FORTRAN Execution Timing 63 Static Analysis/Path Coverage Tools for FORTRAN 67 PCS32: Design and Implementation using VAX-11 C 80 A New Requirements Approach for Software Success 81 45 PAGESWAPPER - May 1984 - Volume 5 Number 11 Westinghouse Report on Fall 1983 Symposium RSX SIG FALL 1983 HANDOUTS Table of Contents RSX SIG Session Notes 5 RSX/IAS Sessions Schedule 6 Dealing with Foreign Magnetic Tape Formats Under RSX-11M 12 Using the Connect to Interrupt ($CINT) Directive 20 MSCAN - An RSX Interprocessor Real-Time System 46 Cheap (FREE?) Networks 65 Introduction to RSX-11M/RSX-11M-PLUS Sysgen 76 How to Implement Timer Support in RSX-11M Drivers 85 The Use of the RSX-11M FCS System from MACRO-11 and Fortran 105 Nifty Things to Do with RSX Indirect Command Files 120 Hows and Whys of ASTs in RSX 140 Indirect Command Files for New Users 165 Overview of an RSX-11M Device Driver 191 FILES-11: The On-Disk Structure 204 Building and Using Resident Libraries 226 One for the Gipper 249 RMS Performance Optimizations 257 INDEX 260 Files-11 Specification 268 46 PAGESWAPPER - May 1984 - Volume 5 Number 11 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 283 Caption: VAX 11/780 to Xerox 8700 "on-line" interface Message: We are currently processing on a VAX 11/780 and outputting on a Xerox 8700 page printer in an "off-line" mode. We would like to interface to an "on-line" system (neither supports the other). Is anyone currently running a Xerox page printer with their VAX system in an "on-line" mode? Contact: Bob Andersen National Computer Systems/PAS 5605 Green Circle Drive Minnetonka, MN 55343 (612) 933-2800 Date: March 26, 1984 INPUT/OUTPUT 284 Caption: Patient Scheduling Database Message: We have a VAX 11/780 running VMS and are looking for an interactive patient/physician scheduling database system for our radiation therapy department. Our patient load is less than 200. Contact: Tim Hall Radiation Therapy Department University of Texas Medical Branch Galveston, TX 77550 (409) 761-2531 Date: April 2, 1984 47 PAGESWAPPER - May 1984 - Volume 5 Number 11 INPUT/OUTPUT INPUT/OUTPUT 285 Caption: VAX-PDP Communication through DR11-Ws Message: We have a PDP-11/34 running RSX and a VAX-11/750 running VMS. DR11-Ws are installed in both machines. We are looking for a way to use the DR11-Ws for file transfers between them. Currently we are using VAXNET through DZ11 lines. It works great but it is slow. Contact: Brent Taylor Anamet Labs 100 Industrial Way San Carlos, CA 94070 (415) 593-2125 Date: April 6, 1984 INPUT/OUTPUT 286 Caption: Software for DECs laser printer LN01 Message: If you have graphics and/or alternate font software for the LN01 laser printer, however incomplete or fragmentary, please contact us. We have none whatsoever. Also, does anyone have the mysterious Appendix C to the laser printer manual? This appendix is referenced in the text, but is missing. Contact: Eric Wicklund High Energy Physics Department University of Wisconsin Madison, Wisconsin 53706 Date: April 9, 1984 INPUT/OUTPUT 287 Caption: Wanted: NAPLPS graphics routines for VAX/VMS Message: Preferably Public Domain software that will run on the VAX. Willing to talk with people who wish to sell currently available software and/or NAPLPS input workstations. 48 PAGESWAPPER - May 1984 - Volume 5 Number 11 INPUT/OUTPUT Contact: Arthur McClinton Mitre Corporation MS W272 1820 Dolley Madison Blvd McLean Va. 22102 (703) 883-6356 Date: April 16, 1984 49 PAGESWAPPER - May 1984 - Volume 5 Number 11 VAX System SIG Committee List VAX System SIG Committee List As of November 2, 1983 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 KMG Fusion Inc. 3621 So 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 50 PAGESWAPPER - May 1984 - Volume 5 Number 11 VAX System SIG Committee List New York, NY 10038 Stephen Gill - Commercial Ball Aerospace P.O. Box 1062 Boulder, Colorado 80306 Don Golden - Overseas Coordinator 500 Corporate Drive Sugarland, TX 77478 Gary Grebus - System Improvement Request Battelle Columbis Labs 505 King Avenue Columbus, OH 43201 Dr. Mark Hale - Education University of Florida 411 Weil Hall Gainesville, FL 32611 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 Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 51 PAGESWAPPER - May 1984 - Volume 5 Number 11 VAX System SIG Committee List 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 52 PAGESWAPPER - May 1984 - Volume 5 Number 11 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 53 PAGESWAPPER - May 1984 - Volume 5 Number 11 INPUT/OUTPUT Submission Form Tear out to submit an I/O item PAGESWAPPER Editor DECUS 249 Northboro Road (BPO2) Marlborough, MA 01752 USA 54 PAGESWAPPER - May 1984 - Volume 5 Number 11 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) 55 PAGESWAPPER - May 1984 - Volume 5 Number 11 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories 505 King Avenue Columbus, Ohio 43201 USA 56