CHAPTER VAX PAGESWAPPER - September 1985 - Volume 7 Number 2 How to Backup to Magtape over DECnet . . . . . . VAX-3 Plugging a Security Leak in CERBERUS . . . . . . VAX-7 The Bedford Store Is No More . . . . . . . . . . VAX-9 More on VMS Timekeeping . . . . . . . . . . . VAX-10 VAX-11 RSX Device Name Performance . . . . . . VAX-11 A Proposal on RMS . . . . . . . . . . . . . . VAX-19 More on a Comprehensive Backup SIR . . . . . . VAX-22 LeLisp: A LISP Environment for VAX/VMS . . . . VAX-23 "It's in the Microfiche..." . . . . . . . . . VAX-27 VAX System SIG Tape Time Bomb . . . . . . . . VAX-31 VMS 4.2 XQP breaks previous privileged code . VAX-32 An Electronic "Campground" For VAX Users . . . VAX-32 Building Efficient Images on VAX/VMS . . . . . VAX-34 Global Section Problems . . . . . . . . . . . VAX-41 System Improvement Request Ballot . . . . . . VAX-44 VAX System SIG Committee List . . . . . . . . VAX-73 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-77 Steering Committee Nominations . . . . . . . . VAX-89 Forms at the End VAX SIG Steering Committee Nomination Form . . VAX-90 VAX Systems SIG Fall 1985 SIR Ballot . . . . . VAX-92 INPUT/OUTPUT Submission Form . . . . . . . . . VAX-94 System Improvement Request Submission Form . . VAX-96 PAGESWAPPER - September 1985 - Volume 7 Number 2 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 (LINKED LIST))" section of the Pageswapper (pertaining to Artificial Intelligence) should be sent to: Terry C. Shannon Technical Editor THE DEC* PROFESSIONAL Magazine 921 Bethlehem Pike Springhouse, PA 19477 USA (215)-542-7008 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. VAX-2 PAGESWAPPER - September 1985 - Volume 7 Number 2 How to Backup to Magtape over DECnet How to Backup to Magtape over DECnet Allen Rueter Mallinckrodt Institute of Radiology 510 South Kingshighway Boulevard St. Louis, MO 63110 In our shop we have 2 VAXs and 3 uVAX IIs but only one has a tape drive. Our 11/730 (SARA) is of the R80/RL02 variety. It would take a lot of RL02s to back up an R80 and even more if you plan to keep 2 cycles. At the Spring 84 DECUS I talked to a man, who works for Evans & Sutherland, and found out some interesting things you can do over DECnet at the DCL level. DEC does not support running backup with output to a tape drive on another node but at a DECnet session we were told you are allowed to write to a mail box! The problem with Backup is it wants to write variable length records. When access the tape over DECnet you need to write fixed length records to tape. This problem can be cured by using the utility CONVERT, with FDL files describing the input and output. On our 730 we have the following file which backs up the R80 to 2 tapes. BckUpDQA0.com $ ! backup dqa0 to lucy::mta0: $ ON ERROR THEN GOTO ERROR_EXIT $ ON CONTROL_Y THEN GOTO ERROR_EXIT $ OPEN/WRITE RMT LUCY::"0=NETDCL2" ! 1) login via proxy $ TYPE SYS$INPUT: ! 2) Please mount tape DQA01 on lucy::mta0: $ INQUIRE yn "Press return when ready to continue" $ ! verify mount and init $ WRITE RMT "Moun MTA0 DQA01" ! 3) mount the tape $ READ RMT s ! to make sure its the $ WRITE RMT "Dism/nounlo MTA0" ! right one $ READ RMT s $ WRITE RMT "Init MTA0 DQA01" ! and initialize it. $ READ RMT s $ TYPE SYS$INPUT: ! 4) Please mount tape DQA00 on Lucy::MTA0: $ INQUIRE yn "Press return when ready to continue" $ ! verify mount and init tape 0 $ WRITE RMT "Moun/assist MTA0 DQA00" $ READ RMT S $ WRITE RMT "Dism/nounlo MTA0" $ READ RMT S $ WRITE RMT "Init MTA0 DQA00" VAX-3 PAGESWAPPER - September 1985 - Volume 7 Number 2 How to Backup to Magtape over DECnet $ READ RMT S $ CLOSE RMT ! 5) $ ! 6) do the backup $ BACKUP/IMAGE DQA0:/IGNORE=INTERLOCK - LUCY::"0=DQA0"/SAVE/BLOCK=4096 $ EXIT $ERROR_EXIT: $ CLOSE RMT $ EXIT The above command file does the following: 1. Starts process on the other node to process dcl commands via proxy access. For more info on proxy see commented out help in sys$help:uafhelp.hlb 2. Tells the operator to mount the 1st tape to be zeroed. 3. Tell the tape node to mount the tape to verify it's the right one. Dismount it and initialize it. The '$ READ RMT s' commands are used to keep things synchronized otherwise the 730 writes the commands faster than the 750 processes them and the messages on the console get out of sync with reality. 4. Mount and initialize the other tape. 5. End the network dcl process with the correct tape on the drive. 6. Backup through CONVERT to tape. If our operator is on his toes, the backup takes 1 hour over Ethernet to a 75 ips Kennedy 9100. In addition I set large scratch files to nobackup with the set file command, such as PAGEFILE.SYS and SWAPFILE.SYS to reduce the time the backup takes. The NETDCL2 file which process the command from BCKUPDQA0 is as follows: $ ! process dcl commands over the network and reply with status $ ! to start this try OPEN /WRITE RMT node::"0=NETDCL" $ SET VERIF $ OPEN RMT SYS$NET:/READ/WRITE $NXT_LINE: ON ERROR THEN CONTINUE $ READ RMT LINE/END=EXIT $ SET VERIF $ 'LINE $ SET NOVERIF $ S = $STATUS VAX-4 PAGESWAPPER - September 1985 - Volume 7 Number 2 How to Backup to Magtape over DECnet $ WRITE RMT S $ GOTO NXT_LINE $EXIT: EXIT It simply takes in each command, executes it and replies with the status Again this is to help keep things synchronized. A log of what happens (for debugging) can be found in NETSERVER.LOG in the default directory under which the process was started. These command procedures are somewhat error prone. We usually just have the operator start all over if something goes wrong. The DQA0 command file which mounts the tape and invokes CONVERT is a follows: $ ! network tape drive $ SET VERIF ! for debugging $ SET PROC/PRIV=VOLPRO ! the account needs $ ! volpro or setprv $ ALLO MTA0 $ MOUNT MTA0 DQA00/BLOC=4096 ! at 8192 we got over runs $ CONVERT SYS$NET:/FDL=NETIN MTA0:SARADQA0.DAT/FDL=MTA0OUT $ DISM MTA0 $ DEALLO MTA0 $ EXIT The DQA0.com file does have potential problems. The 1st problem being some one could allocate the tape drive between initializing and the backup starting. Secondly if the tape node system is slow, you may get a LINKEXIT error, which can be caused by the incoming and outgoing timers being set to low (Use NCP SHOW EXEC CHAR to check). Other restriction include no generalized method to support different tape labels, so for now we just keep different COM files. I suppose one could use NETDCL2 to create some logical names at the group level and then generalize this command procedure further. Currently we only have need to backup our R80. Those of you with 11/780's or faster machines may be able to block the records at 8192, on our machines things would just seem to hang when either node got real busy. With the block size set to 4096 we have not had any problems. In addition an account was create to do the backups with its BYTLM set to 20480, this lets DECnet work more efficiently. With SYSGEN we adjusted the number of free LRP's, before the backup starts, up to about 12 on the receiving node. The NETIN fdl file for CONVERT's input from SYS$NET: is as follows: IDENT 12-JUL-1984 15:16:24 VAX-11 FDL Editor SYSTEM VAX-5 PAGESWAPPER - September 1985 - Volume 7 Number 2 How to Backup to Magtape over DECnet SOURCE VAX/VMS FILE ORGANIZATION sequential RECORD CARRIAGE_CONTROL none FORMAT variable SIZE 4096 and the MTA0OUT fdl file for CONVERT to write to tape is IDENT 11-OCT-1984 09:06:52 VAX-11 FDL Editor SYSTEM SOURCE VAX/VMS FILE ORGANIZATION sequential RECORD CARRIAGE_CONTROL none FORMAT fixed SIZE 4096 This has been working quite well for over a year in our shop. One of the nice features is, that convert automatically asks for the next tape. Our operator uses the following command after mounting the next tape. $ REPLY/TO= "DQA01" where DQA01 is the label to be put on the second tape. This backup tape, and the initial VMS distribution media along with a backup of SYS$SYSDEVICE:[SYS0...] to RL02s, to speed up the upgrade from V3.0 to V3.6, works. I have not been able to restore the disk from the tape, back across the network. I have managed to borrow a tape drive from another system and restore the whole disk without any problems. I went through the following steps to restore the system. 1) Load and install the system from the distribution media. 2) Then using our weekly backup of [sys0...] I brought the system V3.0 to V3.6 with: $ BACKUP DQA1:SYSTUFF.BCK/SAVE - DQA0:[*...]/NEW_VER/OWNER=ORIG VAX-6 PAGESWAPPER - September 1985 - Volume 7 Number 2 How to Backup to Magtape over DECnet 3) reboot 4) PURGE/Keep=1 DQA0:[*...]*.* ! to get rid of old V3.0 system files 5) BACKUP MTA0:DQA0BCK.DAT/SAVE DQA0:[*...]/OWNER=ORIG Ignore the error message about the system files that already exist or use the /SELECT with what ever directories you want to put in first. Another alternative, if one could find enough disk space, is to copy the saveset from tape to disk, then backup across the net from disk to disk. Or if one is not gifted with disk space(is anyone?), with liberal use of the select clause one could restore things in chunks. Now if it was only possible to pass and retrieve optional data at the DCL level, I would only need to have one NETTAPE account and I could pass the label as optional data. Until that happens I copy a new login.com file, like the above, before I do my remote access. Plugging a Security Leak in CERBERUS Johan Hamaker Netherlands Foundation for Radio Astronomy P.O. Box 2, 7990 AA Dwingeloo The Netherlands telex 42043 srzm nl telephone: 05219-7244 From the Editor's little notes in recent Pageswappers I gather that my description of the CERBERUS package for executing command procedures with temporary privileges (Pageswapper, January 1985) has roused some interest. I hope that this note comes in time to prevent security disasters from happening on sites where CERBERUS is being adopted. One of the crucial elements in the package is that it controls all possible exits from the privileged process state, insuring that the user cannot regain control with more than his regular authorised privileges. I recently discovered that, in the form in which I proposed it, CERBERUS gives its users access to a very easy uncontrolled exit. Indeed, before attempting to execute any command line, DCL tries to substitute the first word (the "command verb") in the line by looking for a symbol with that name. Thus, the user can override normal execution of any verb by redefining it, e.g. VAX-7 PAGESWAPPER - September 1985 - Volume 7 Number 2 Plugging a Security Leak in CERBERUS IF="STOP!" (The exclamation mark will cause the remainder of the line to be treated as comment.) With this definition, the first IF statement in the privileged procedure will cause an immediate return to DCL command level, without giving CERBERUS a chance to retract the temporary privileges. The solution is simple: CERBERUS or the privileged procedures themselves must override any redefinitions which the user may have made by their own, e.g. IF="IF" (Note that the definition must be LOCAL so it will take precedence over all previous ones!) To make this method work also for those cases where a privileged procedure might contain abbreviated commands, one should allow for all possible unambiguous forms of a command, e.g. PU*RGE="PURGE" Although the number of DCL verbs is considerable and is likely to grow in the future, the extra overhead of redefining them all was found to be unnoticeable to CERBERUS's users. Like DCL symbols, logical names could also be abused, e.g.. to access files other than those on which a privileged procedure was designed to operate. Either CERBERUS or the privileged procedure itself should take the necessary precautions. VAX-8 PAGESWAPPER - September 1985 - Volume 7 Number 2 The Bedford Store Is No More The Bedford Store Is No More by Larry Kilgallen, Pageswapper Editor A great advantage of being in the Boston area (and somewhere in California as well I am told) was the existance of a DEC Bookstore. Many manuals were in stock, and they could special-order others. I placed an order there for my VMS V4 documentation set and on the day they first came in (the Bookstore staff notified me) I learned I was not the only one, as the place was overflowing with V4 doc sets. There is a great satisfaction in being able to walk in, buy something, and carry it out (even if it takes up three boxes). I contrast this particularly with the non-service from DECdirect who on my last encounter spent 18 months to NOT send me the update I had ordered. I sent letters every three months and struggled each Symposium to find someone who would own up to representing DECdirect. There are always plenty of technical writers to discuss the contents of the manuals, but never anyone to talk about the difficulty of getting them. Early in July I was quite disappointed to stop by the DEC Bookstore and discover it did not exist anymore. There are Business Product Centers (or is that IBM's name for the same thing?) but the Boston instantiation seems to deal exclusively in word processing and booklets on how to conquer fear of computers. Nothing for VAX fans. I understand that DEC makes changes now and then, but it is quite a disappointment to have them cancel the part that works. So I look for alternatives. A couple of months ago I signed up on speculation with the "Electronic Store", but didn't really put a lot of work into using it (almost as painful as the machine run by TSC) until the DEC Bookstore was no longer there. Trying to get a VAX Pascal documentation set (greatly improved for Version 3.0, in case you hadn't heard) I found "you can't get there from here". Calling their help line (would you believe it, the person who answered the phone was the one who knew the answer!!!), I learned that taking the "purchase" option when rummaging around in the "VAX Pascal" section does not entitle you to order the full set of kits listed in that section. Instead, you must go back up to the main menu and choose an express purchase option. (Sigh)... So I was able to order Pascal documentation, rather than walk in and buy it. It hasn't arrived yet, so tune in next month for the next installment of "Convincing DEC to Sell You Documentation". VAX-9 PAGESWAPPER - September 1985 - Volume 7 Number 2 More on VMS Timekeeping More on VMS Timekeeping Science and Engineering Research Council Rutherford Appleton Laboratory Space and Astrophysics Division Chilton, DIDCOT, Oxon Oxfordshire, OX11 0QX England Tel Abingdon (0235) 21900 Ext 5372 Direct Line (0235) Telex 83159 RUTHLB G Fax (0235) 832277 10 May 1985 Mr Larry Kilgallen Pageswapper Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Dear Mr Kilgallen Don Golden's letter in the December 1984 Pageswapper has prompted me to SPR a solution to the 'time zone' problem. I fully agree with his analysis, and my proposal differs from his only in detail. First, the 'time zone' parameter must not be an integer as some time zones differ from UTC (Universal Time, the successor in civil timekeeping to GMT) by n.5 hours (Singapore for example). Second, the best flavour of time to use as the standard is, in my opinion, International Atomic Time (TAI). Unlike UTC, which is tweaked every so often to fudge it back roughly into line with the Earth, TAI does not have leap seconds which might conceivably cause problems in a real time system. TAI currently differs from UTC by (exactly) 22 seconds, and jumps by one second only every couple of years; so most sites can pretend standard time is 'GMT'. Really punctilious sites can include the TAI-UTC in the time zone parameter. Yours sincerely Patrick Wallace, Starlink Project Manager VAX-10 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance VAX-11 RSX Device Name Performance David R. Butenhof, VAX-11 RSX Project Leader DEC, ZKO1-3/H21 110 Spit Brook Road Nashua, NH 03062-2642 July 1, 1985 A B S T R A C T The purpose of this article is to explain the need for "$$n" names, and why the implementation of $$n names in VAX-11 RSX Version 1.0 resulted in a severe performance degradation. This article will also explain how the VAX-11 RSX development group plans to correct these problems for VAX-11 RSX Version 2.0, and gives estimates of how much the performance will improve. Why things had to change Before VAX/VMS Version 3.0, a VAX/VMS device name had the format ddan: where dd represented the device type ("DR" for Massbus disks, "DM" for RK06 or RK07, etc.), a represented a controller letter, and n represented a decimal unit number, technically in the range of 0 to 32767, but usually less than 16 (with a few exceptions such as remote terminals and mailboxes). This format is not much different from the traditional RSX-11 device name, which has the format ddn: where dd represents the device type (almost as VAX/VMS device names, with a few exceptions like "MM", which VAX/VMS refers to as "MT"), and n represents a unit number in the range of 0 to 377 (octal). All that was necessary for the RSX-11 Application Migration Executive, (or "AME", which was then a bundled component of VAX/VMS), to translate a VAX/VMS device name into an RSX-11 device name was add the controller letter. There is no RSX-11 analogue for a controller letter. This was done by treating the controller letter as a 16 unit offset (as if "DRB0:" were actually "DRA16:"). The actual VAX/VMS unit number could then VAX-11 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance be added to this value, and the result used as the RSX-11 unit number, unambiguously. If the aggregate unit number ((controller * 16) + unit) exceeded 377 (octal), the device name could not be translated, but this condition rarely occurred. In fact, the code did not even consider the possibility, and would simply use the low byte of the resulting value. The RSX-11 device name could be converted to a VAX/VMS device name by simply reversing the process. The unit number was divided by 16, the integer result added to the ASCII character "A" became the VAX/VMS controller letter, and the remainder became the VAX/VMS unit number. Several special cases were necessary for devices like remote terminals and mailboxes that always have "A" controllers regardless of the magnitude of the unit number. When the concept of "rooted directories" was introduced in VAX/VMS Version 3.0, the conversion algorithm no longer worked well. To treat rooted directories so that RSX-11 applications would function similarly to native mode VAX/VMS applications, it was necessary for the RSX-11 AME to treat rooted directories as "virtual devices." This meant that the root directory name could not be separated from the device name itself, nor could the root directory name "DRA0:[SYS0.]" be equivalent to the plain device name "DRA0:". Obviously, the rooted directory name could not be mapped into the RSX-11 physical device name format. Rather, the RSX-11 AME used the VAX/VMS physical device name, but maintained internal context, including the full rooted directory name and the directory's file identification value. Therefore, while the RSX-11 application might see the device "DR0:", the AME used the full root directory context "DRA0:[SYS0.]". Unfortunately this convention was ambiguous. When a task assigned a LUN to "DR0:", the RSX-11 AME had no way to determine whether the task actually intended to use the rooted directory "DRA0:[SYS0.]", or the physical device "DRA0:". Therefore, a root directory could be associated with an RSX-11 device name only through the initial parsing operation. A subsequent assignment of another LUN to the same device would not propagate the root directory context. For example, if 'LB = "DRA0:[SYS0.]"', then assigning a LUN to "LB0:" would preserve the root directory context, and accessing a file via that LUN would result in the correct "virtual MFD" directory context. But a GLUN$ on that LUN would return a device name of "DR0:", and a subsequent LUN assignment, using that device name, would result in assignment to the physical device "DRA0:" with no root directory context. If this were not the case, it would have been impossible for a task to access both "LB:" and "DRA0:". The VAX/VMS Version 3.0 RSX-11 AME support of rooted directories was at best a temporary and barely satisfactory workaround. VAX-12 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance With the advent of VAXclusters under VAX/VMS Version 4.0, this workaround was impractical. Even aside from the special case of rooted directories, VAX/VMS physical device names such as "HSC001$DUK1000:" cannot be mapped to RSX-11 device name format. Furthermore, it is quite possible that another device called "HSC002$DUK1000:" could exist within the same VAXcluster. Not only is the aggregate unit number of each of these names far beyond 377 (octal), but the old-style two character device name "DU" and the unit number would be insufficient to uniquely describe the target device in any case. The full physical device name is absolutely essential. This, combined with the problem of rooted directories, and the original problems with mailboxes and remote terminals, mandated that VAX-11 RSX (which was being unbundled from VAX/VMS during the development of VAX/VMS Version 4.0), finally remove the direct connection between VAX/VMS physical device names and "emulated" RSX-11 device names. The $$n connection The problem was to reduce the full VAX/VMS physical device name and rooted directory to something which an RSX-11 task could perceive as a physical device name, and which the VAX-11 RSX AME could uniquely and bi-directionally connect with the original VAX/VMS name. A number of proposals were considered which would minimize the impact on VAX-11 RSX users. Most of these proposals had severe drawbacks, including: o Preventing RSX-11 tasks from using VAX/VMS logical names such as SYS$SYSTEM, since they do not have an RSX-11 device name format. o Requiring all VAX/VMS logical names definitions to be confusingly re-duplicated (or modified) so that the logical name closest to the physical name (with the "concealed" translation attribute) would resemble an RSX-11 device name. o Combining both problems, and adding to user confusion, by using any logical name in the translation path which resembled an RSX-11 device name. We decided that it was important that the design we chose fulfilled the following criteria: VAX-13 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance o Could be documented clearly and simply (with the realization that any implementation which solved the problems would appear confusing compared to the previous behavior), o Was consistent and predictable, o Did not exclude or unnecessarily complicate the use of standard VAX/VMS logical names already defined for native mode use. The final decision was to implement a new RSX-11 "physical device name," something currently unassigned to any device. We chose "$$." All VAX/VMS devices and root directories on the system would appear to RSX-11 tasks as units of the device "$$". These devices would be described to the VAX-11 RSX AME through VAX/VMS logical names, which it would translate when presented with a physical device name. This was relatively easy to document (although still somewhat confusing simply because it diverged so radically from the previous state of affairs); consistent and predictable because a simple "SHOW LOGICAL $$*" would show all $$n name translations; and would not exclude the use of ordinary VAX/VMS logical names, since the VAX-11 RSX AME would associate the VAX/VMS physical device name and root directory with a $$n name totally independent of whichever VAX/VMS logical names may have been translated to arrive at that device name. VAX-11 RSX Version 1.0 implementation The VAX-11 RSX Version 1.0 development schedule was constrained by the VAX/VMS Version 4.0 development schedule. Though we were technically under the management structure of the RSX-11 group, in fact we were still working for VAX/VMS. It was necessary that VAX-11 RSX Version 1.0 be available to existing customers when VAX/VMS Version 4.0 went to field test, and because of this, we did not have the freedom to take development risks. This constraint meant that $$n names had to be implemented within the current structure of the VAX-11 RSX AME, without the major redesign effort actually required for the feature. The AME code implementing the ALUN$ and ELP$ (extended VAX/VMS parse operation) directives, the modules most strongly affected by the implementation of $$n names, were already unstructured and inefficient. Adding the new features without totally redesigning the code meant dramatically increasing the inefficiency, but we had to accept that in order to insure that a functionally correct AME would be available when VAX/VMS VAX-14 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance Version 4.0 was ready for field test. The RSX-11 physical device name (two ASCII characters and a one-byte binary unit number) supplied to the ALUN$ directive was first converted to an ASCII string in the RSX-11 ddn: format, with n in octal. The AME then attempted to translate the result as a logical name. If there was no such logical name, it would then reformat the device name as a VAX/VMS device name in the ddan: format, with n in decimal. It would attempt to translate the resultant name, and repeat this until it reached the physical device level. If it found a translation string which included a rooted directory name, it would retain the logical name as the "VAX/VMS physical device name" for the LUN. Once the AME had a VAX/VMS physical device name, it needed to calculate the equivalent RSX-11 device name, which could be returned to the RSX-11 task on a GLUN$ directive (or the new GDVI$ directive). The AME calculated the equivalent by scanning a list of pre-defined logical names, including LB, SP, and the $$n names, until it found one that translated to the same VAX/VMS physical device name (and root directory, if any). For each of these, the logical name needed to be translated to the level of a physical device name and root directory. The device name had to be separated and resolved to a physical device name using $GETDVI to remove formatting variations (so that a $$n name defined to "DR:" would match against "DRA0:", for example). The physical device names were compared; if they matched, and if root directories were present in both strings, they were also compared. This process was obviously slow, and often required large numbers of logical name translations during the initialization of average RSX-11 tasks. VAX-11 RSX Version 2.0 implementation The VAX-11 RSX development group was not constrained by time and schedule for Version 2.0, so we decided to reimplement $$n names correctly. The code implementing ALUN$ has been almost totally redesigned and reimplemented. The code for ELP$ has been drastically modified. Many subroutines used by these routines have been totally redesigned, and the associated data structures have also been redesigned. This reconstruction not only provides improved performance, but also enhances capability: VAX-11 RSX Version 2.0 supports (limited) use of VAX/VMS search list logical names from compatibility mode. VAX-15 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance The redesign of the code and data structures requires fewer translations to be done when initially processing a device name. In most cases, no translations (or other VAX/VMS system services) are necessary when subsequently operating on that same device, which was not possible for VAX-11 RSX Version 1.0. Furthermore, when LB, SP, or a $$n name is translated the first time, the value is cached so that the same name need not be translated again. This cache can be disabled (via the logical name RSX$DEVICECACHE) if a site desires the ability to change (or add) $$n names while an RSX-11 task is running (note that dynamic $$n names -- with unit numbers of 350 (octal) and above -- are never cached). Data structures which are re-used frequently are kept on "lookaside" lists rather than being deallocated when not in use, reducing the overhead of reusing them. The combined result of these changes is that VAX-11 RSX Version 2.0 is, for most RSX-11 tasks, between 2 and 3 times faster than VAX-11 RSX Version 1.0, even with the additional overhead and complication of supporting search lists. In extreme cases(1), VAX-11 RSX Version 2.0 is up to 54 times as fast as VAX-11 RSX Version 1.0. The numbers The performance of VAX-11 RSX Version 1.0 and Version 2.0 were measured in terms of pagefaults, CPU time, and elapsed (clock) time. The tests were run on a moderately busy VAX 11/750. The system is configured as a "common system disk" (although the processor is not in a VAXcluster), and the VAX-11 RSX Version 1.0 tests used 'LB = "SYS$COMMON:"' while the VAX-11 RSX Version 2.0 tests used 'LB = "SYS$SYSROOT:"'. This results in biased figures (the search list reduces performance slightly), but is more representative of how the respective versions would actually be used. Performance measurements were done using the field test version of VAX-11 RSX Version 2.0. Five test sets were compared: 1. VAX-11 RSX Version 1.0 2. VAX-11 RSX Version 2.0 with $$n name caching and no unit number limits(2). --------------- 1 A test designed to simulate worst-case ALUN$ performance, by alternately reassigning a single LUN between two devices mapped by "$$346" and "$$347", 100 times. VAX-16 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance 3. VAX-11 RSX Version 2.0 with $$n name caching, and unit number limits of 10 (octal) and 340 (octal) (the fastest case measured). 4. VAX-11 RSX Version 2.0 with $$n name caching disabled, and no unit number limits (the slowest case for VAX-11 RSX Version 2.0). 5. VAX-11 RSX Version 2.0 with $$n name caching disabled, and unit number limits of 10 (octal) and 340 (octal). Seven (7) test cases were used in each set. Each test set was repeated 20 times (to minimize the impact of fluctuating system usage). The reported values are the average of the 20 repetitions. 1. "MCR MAC RPR,RPR/-SP=RPR", assemble a small Macro-11 program. 2. "MCR TKB RPR,RPR/-SP=RPR", task build the same task. 3. "MCR F77 REQUES,REQUES/-SP/LI:7/CO:10/TR:ALL=REQUES", compile a small FORTRAN-77 program. 4. "MCR LBR LB:[1,1]SYSLIB.OLB/LI", type a listing of the contents of SYSLIB.OLB. 5. "MCR PIP A.B=*.*/LI", write a listing of the current directory to a file (the current directory had a large number of files). 6. "MCR PIP A.B/PU", purge 3 obsolete versions of a file. 7. "RUN ALUN", run the ALUN test mentioned previously. It assigns a LUN to "$$346:" and then to "$$347:", repeating this 100 times; this test forces maximum turnover of internal data structures, and therefore creates the most work for the AME. Because this task does little other than ALUN$ directive calls, this test also serves as a rough measure of the actual ALUN$ performance, as opposed to the other tests which provide the "real world" effect on tasks doing useful work. On the average, with default caching enabled (no $$n unit number limits in effect), VAX-11 RSX Version 2.0 is about 2.41 times as "fast" (measured in terms of elapsed CPU time) as VAX-11 RSX --------------- 2 This is controlled by using RSX$DEVICECACHE; see the VAX-11 RSX Version 2.0 Compatibility Mode Reference Manual for information on using this logical name. VAX-17 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX-11 RSX Device Name Performance Version 1.0. The actual test values range from a low of 1.14 for the "MCR PIP A.B=*.*/LI" command to a high of 3.79 for the "MCR TKB RPR,RPR/-SP=RPR" command, not including the "RUN ALUN" test, where Version 2.0 was 45.26 times as fast as Version 1.0. On the average, Version 2.0 ran with 1.02 times fewer page faults and used 2.79 times less elapsed clock time. The following summarizes the average improvement of VAX-11 RSX Version 2.0 over VAX-11 RSX Version 1.0 for each of the Version 2.0 test sets mentioned above: o $$n cache, no limits: page fault improvement 1.02, CPU time improvement 2.41, clock time improvement 2.76 o $$n cache, limits of 10 and 340: page fault improvement 1.03, CPU time improvement 2.62, clock time improvement 3.07 o no $$n cache, no limits: page fault improvement 1.03, CPU time improvement 1.97, clock time improvement 2.00 o no $$n cache, limits of 10 and 340: page fault improvement 1.05, CPU time improvement 2.35, clock time improvement 2.72 In a few simple tests, it appears that the VAX/VMS Version 3.7 AME runs as fast as VAX-11 RSX Version 2.0 (with default caching) or slightly faster. However, fair testing is not possible as the VAX/VMS Version 3.7 AME cannot be made to run under VAX/VMS Version 4.0. It is inevitable that the current and future versions of the VAX-11 RSX AME will be slower than the original, because more needs to be done to emulate the RSX-11 environment under VAX/VMS. We have dramatically improved the performance of VAX-11 RSX Version 2.0 as compared to Version 1.0. We will continue to try to provide the best practical performance, while maintaining compatibility with VAX/VMS and improving our compatibility with RSX-11 in future versions of VAX-11 RSX. We appreciate your patience through the difficult adjustment period as we unbundled VAX-11 RSX from VAX/VMS, while maintaining and extending the RSX-11 environment under VAX/VMS Version 4.0. This article has been an attempt to help you to understand why some of the changes have occurred. VAX-18 PAGESWAPPER - September 1985 - Volume 7 Number 2 A Proposal on RMS A Proposal on RMS Jeffrey S. Jalbert J C C (614)587-0157 This note is the result of a question asked at the "Digital Asks the DEC Users" session that was held on Monday at the New Orleans Symposium. It contains several comments, a suggestion, and an offer. The symposium question had to do with the desirability of a specific additional feature for RMS. Why, I asked myself, shouldn't I vocalize some of those features I would like to see in RMS. This led to a further thought, why not solicit, compile, and publish a focused set of requirements from the entire VMS community? This letter is born of those thoughts. Features of interest to me are: 1. Multi-datatype segmented index Often we have a need to design an index which is comprised of several fields. This can be accomplished using the segmented string keys available with both prologue 2 and prologue 3 files. It is not convenient, however, to keep all such fields as string datatypes, especially when such fields are used in calculations and our programming language is FORTRAN or BASIC. Why be stingy? We would like to see any valid VMS datatype as a segment in such an index. 2. Read backwards The sequential nature of indexed sequential files is often useful to "locate" oneself in a file. One randomly reads a record and then reads successive records sequentially (by index.) This process is called "dynamic" access. We have as frequent a need for dynamic access both in the forward as well as BACKWARD directions. Forward alone is not enough. If we cannot have both forward and backward, we would like to be able to define an index maintained in reverse sorting order. We understand that this may require the definition of additional indices. VAX-19 PAGESWAPPER - September 1985 - Volume 7 Number 2 A Proposal on RMS We would also like to read sequential and relative files backwards. Often, the most recent data is what we are interested in. 3. Speed Of course, we all want speed improvements for random ISAM retrieval and insertions , but what will we give up? For us the answer is "sequential". Random yes, sequential no. I believe "the other" computer company calls this type of indexed but non-sequential file organization "HDAM", hashed direct access method. Such an organization should allow RMS to avoid the bucket split issues that plague the current ISAM organization. We are in the habit of creating non-unique indices though. We cannot afford to have records float too much. Thus, we would like to see the RFA's of the records remain fixed (and as permanent as today) in such files. We can thus process HDAM files with techniques we use today. HDAM files should be able to support multiple indices as well as the new index features that are noted above. Lets all recognize the dramatic decrease in the cost of disk storage, by a factor of 100 in the past ten years. We would also be prepared to pay a bit in file size too. (Hashing techniques work best when there are more record slots available than records to go in them!) Of course we will read HDAM files sequentially. When such files are read sequentially we expect to receive a record stream in no particular order. We are prepared to accept such strange orders as long as RFA's will remain fixed. We are also prepared to receive records in a non-dependable order for sequential reads. 4. Dynamic indices We do a lot of application design and often find a need to add indices to existing files. We have obtained significant performance improvements when doing so. However there is a problem to this -- what do we do if the file is 200,000 blocks and we have only 50,000 blocks free? That problem is real and pressing. Today we spend hours tossing files onto a backup tape, freeing space, reorganizing, and then restoring the archived files. It seems to me that this is unnecessary. We would like dynamically to add and delete indices for an indexed file. VAX-20 PAGESWAPPER - September 1985 - Volume 7 Number 2 A Proposal on RMS 5. In-place reorganization This issue goes along with the one mentioned above. When dealing with systems that have limited disk storage, it would be extremely useful to reorganize files in place. Sure we save the backup tapes, but it may be that the tape drive is located on another system that is accessible only via slow-speed DECnet. If you would like to contribute your entries to this list or comment on mine, please send a note to: Jeffrey S. Jalbert J C C P.O. Box 381 Granville, Ohio 43023 I will compile all comments and additional suggestions and report them back to you (and VMS engineering) in the January issue of the Pageswapper. If this offer prompts an extensive comment from anyone, TU58's and 9-track 1600 bpi tape will assist in inclusion of those comments within the promised report. VAX-21 PAGESWAPPER - September 1985 - Volume 7 Number 2 More on a Comprehensive Backup SIR More on a Comprehensive Backup SIR Lawrence J. Chiano, MIS Manager Sippican Consultants International, Incorporated Computer Group/SCI 1033 Massachusetts Avenue Cambridge, MA 02138 (617) 868-1200 ext 460 Regarding the June 1985 Pageswapper article by Andy Davenport of Harvey Mudd College, I would like to add the following suggestion. Allow the /SELECT= and /EXCLUDE= qualifiers to apply temporary filename field defaults, as do other DCL commands which use filenames for input. For example: If I want to restore the list of files, [MYDIR]A.B, [MYDIR]C.D, [MYDIR]E.F, I need to use the following BACKUP command: BACKUP/SELECT=([MYDIR]A.B,[MYDIR]C.D,[MYDIR]E.F) I would like to be able to use: BACKUP/SELECT=([MYDIR]A.B,C.D,E.F) Currently the shorter version of the BACKUP command will select files C.D and E.F from any and all directories that are on the BACKUP save set. this is contrary to other DCL commands such as COPY, PRINT, DELETE and DIRECTORY. VAX-22 PAGESWAPPER - September 1985 - Volume 7 Number 2 LeLisp: A LISP Environment for VAX/VMS LeLisp: A LISP Environment for VAX/VMS Lee C. Rice Marquette University Department of Philosophy Milwaukee, WI 53233 The Marquette user community has had an active group of students and researchers working in Lisp and artificial intelligence for several years. Some early work was done in Franz Lisp (running in UNIX compatibility mode on our cluster of VAX-11/785s) and, beginning in 1983, in InterLISP. Both of these Lisp environments, like the VAX LISP announced by DEC early in 1985, place enormous demands upon their host systems. In a large multiuser environment such as Marquette, even InterLISP running under native VMS produced a marked degeneration in response time. In 1984 we became aware of LeLisp, a system promoted as highly efficient and extremely portable. The system was created in France by the INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE (Domaine de Voluceau, B.P. 105, 78153 Le Chesnay, France), and the VAX/VMS version is currently separately supported by the ECOLE NATIONALE SUPERIEURE DE TELECOMMUNICATIONS (46 rue Barrault, 75634 Paris Cedex 13, France). In addition to VAX/VMS, UNIX, and six other machines, the system is currently under development for still other operating systems and hardware. LeLisp is wholly written in the virtual machine language LLM3, which was implemented by INRIA as a means of efficiently moving the language into new environments. VLISP was chosen as its base language, since this has proven more efficient than either Franz Lisp or InterLISP. The initial design of the language included compiler and debugging support, and was undertaken with a view to user extensibility. Benchmarks of a variety of programs subsequently published by INRIA indicate that LeLisp is approximately 50% more efficient than Franz Lisp, InterLISP, or even the LISP Machine (Symbolic-3600). Our experience with it at Marquette has been highly favorable, and we have experienced no problems in response time degradation even during peak periods, with as many as 30 users on a single VAX working in LeLisp. VAX-23 PAGESWAPPER - September 1985 - Volume 7 Number 2 LeLisp: A LISP Environment for VAX/VMS THE LELISP ENVIRONMENT Entry into the interpreter loads a default core image containing about 2000 precompiled Lisp functions. While it is possible to save and reload entire user-created core images for the extensive development of large applications, the default image satisfies most user needs. LeLisp supports four types of functions: EXPRs (which evaluate their argument lists before execution), FEXPRs (no evaluation), MACROs, and a special macro form called the DMACRO. The LEXPR functional type of Common Lisp can be defined in LeLisp as a special form of EXPR. Predefined functions include all of the standard MAP and EVAL functions of Common Lisp, with extensions of many of these to the VECTOR, which LeLisp recognizes as a distinct object type. LeLisp is also particularly strong in control functions, which include not only the classical COND, iteratives (PROG, PROG1, PROGN), but also IF, WHEN, UNLESS, WHILE, SELECTQ, REPEAT, and FOR. As well as a rich array of recursive control function, LeLisp also provides the possibility of iterative definitions, which makes it an ideal environment for learning by those more experienced with nonrecursive structures. Recursions are also optimized both by the interpreter and compiler, which minimize stack size and have special forms for handling tail recursions. An infinite table of integer squares, for example, can be printed with no stack overflow. The Lisp interpreter recognizes both integers and floating point numbers, and also has functions for generic arithmetic which provide automatic conversion. Three additional computational packages are also provided and loadable from user libraries. The first of these, extended integer arithmetic, provides integers of up to 65535 digits. The second is a floating point library which allows calculation to arbitrary precision. Finally, new with Version 15 of LeLisp is a program for rational arithmetic, Q-Numbers of the form (x/y), which provides standard rational arithmetic functions without roundoff errors, as well as a complete package of functions for converting from and to floating point equivalents. Because all symbol names in LeLisp are packaged, name collisions and local parameter capturing are avoided by both the interpreter and compiler. Several packages are currently provided in the user libraries, and individual users may create their own interned and auto-loadable packages easily. LeLisp provides complete buffered I/O mechanisms on both terminal and text files, as well as an independent raw output mechanism for the terminal. Buffered I/O may be controlled by default software interrupts, but these may be fully controlled by the user. Error handling is provided by devices similar to VAX-24 PAGESWAPPER - September 1985 - Volume 7 Number 2 LeLisp: A LISP Environment for VAX/VMS those found in MacLisp, by a mechanism for exceptions and local exits which is also under complete user control. The LeLisp compiler is fully compatible with all interpreted code, and operates in two passes. It provides a runtime execution improvement at the order of about 10 times, and is quite small, so that compilation time is also typically quite short. The first pass produces LLM3 code in LAP form, which is optimized and converted to binary code by a machine dependent loader on the second pass. Full trace, debug, and autoload facilities are also provided within the interpreter. These enable the production of personally customized environments for developing and testing programs. Three editors are also provided. PEPE is a line oriented editor which understands Lisp code and can evaluate functions being edited. EMACS is a full screen editor with extensive customizing capabilities. BIGMACS, still under development, includes a text editor, hierarchy editor, and a tree editor for the definition and manipulation of new Lisp data structures. Version 15 of LeLisp also provides full integration with VMS by enabling the user to execute most DCL commands from within Lisp via the bang command (e.g., !EDT, !MAIL, !DIR). This holds the Lisp user environment in suspension pending execution of the command, and then returns the user to Lisp with all global variables intact. In addition to the user libraries which they provide and support, INRIA and ENST also distribute libraries of utilities contributed by users. Their number has grown steadily over the past year. There are presently over 200 European sites for LeLisp. DOCUMENTATION AND SUPPORT When we received the LeLisp system in 1984, all available documentation was in French. We were particularly impressed with the LeLisp Manual. It is clear, well organized, and contains over 2000 examples of Lisp functions. The other Lisp manuals in our experience were poorly organized, lacked adequate examples, and badly written. I undertook the translation of the LeLisp Manual at once, and tested in as a general introductory text in a course offered at Marquette during the spring semester of 1985. The complete LeLisp Version 15 Manual was completed in June of 1985, and is approximately 250 pages in length. VAX-25 PAGESWAPPER - September 1985 - Volume 7 Number 2 LeLisp: A LISP Environment for VAX/VMS Another support library included with LeLisp also interested Marquette users. CEYX is a Lisp extension which enables creation and manipulation of new data structures and objects. Objects are defined as the combination of a record-like structure with a set of semantical properties which are the basic operations to be performed on these structures. CEYX resembles SMALLTALK and FLAVORS in its ability to arrange objects in hierarchical structures which inherit the properties of their ancestors. CEYX is written in CEYX, and is bootstrapped. All primitive operators are thus fully available to the user, and the system is fully extensible. Additional CEYX modules are included in the CEYX library in symbolic form, and may be modified by users for particular purposes. CEYX also includes a precompiler to optimize CEYX code prior to compilation. French documentation for CEYX was in the form of a series of monographs, some of which deal with particular library utilities. My approach to English documentation for CEYX was to include these monographs (in translated form) in a single larger volume which contained a general introduction to CEYX structures as well. This manual, AN ENGLISH LANGUAGE INTRODUCTION TO CEYX, is approximately 160 pages, and contains source code for many of the library utilities. The English documentation for LeLisp and CEYX is provided at no charge in machine readable form (RUNOFF format) by ENST to licensed sites for LeLisp. Also included with this documentation is a set of user utilities contributed by Marquette users, and fully commented. Educational institutions may also profit from a licensing fee (approximately $100) which has been made low enough to encourage the growth of English-speaking LeLisp sites. The licensing form, together with further information for the VMS version of LeLisp, may be secured by writing directly to: Michel DANA, Ingenieur Ecole Nationale Superieure de Telecommunications 46, rue Barrault 75634 Paris Cdex 13 France Those interested in the UNIX or other versions of LeLisp should write directly to INRIA, whose address is given earlier. Several U.S. institutions have already licensed this new and powerful dialect of Lisp, and I would appreciate new licensees' sending me their address as well. We hope in the future to form a special interest group of LeLisp users to share resources and developing applications. VAX-26 PAGESWAPPER - September 1985 - Volume 7 Number 2 "It's in the Microfiche..." "It's in the Microfiche..." Internals Working Group B.C. Dow-Pleines MAGIC ONE 5915 Southwind Drive San Jose, CA 95138-1847 XDELTA - An example of changing the Program Counter My favorite utility on VMS is a little known program called XDELTA. It is useful in the debugging of a device driver and code that runs at a high IPL ( Interrupt Processor Level). XDELTA is not well known in the user community because 1). not all people are writing device drivers or operating system code, and 2). it has a marked impact on the machine when you use it. Basically no one else can be on the machine when someone else is using XDELTA. Only OPA0: can be used to issue commands and observe their results. This is why I like XDELTA so much, it turns the 780 and 785 I use into my own PC! Some of the problems with XDELTA are the lack of documentation and training available. Some documentation can be gotten from the device driver manual and the device driver course offered by DEC, but they don't to my knowledge offer training in the use of XDELTA yet. Maybe the MicroVAX II's will change that. Most people have learned XDELTA either by trial and error, or from another user, or by listening to talks given at the DECUS Symposium. There was an excellent talk given by Jamie Hanrahan on XDELTA at the Spring 85 DECUS. The tape for this talk is probably available through DECUS or Eastern Audio. His notes from the talk might appear in the proceedings for the symposium. Additionally, I'd like to offer some by help by writing this article. Recently I had a problem where I needed to change the flow of control of a terminal driver. I had to make it execute an error path. Since I hadn't written the original code, I wasn't sure why it was failing in the first place. I, like many software people, assumed it was hardware that caused the driver to execute the error routine. After all, software never fails. VAX-27 PAGESWAPPER - September 1985 - Volume 7 Number 2 "It's in the Microfiche..." So my objective in making the terminal driver fail was to simulate a hardware failure. But the question came up of how to do that. Do I walk up to the back of a terminal and pull the plug? Or, I could load a value into a register that would indicate a failure so that the code would branch to the failure routine. But why not just branch to the routine? It would save the extra work of finding the register or memory location that was being tested. Plus, all I wanted to verify was that the driver did indeed crash when it took this path. I'm going to start my example at the point where XDELTA has already been loaded into the system, and the driver has breakpoints in the important routines. I won't discuss how to boot the system with XDELTA, nor how to put breakpoints in the code. Instead I'll refer you, for now, to the device driver manual. Since XDELTA was up, and the breakpoints were set, I started out by getting the driver to execute in the read interrupt routine. To do this I hit a carriage return on the terminal. That worked. The machine then stopped and displayed the XDELTA breakpoint shown below: 1 BRK AT 8000EB63 This is a system breakpoint, and it takes two steps into the code to actually get into the driver code. To make the machine take two steps into the code it is necessary to type S, then wait, then S again. A carriage return is not typed after the S. The OPA0: output for this sequence is shown below. 1 BRK AT 8000EB63 8000EB63/NOP S 8000EB64/RSB S 8015082B/MOVL @(SP)+,R2 I continued stepping through the code until I found the branch point I desired. I needed the address of the branch point in order to figure out the address of the error code. It is the address of the error code that I wanted to load the program counter with it. The problem was to figure out that address. I had the option of 1). guessing, 2). trying my best to figure out how many bytes a BEQL instruction takes, or 3). finding it out in SDA. I chose the last option. But if I was going to use SDA that would mean I would have to get the system back to its running state. Remember, that when XDELTA runs it is actually sitting there waiting for input from the user. That means that no other process is running, and no other activity can happen on the system, that is a user cannot login. So this brings us to then next XDELTA command, ;P. Semicolon P is the VAX-28 PAGESWAPPER - September 1985 - Volume 7 Number 2 "It's in the Microfiche..." command issued that tells the system to continue on until the next breakpoint. I thus proceeded to hit semicolon P enough times to get the system backup to its usual running state. Since I had stepped through the code successfully I had the address of the instructions before the branch. Now it was necessary to use SDA to locate the address of the error instructions. The technique for doing this is to run analyze/system, examine the branch address to make sure it is correct, and then to examine a number of bytes past that address looking for the error address. An example is shown below. (examine the branch address with the instruction option) $ analyze/system SDA> examine/instruction 8015086B AADRIVER+62B: BLEQ AADRIVER+640 (examine the branch address and 10 bytes following it) SDA> examine/instruction 8015086B;10 AADRIVER+62B: BLEQ AADRIVER+640 AADRIVER+62D: BSBW AADRIVER+69D AADRIVER+630: BLBS R0,AADRIVER+693 AADRIVER+633: CLRL R1 The CLRL R1 instruction was the one I wanted to branch to. The address of it was 10 hex added to 8015086B, or 80150873. SDA> examine/instruction 80150873 AADRIVER+633: CLRL R1 Now I was ready to go back into XDELTA and change the program counter. I started XDELTA again by typing a carriage return at the device using the driver. Once again XDELTA stopped the system. This time I stepped through the code until I reached the branch statement - BEQL 10$. This is where the fun began. I examined the program counter value by typing RF followed by a slash. After the slash, the system displays the value of the program counter. My next step was to change this value to 80150873. The procedure for doing this is to type a space following the current program counter, and then type the new value. The new value is then inserted into the program counter. To clarify this, the terminal output is shown below with comments. CURRENT INSTRUCTION, AND DISPLAYING THE PROGRAM COUNTER FOR THAT INSTRUCTION - VAX-29 PAGESWAPPER - September 1985 - Volume 7 Number 2 "It's in the Microfiche..." 80150863/BEQL 80150880 (current instruction) RF/80150863 (current program counter value) CURRENT INSTRUCTION, AND CHANGING THE PROGRAM COUNTER, AND NEW INSTRUCTION - 80150863/BEQL 80150880 (current instruction) RF/80150863 80150873 (modifying program counter value) S (issuing the step command) 80150875/MOVL 0114(R5),R2 (executing instruction at 80150873 and halting before the execution of the next instruction.) As you can see, I changed the program counter, and then had to issue a step instruction to get the machine executing again. Note, that the instruction pointed to by the program counter, 80150873, CLRL R1, is not printed out on the console device. Instead, after execution of the CLRL R1 command, the instruction following it is printed, in this case the instruction at address 80150875. And thus ended my play time on the VAX. VAX-30 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX System SIG Tape Time Bomb VAX System SIG Tape Time Bomb by Glenn Everhart RCA A&D Eng. MS 206-1 Route 38 Cherry Hill, NJ 08358 The VAX tape is just getting put to bed now, and I expect to send it to Joe Bingham today for addition of a couple directories and for indexing. In going over the tape, I recalled the flap that occurred due to the time bomb that stopped the Spring '84 Reminder from working prior to the arrival of the Fall '84 tape. Well, the Fall '84 version has a timebomb too, set to make it fail starting on August 1, 1985. We should have an official tape out the door by then, but lots of sites won't have it and may call. This is to let you know the new status. I fixed the bomb and have put a patched version from Fall '84 on the tape. It has an expiration date of August 1, 2984, by which time I suspect VAXen will be ancient history. Users can do the patch themselves if they can figure out how to patch REMINDER.EXE off the fall tape. In block 14 of the tape (or thereabouts) about 1/3 of the way down is a string "01-AUG-19854.2" which can be changed to "01-AUG-29844.2" as I did, and the problem of the timebomb goes away. Note that this fix will allow any buried checksums to keep on thinking the bomb is set still. I neither know nor care if there's a checksum; the thing works when modified. Both a patched image and a discussion of what and where the patch is are on the tape for Spring '85. Meanwhile, be ready, and fix your own copies if you use the thing. VAX-31 PAGESWAPPER - September 1985 - Volume 7 Number 2 VMS 4.2 XQP breaks previous privileged code VMS 4.2 XQP breaks previous privileged code by Art McClinton, MITRE Corporation Although the symptoms described in this article are related to the jnet product developed by Joiner Assoc., the problems described will be apparant in any security conscious program developed under pre VMS 4.0 atmosphere. Joiner is delivering a patch that allows their programs to continue running. Users and systems managers will however note that the error messages issued do not immediately point to XQP as the cause of the problems. In an effort to tighten VMS security, the VMS V4.2 extended QIO processor (XQP) enforces the rule that programs must have sufficient privileges to close (as well as open) files. This new feature breaks programs that keep all image privileges turned off except at the instant that they are needed, including jnet V1.2. Though you may not yet be using VMS V4.2, you may have a Near-V4.2 XQP from the Remote Diagnostic Center to fix certain problems in Files-11 disk handling under V4.0 or V4.1. Symptoms included various privilege violation messages when nonprivileged users send VMSmail or files over the RSCS network. The files are created as JANSYS:linkname.RSC, but the linknameDaemon is not awoken and the queue count is not incremented. An Electronic "Campground" For VAX Users Gary Grebus Anyone who has attended a DECUS Symposium knows about a campground: it's place to drop in and talk shop, read notes on the bulletin board, and look for help with problems. Some of the best information is shared in this informal setting. Now imagine a campground that is available not just during a symposium, but 24 hours a day, every day of the year...one that you can visit electronically without leaving your home or office. Such an electronic "campground" is the VAX SIG on CompuServe's Information Service. VAX-32 PAGESWAPPER - September 1985 - Volume 7 Number 2 An Electronic "Campground" For VAX Users CompuServe Information Services is a commercial information "utility". One of the many services offered to their subscribers are SIG's (sometimes called Forums), a method for communication between individuals with similar interests. Stuart Fuller, a DECUS member in the Detroit area, arranged to start a SIG devoted to one of his interests, VAX's. Since 1983, Stu has been the SYSOP or caretaker of this useful information exchange. Currently, over 100 users a day visit the SIG, and the total SIG membership numbers over 1000. The CompuServe VAX SIG offers a number of services. One central feature is the bulletin board. This is an easy-to-use mail system for posting messages on such topics as VMS software, VAX hardware, UNIX on VAX, and VMS Communications. Messages can be posted to the general public or to a specific SIG user. Content ranges from "Does anyone know of a SNOBOL compiler for VMS..." to "We've just found an interesting problem with DMF-32's..." to "Can anyone help me with this problem with terminal QIO's...". The bulletin board is the place to get or give help and to find out what other VAX users are doing with their systems. Another service of the "campground" is the Data Library. This is a collection of files containing public-domain software, articles of interest to VAX users, and information about using the SIG. Files can be "downloaded" to your VAX using various protocols, and you can upload contributions to share with other users. Currently, about 4 megabytes of VAX related files are available online. Other services include real-time online conferences using a facility much like the VMS PHONE utility, and a user list giving names and interests of other SIG users. The VAX SIG is also currently host to DEC Personal Computer activities on CompuServe. A wealth of information on DEC Rainbows and Robins is available. The CompuServe Information Service is accessible by local phone call through TYMNET, TELENET, DATAPAC (in Canada), and CompuServes own network. Usage rates vary based on time of day, baud rate, and the network used. CompuServe subscription "Starter Packs" are sold through most local computer dealers. The CompuServe VAX SIG is accessed through menu page PCS-16. Enter "GO PCS-16" at the menu prompt. Hope to see you online! VAX-33 PAGESWAPPER - September 1985 - Volume 7 Number 2 Building Efficient Images on VAX/VMS Building Efficient Images on VAX/VMS Benn Schreiber, Commercial Languages and Tools DEC, 110 Spit Brook Road (ZKO2-3/K06) Nashua, NH 03062-2698 Program Sections (PSECTs) o Describe a portion of memory by size and contents o Have a user-assigned name and a set of attributes o Typical psects produced by VAX language compilers - Read-only code - Read-only data - Read-write data o Language compilers define contents of psects o In MACRO and BLISS, psect attributes and contents are under programmer control Important PSECT attributes o Relocatable (REL) and Absolute (ABS) - Relocatable psects can be stored in memory. Absolute psects are used for defining global symbols and do not occupy memory. o Concatenated (CON) and Overlaid (OVR) - In an overlaid psect, the psect is the size of the largest contribution, and the contribution for each module starts at the same virtual address. In a concatenated psect, the size of the psect is the sum of all the contributions to it. o Writeable (WRT) and Non-writeable (NOWRT) - Writeable program sections can be modified by your program. An access violation will occur if your program tries to VAX-34 PAGESWAPPER - September 1985 - Volume 7 Number 2 Building Efficient Images on VAX/VMS modify a NOWRT psect. o Executable (EXE) and Non-executable (NOEXE) - Has no effect on whether section contains executable code. Only used for creating image sections. There is no hardware support for execute-only. o Local (LCL) and GLOBAL (GBL) scope - Controls linker search extent. The search for global psects encompasses all clusters, while the search for local psects is limited to the current cluster. o Vector (VEC) and Non-vector (NOVEC) - Most psects are NOVEC, with the exception of message sections and protected code. o Attributes considered when creating a shareable image - Shareable (SHR) and Non-shareable (NOSHR) - Determines whether psect is shared among more than one process. - Position independent (PIC) and Non-position independent (NOPIC) - Specifies whether psect executes correctly regardless of placement in memory. Setting NOPIC does not affect the 'position-independence' of the resulting image. o In a shareable image, psects that have GBL, OVR, and SHR attributes are like FORTRAN COMMON. o Psects with "similar" attributes are collected together into image sections. Image Sections o Image sections are a collection of psects with similar attributes. o After it has read all input (object and shareable image) files, the linker finds psects with "similar" attributes and gathers them into image sections (alphabetically within each image section). VAX-35 PAGESWAPPER - September 1985 - Volume 7 Number 2 Building Efficient Images on VAX/VMS o PSECT Attributes considered - For executable images: WRT/NOWRT, EXE/NOEXE, VEC/NOVEC (8 different combinations of psect attributes) - For shareable images: WRT/NOWRT, EXE/NOEXE, VEC/NOVEC, SHR/NOSHR, and PIC/NOPIC (32 different combinations of psect attributes) o The order of psect attribute selection is fixed in the linker. This can be used to control the ordering of code and/or data within your image. Attribute order listed on page LINK-75 of the Linker Reference Manual. Clusters o A cluster is a concept used by the linker (and only the linker) - Accumulate image sections - Each shareable image input is a separate cluster o Clusters are made up of a group of image sections, which are in turn made up of a collection of similar psects. o You control placement of object modules in the image by use of the CLUSTER option. o You control placement of psects in the image by use of the COLLECT option. Copy-on-Reference (CRF) pages o With respect to an image file, CRF pages are those that will be process-private pages. VAX-36 PAGESWAPPER - September 1985 - Volume 7 Number 2 Building Efficient Images on VAX/VMS o Initialized, per-process data section. o Occupy space in the image file. Demand-zero pages o Uninitialized (default to all 0), per-process data section. o Occupy no space in the image file, created at runtime by VMS memory management services. Transfer Vectors o Use transfer vectors to ensure upward compatibility in your shareable image. o Ensure transfer vector is at the very front of your shareable image. - Use the CLUSTER link option and specify the transfer vector as the first cluster. $ LINK MYIMAGE, SYS$INPUT/OPTION CLUSTER=TRANSFER_VECTOR,,,OBJ:TRANSFER_VECTOR CLUSTER=THE_REST,,,OBJ:MYLIB/LIBRARY... - Very careful placement via psect attributes and psect name - make the attributes NOWRT, NOEXE, SHR, NOPIC, NOVEC and use a name that collates before any of your other psects ($$$TRANSFER for instance). $ LINK MYIMAGE, SYS$INPUT/OPTION PSECT=$$$TRANSFER,NOWRT,NOEXE,SHR,NOPIC,NOVEC OBJ:MYLIB/LIBRARY/INCLUDE=TRANSFER_VECTOR VAX-37 PAGESWAPPER - September 1985 - Volume 7 Number 2 Building Efficient Images on VAX/VMS Linker GSMATCH option o Use the GSMATCH option to control when images linked against your shareable image (consumers) need to relink. o Typically, you only change the minor ident of the GSMATCH when you change the image. This prevents images linked against the new version from accidentally running with the old version. o If you make incompatible changes (order of elements in the transfer vector, for instance), then you must change the GSMATCH major ident to force all consumers to relink. Shareable images o A collection of routines that are known to be debugged and working. o Greatly reduces link time as compared to linking against object libraries. o Improves memory sharing. o Reduces software maintenance costs/headaches. "Did you relink your image to pick up the new version of the FROTZ routine?" Shareable image libraries o A name space translator. The linker looks in a shareable image library for a global symbol. If it finds the symbol, it determines which module (and hence the shareable image) contains the symbol. VAX-38 PAGESWAPPER - September 1985 - Volume 7 Number 2 Building Efficient Images on VAX/VMS o The modules in a shareable image library contain no code. o SYS$LIBRARY:IMAGELIB.OLB is a shareable image library. Image File Fixup Section o The linker uses the image file fixup section to guide the image activator in resolving references to shareable images. o Two types of image fixups done - Code references are fixed by directing the image activator to modify a longword in the fixup section itself. All code references to a particular global name reference the same location in the fixup section. - Data references (MACRO .ADDRESS) are EACH fixed up by the image activator. The fixup section contains a list of locations within the image that need to be modified. SECTIONS CONTAINING .ADDRESS DATA ARE NOT SHAREABLE. Hints for high performance images o Order and group modules according to usage. In a phase-oriented image, such as a compiler, group the modules for the different phases together. This can be done by specifying the object module load order, or with the linker CLUSTER option. o Reduce number of image sections by combining 'similar' psects where possible. In MACRO, don't randomly use psect attributes, this can generate extra unnecessary image sections. VAX-39 PAGESWAPPER - September 1985 - Volume 7 Number 2 Building Efficient Images on VAX/VMS o To maximize demand-zero pages and minimize CRF pages, group all initialized data together, and all unitialized data together. This avoids the checkerboard (DZRO, CRF, DZRO, CRF) image that can result. o Avoid using .ADDRESS data (not possible with some language compilers). In languages where you have control, use self-relative offsets in tables rather than .ADDRESS data. o Use the VAX Performance and Coverage Analyzer (PCA) to help you characterize your program's performance. o Trade off disk space (image size) vs. activation time (number of image sections) by use of the ISD_MAX and DZRO_MIN options. - ISD_MAX controls the maximum number of image sections in the image (default is approximately 96). Increasing this value may decrease image size by allowing the linker to generate more demand zero sections, but may increase the total number of image sections. - DZRO_MIN controls the minimum size of a demand zero section (default is 5 pages). Decreasing this number may increase the number of demand zero sections, but be careful of the DZRO/CRF/DZRO/CRF checkerboard. VAX-40 PAGESWAPPER - September 1985 - Volume 7 Number 2 Global Section Problems Global Section Problems Pageswapper Editor's Note The only guess I can make is that this originated with Don Golden. At any rate, he is the one who sent it to me (along with articles by others) with no indication of the author. Dear Larry, I feel that these two problems (currently, unsolved) warrant a letter to the editor of the Pageswapper. I don't have solutions, yet, but think other users might appreciate knowing about these pitfalls. Our software product transfers large, and I do mean LARGE, data buffers between VAXen by using DECnet non-transparent task to task communications. It may or may not matter that the VAXen are tied together via an Ethernet link. The basic transfer algorithm is really quite simple. When the process responsible for the DECnet interface in one machine perceives the need to transfer data to the other machine, it first sends an interrupt message with some information about the message to be transferred. Included in this information packet is the desired byte count. This interrupt message is sent using a QIO (no wait). The same process then issues a QIO to write the actual message to the channel. If the message is greater than 65K, multiple QIO's are issued. The process at the receiving end wakes up when the interrupt message arrives. {The plot thickens (:>) }. What we want to do is this. The receiving process knows the size of the message being sent along with some other application dependent characteristics, for example, the name of the real destination process. It can use this information to create and map a global section. It then hangs a read or (or a series of reads) to match the write done on the other end on the channel. If this were to work, it could tell the process on the same node about the global section and then consider its work would be done. Not so fast, champ! This doesn't work. When the byte count approaches 4000 or so, this mechanism starts failing. Let me describe the failure syndrome. The QIOs on the sending system complete without apparent error. The QIO for the receipt of the message completes with a successful system service status. Its IOSB indicates an access violation, but shows the full byte count as having been transferred! VAX-41 PAGESWAPPER - September 1985 - Volume 7 Number 2 Global Section Problems Closer investigation of the receive buffer indicates that fewer bytes than the full byte count actually arrived in the buffer. Even more interesting is that the actual number of bytes transferred is a strange number. It is a multiple of the DECnet buffer size less 15. That is, with a DECnet buffer size of 1024, the actual number of bytes transferred is a multiple of 1009. With a DECnet buffer size of 576, the number of bytes arriving in the receive buffer is a multiple of 561. We did a bunch of looking at our create and map global section code, assuming we had mapped it incorrectly and had thereby caused the access violation. We couldn't see anything wrong. Still, we had to make a test. These applications programs are written in that wonderful systems implementation { (:>) }language, PASCAL. Replacing the create and map section code with some PASCAL NEW commands, we could receive into a different type of buffer. Eureka!!! It works!!! Up to 65K bytes, our test programs do not fail, we did not worry about going beyond 65K since if you can do 65K a bunch of times one way you can do it another, right? WRONG!!! When we modified our production programs to do NEWs instead of create and map section, everything was OK for buffers up to 65535 bytes. However, when our transfer request caused us to stack two reads and the second was more than 3 or 4 thousand, we got the same error syndrome on the second read as into the global section. This was a real stumper. While it would be fun to bang through fiche and figure this one out, we have a production system to ship and we needed to find a work around to the work around. By reading a series of smaller chunks, namely 49152 byte chunks, the work around began to play. You'll note that 49152 is roughly 16K plus 32K so it has all sorts of nice boundary conditions. This was all reported to DEC in an SPR which has not yet been answered. This is the most strange behavior out of DEC, since usually they are really helpful in at least giving back a status on problems like this. The Global Section Problem Our software product has a suite of programs which create and map page file sections. These are sections which use the page file as their backing store and are just great for temporary storage and interprocess communications. We use a directory and naming convention that allows us to generate unique names, and then to find the names later. When we complete the use of a section and delete it we return the name to the directory structure. The directory module puts the name back on the top of a linked list, where it can be used again. VAX-42 PAGESWAPPER - September 1985 - Volume 7 Number 2 Global Section Problems This particular suite of programs tend to activate one another in the following way. Process A activates process B, gets rid of its sections, and hibernates. Process B starts up gets some sections and does its thing. Reasonably often process B gets the name that process A discarded. Looking in the global section list, there will be a section mapped to B and one of the same name in the delete pending list. If this goes on long enough, the delete pending list gets really long and the number of global sections reaches the sysgen limit. When this happens, our software product shuts down. This is not a satisfactory situation. The problem is, the global sections marked delete pending seem never to get really deleted. We asked DEC about this and they really couldn't or didn't give us an answer. By returning used names to the end of our directory structure list and pulling new name off the top of the list, the entire problem vanished. It appears that there was a problem in the global section name space, once the name got reused, the section marked delete pending could not be disposed of. VAX-43 PAGESWAPPER - September 1985 - Volume 7 Number 2 *** VOTE *** VOTE *** VOTE *** VOTE *** VOTE *** VOTE *** System Improvement Request Ballot FALL 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. Don't complain about the directions VMS takes unless you help provde the direction! 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. For your convenience, the ballot items have been grouped by area of interest. New for this ballot is a section of items proposing improvements for the SIR process itself. Please give us your input on how this process can be improved. 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 NOVEMBER 4 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 Fall 1985 DECUS Symposium in Anaheim, and will be published in the Pageswapper. Instructions You have a total of 100 points to allocate among the SIR's on the ballot (excluding the section on the SIR process itself). 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, you may not assign more than 10 points to any one SIR. To allocate points to a SIR simply record the number of the SIR VAX-44 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot 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. VMS Internals SIR: F85-1 Abstract: Provide a means to keep control of a drive obtained via assisted MOUNT. Description: Operator-assisted MOUNT provides a way to have a volume mounted on an arbitrary drive. However, there is no way to avoid relinquishing control of the drive when it must be dismounted, for example to re-INITIALIZE the volume. Without this control, it is possible that the volume could be switched and the INITIALIZE or re-MOUNT be done on the wrong volume. ALLOCATE is only effective if done before the MOUNT, which is impossible when the drive assignment is done by MOUNT. SIR: F85-2 Abstract: Implement a quota to limit the RATE of buffered I/O's. Description: The VMS documentation suggests how to deal with excessive terminal I/O and suggests redesigning the user programs. For the usual case where this is not practical, a quota should be available to restrict the maximum rate at which a process could generate buffered I/O's. Alterately, it should be possible to prevent VMS from boosting the priority of a process performing buffered I/O at a rate above some system-wide threshold. Currently, a process doing excessive buffered I/O degrades the whole system and is rewarded by receiving a priority boost. Reducing the BIOLM quota does not solve the problem, since the priority boost insures troublesome process receives prompt service. Putting an upper limit on the buffered I/O rate per process would preserve the system's responsiveness at the cost of degrading the response time of the offending process. VAX-45 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-3 Abstract: Provide facility for parsing a privilege string. Description: VMS should provide a common facility (as both an RTL routine and a DCL lexical function) which can convert between the textual representation of a VMS privilege list and the corresponding bit mask. This would make it easy to reliably handle privilege specifications in applications and would ease tracking future enhancements in VMS. SIR: F85-4 Abstract: Provide more detailed CPU usage information in MONITOR. Description: The MONITOR displays which show CPU usage should optionally provide much more detailed information about where the CPU is being used. For example, it should be possible to break down the kernel mode display of MONITOR MODES by its major components (QIO, file system, paging, etc). MONITOR PROCESS/TOP_CPU should be able to break down process CPU usage by access mode. Such additional detail is frequently needed to identify the actual performance problem from among several similar possibilities. SIR: F85-5 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 cluster-visible devices. User functions should include the ability to specify 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 VAX-46 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot 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. SIR: F85-6 Abstract: Provide support for running multiple versions of a layered product. Description: In a production environment, it is almost always an unacceptable practice to blindly replace the existing version of a layered product with a new version. Some sort of local testing or quality assurance is usually required. However, the current VMS product installation procedures do not support such an installation. Installing a "test" version of a product is a tedious and error-prone task. The VMS layered product installation should support multiple versions of a product on the same system, and should provide an easy way to switch between versions of the product. Note this may require switching a variety of images, shareable libraries, help libraries, DCL tables, etc. In the case where the product manipulates a global database (such as the Common Data Dictionary), the installation procedures should provide for the creation of a test version of the database. SIR: F85-7 Abstract: Provide for user-supplied filters between the terminal driver and applications. VAX-47 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot Description: VMS should provide a facility to allow user-supplied, non-privileged programs to act as filters between the user's terminal and any application. These filters, traps, or translators could provide "one-keystroke" access to a variety of useful functions, similar to the "pop-up" utilities available on various personal computers. At minimum, such a filter might allow access to the SPAWN and ATTACH facilities of DCL. Or, it might provide access to a "notepad" file, or perform keystroke mapping for a non-standard keyboard layout. In any case, this facility would act without disturbing the previously running program. SIR: F85-8 Abstract: Provide a SYSGEN DISCONNECT command Description: When configuring devices with the SYSGEN 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 controller switch settings. This capability need not be applicable to all drivers or devices. It is not necessary that devices supported by a port/class driver be disconnectable. The idle device test used by SYSGEN RELOAD (even if not highly reliable) could still be employed with no more risk than is currently present. At a minimum, it should be possible to change the CSR and vector for a device even if the device cannot be completely DISCONNECT'ed. This request is a repeat of an item which has previously made the top 10 SIR list. SIR: F85-9 Abstract: Propagate the file ERASE attribute to new versions. Description: VMS Version 4 has generally added the convention of propagating file protection attributes from previous versions of a file. Since the ERASE attribute has similar security implications, it should be propagated in the same manner. SIR: F85-10 Abstract: Allow an image to be installed with a priority and UIC. VAX-48 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot Description: The ability to provide a base priority increment or decrement while running a specific image would be a great help in a heavily loaded interactive system. For example, the EDT editor might be installed with higher priority to help its responsiveness, while a CPU-intensive compiler might be forced to execute at a lower priority. The ability to run with a UIC other than the owner's is a great help in cases where mailbox communication is necessary. The VMS INSTALL utility should allow both of these conditions to be specified, in the same manner as enhanced privileges. SIR: F85-11 Abstract: Provide a means to perform an in-place compression of a disk. Description: One of the trade-offs associated with the Files-11 disk structure is that, with time, the disk space becomes fragmented into many small extents. This causes increased inefficiencies in disk I/O, since files are less likely to be contiguously allocated and since more overhead is required to keep track of the file extents. The solution to this problem has always required that a disk be dumped to tape (or disk) and reloaded to compress the files into contiguous allocation. However, with the advent of larger, non-removable disks, the time required to perform such a compression has become extremely large. While this may be a very difficult problem, it would be extremely beneficial to have a way to perform such a compression without the need to completely dump and reload the disk or disk volume set. Even if a complete solution cannot be achieved, a partial implementation could be useful. Any procedure which could produce a useful amount of compression in less time than required for a dump/reload would be a great benefit. SIR: F85-12 Abstract: Expand use of page files for swapping. Description: In the absence of a swap file, the swapper will swap to the primary page file. The swapper should be able to use any available page file when there is no swap file. It also should be able to use more than one page file for swapping when multiple page files are available. A large cluster of machines with lots of memory and a common system disk cause too high an I/O load on the common disk. This request would provide additional flexibility in spreading the paging and swapping load to other disks. VAX-49 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-13 Abstract: Add simplified insert and extract routines to callable Librarian. Description: It is suggested that 8 additional entry points be added to the callable Librarian to assist in the insertion/extraction of data from libraries through programs written in high level languages. These entry points would be of the form LBR$INSERT_xxx and LBR$EXTRACT_xxx where xxx is a valid library type (MLB, OLB, TLB, HLB). The routines would have three parameters: the library index (as used by the other Librarian routines), the name of the module to insert/extract, and a filespec where the extracted module would be written to or the inserted module read from. SIR: F85-14 Abstract: Alter the mechanism which delivers priority boosts. Description: The VMS scheduler gives priority boosts in response to various system events, including terminal I/O completion. Often the process has to wait a long time at base priority before the scheduler sees it and actually implements the new priority by requeueing it in the higher priority queue. It is suggested that the code which does the priority boost also should requeue the process into the higher priority queue. This suggestion is aimed at improving response for highly interactive tasks like editors. SIR: F85-15 Abstract: TCP/IP support is needed under VMS. Description: A large number of workstations, "intelligent" test instruments, and process control systems are currently available which use the UNIX operating system. These UNIX based systems very often support the TCP/IP network protocol. There is frequently a need to connect such devices to a VAX running VMS. VMS should support TCP/IP with file transfer capability to allow for such communications. SIR: F85-16 Abstract: Add FILE_ID item to $GETQUI. VAX-50 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot Description: The $GETQUI service should have an item which returns the File Identification for the file in a job. This information is necessary to access a file which is not entered in a directory, such as a file produced through a spooled device. SIR: F85-17 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 includes 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 problems 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: F85-18 Abstract: Develop class-based scheduling facilities for VMS. Description: Under VMS, a long, compute-bound batch job can prevent a lower prioirty 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 processor (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 need not be dedicated to single applications. This will VAX-51 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot not be feasible unless resources can be partitioned in a definable and reproducible fashion. SIR: F85-19 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 applicaitons. 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). DCL and Utilities SIR: F85-20 Abstract: Add a keyword search capability to HELP. Description: It would be useful to have a feature in the HELP utility which would accept a keyword and display a screen showing the keyword's occurrences in context. Thus specifying something like: $ HELP/KEYWORD="/date" would return information showing where HELP has entries containing the keyword "/date". The context should include the hierarchical list of topics needed to locate the reference. Frequently you may know the keywords related to a topic, but not the exact path needed to locate the information. This facility might be generally useful apart from HELP as an enhancement to the SEARCH utility. It could allow searching of text and macro libraries with a display of the context as well as the module name. SIR: F85-21 VAX-52 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot Abstract: Add /NOIMAGE debugging option for DCL command procedures Description: Development and debugging of complex command procedures would be simplified in many cases if a facility similar to the RSX /NOMCR switch were available. The desired functionality would be to avoid activating images such as COPY and DELETE, etc. This would eliminate check-out tests that had undesirable side effects like deleting files based on an improperly constructed symbol substitution. The primary purpose would be for syntax checking of DCL, it would be the user's responsibility to elimiate all non-DCL entries read in by user images. Some control over which images would not be activated on a session-by- session basis would be desirable. SIR: F85-22 Abstract: Allow command procs to be invoked from a library. Description: DCL should support (on a process-by-process basis) a default text library to search for command procedures to be executed. This could reduce run time by minimizing directory searches and file opens. If the requested command proc were not found in the library the current default directory would be searched as is currently done. This facility would not apply to an @filespec that contained any node or directory specification. Some ability to turn this facility on and off as well as redefine the library would be needed. SIR: F85-23 Abstract: Provide an optimizer for DCL. Description: By applying existing compiler optimization techniques it should be possible to create a utility that converts an existing command proc into an optimized form. It would not be necessary to try to preserve the proper location and context of documentary comments. As much as possible the original symbol names should be preserved. SIR: F85-24 Abstract: Add automatic closing capability for command procs. Description: When a command proc is aborted via or or any other abnormal event, some facility should be provided to automatically close all files opened. This would elimiate frustration over accidentally restarting the command proc with the old files. Note for compatibility with existing command procs that rely on the current behavior this would need to be implemented in a VAX-53 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot user-controllable fashion. It would be desirable if this behavior could be specified as either: a default for all command procs executed, applies only to this command proc execution or applies only to specified files in this command proc execution. SIR: F85-25 Abstract: Provide enhanced capability. Description: In order to facility debugging of systems that utilize subprocesses it would be desirable to have a mode of behavior for or some other control sequence to perform the equivalent of a for all process and subprocesses descended from the main process. This would enable the user to ascertain if the subprocesses are working or have become hung up by monitoring the information provided. SIR: F85-26 Abstract: Provide a "catch symbol" for the DCL interpreter. Description: If a catch symbol facility were provided in VMS DCL that would be invoked when DCL failed to understand a command, it would be relatively easty to "catch" and parse in complex fashions "other" commands. These "other" commands would not need to follow DCL SYNTAX or be parsed by DCL but would be parsed by a user-supplied image. It would also be desirable if the user parsing image were redefinable by some method. SIR: F85-27 Abstract: Enhanced DELETE command behavior. Description: It would be desirable to provide some method that would allow the DELETE command to detect humanely the omission of the required ";" and behave as if ";*/confirm" had been typed. This behavior would then parallel the behavior of the RSX DELETE command. SIR: F85-28 Abstract: Modified behavior of the PURGE command. Description: A user can purge all files in a directory by giving a PURGE command with no filespec. However a PURGE command with a filename only results in an error. By changing this behavior to treat PURGE with a filename as a PURGE filename.* and purge all file types for the given filename, behavior would be consistent. VAX-54 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-29 Abstract: Improve the behavior of the /CONFIRM qualifier. Description: Currently, all commands that accept the /CONFIRM command expect a positive response of "Y" to cause the aciton to be taken, with the default behavior being "N". It would be desirable to have a user-controlled method of altering this so that the default behavior would be the requested action and thus a declination response of "N" would be necessary in order to skip performance of the requested action. SIR: F85-30 Abstract: Modify the treatment of SET VERIFY and SET NOVERIFY by DCL. Description: It would be desirable if DCL would automatically preserve the verify state that was in effect at each level of command proc nesting. This would eliminate annoying changes of verification state caused by the interruption or termination of a subordinate command proc. That is, propagate the VERIFY status downward through nested command procs but NEVER upwards. This would also eliminate the need for users constantly to add DCL commands to their command procs to maintain the VERIFY status of their caller and restore it on exit. SIR: F85-31 Abstract: Provide SET PROTECTION support for logical name tables. Description: Now that logical name tables have been made protectable objects and given protection masks, it is necessary that one be able to manipulate and examine these protections. This applies to all logical name tables: SYSTEM, USER, GROUP, JOB, etc. SIR: F85-32 Abstract: Restore the size of the LIB$GET_FOREIGN buffer. Description: Currently DCL restricts the total size of the command string passed by a foreign command to 255 characters. This restriction of 255 did not apply in VMS 3.6 (some large one probably did) and the new limit of 255 is now causing working programs to break. This problem is particularly aggravated by the longer filenames and resultang filespecs supported by VMS 4.0. VAX-55 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-33 Abstract: Add a utility for setting certain file attributes. Description: Certain file attributes describe only the interpretation of the data, not its actual structure. A utility should be available which can change such attributes to alter the interpretation of the data. The most common such change is to switch a file (perhaps obtained from a foreign tape) between FORTRAN and Carriage-Return carriage control. Another example is to switch a file among the various forms of STREAM record formats. Such a utility would eliminate the need to CONVERT large files or do QIO-level programming to accomplish this type of change. SIR: F85-34 Abstract: Add a match limit to the SEARCH utility. Description: Currently, SEARCH scans the entire file for EVERY occurrence of the specified search string. It would be useful to be able to limit the number of occurrences which are searched for. This would be hlepful when searching a large number of files and the existence of one (or some fixed number) of occurrences of a stirng is sufficient to identify the file. $ SEARCH/LIMIT=1 *.FOR "FROBOZ" would identify all FORTRAN programs containg the string FROBOZ. Once the limit of successful matches is reached SEARCH would close the file and proceed to the next one. SIR: F85-35 Abstract: Enhance DIFFERENCE utility to recognize comment delimiters for C. Description: When invoked with the /COMMENT_DELIMITER switch, the DIFFERENCE utilty, by default, recognizes comment delimiters for many of the popular programming languages (MACRO, BLISS, FORTRAN) based on DEC-defined file types. This should be extended to recognize "C" programs and the standard /* */ pairs. SIR: F85-36 Abstract: Enhance the MAIL utility to track delivery of messages. Description: When using MAIL it should be possible to request complete tracking of message delivery. This would make it possible for the sender to obtain a list of who had read a message, on a by-message or by-user basis. For messages sent across DECnet, it is NOT acceptable to lose the record VAX-56 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot of delivery if the originating node is unavailable at the time that the message is read. SIR: F85-37 Abstract: MAIL should be able to send mail to all usernames. Description: MAIL should have an option which allows a suitably privileged user to send a message to all known usernames. This would provide a convenient method of delivering site information, notices, etc. in a form familiar to the recipient. To allow finer control, the MAIL SEND command should also have an /EXCLUDE qualifier which allows a user or group of users to be excluded from the mass delivery. The /EXCLUDE list would presumably be smaller and more manageable than the list of all known usernames. SIR: F85-38 Abstract: Provide a callable interface to the MAIL facility. Description: Many applications require automatic delivery of status messages or notifications to one or more users, something which can be very effectively done via MAIL. However, implementing such a service via exit commands or DECL subprocess spawns is cumbersome and error-prone. It would be very useful to have a MAIL facility that is callable by a user program directly. Separate entry points for each function or a facility to accept a properly formatted text string or file would be acceptable. This facility could also be used to build a gateway between mail systems in a multivendor installation. SIR: F85-39 Abstract: Provide a /NOADVANCE option on the DCL WRITE command. Description: DCL should have a mechanism which allows a string to be written to SYS$OUTPUT, without positioning to the next line. This facility would be useful when exact positioning control is required, for example when generating output onto a pre-printed hardcopy form. SIR: F85-40 Abstract: SET TERMINAL/INQUIRE should be able to determine the mode of a VT200 series terminal without changing that mode. Description: With VMS V4.1, a VT220 terminal set in VT100 mode is automatically changed to VT220 mode by the command SET TERMINAL/INQUIRE. This is contrary to the previous treatment of VT52 mode on VT100 terminals and is in general a disservice. Although there may be cases where changing VAX-57 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot the mode is desired, there are plenty of cases where only inquiry is needed; for instance where a distinction needs to be made between video and hardcopy terminals, without disturbing a user's choice of terminal mode. Perhaps an optional qualifier would be in order. SIR: F85-41 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. System Management SIR: F85-42 Abstract: Enhance the network support in BACKUP. Description: BACKUP should have enhanced networking capabilities: 1. It should generate a remote backup object to handle magtape and file selection remotely from remote tapes or save-sets. 2. Standalone BACKUP should have rudimentary DECnet capability. VAX-58 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot 3. Standalone BACKUP should be down-line loadable over Ethernet. BACKUP is extremely useful, but it lacks certain important networking capabilities. The ability for BACKUP to invoke a remote network object version of itself would have 2 useful results: the remote object could mount and handle the magnetic tape (with increased reliability due to BACKUP's superior tape handling), and it could do file selection from remote save-sets which would greatly decrease network traffic. (At present, the whole save-set must be processed by FAL and the files locally selected by BACKUP). Some rudimentary DECnet support in Standalone BACKUP is a big piece missing from the MicroVAX support. Anyone who has loaded 31 floppies will agree. (We won't all be ordering TK50's). Having BACKUP down-line loadable over Ethernet would be the ideal in support for remote systems. SIR: F85-43 Abstract: Summary ACCOUNTING report should list actual times of first and last entries. Description: When generating summary reports with the ACCOUNTING utility the input file often does not cover the entire period specified. There is no way of knowing from the summary report if this is the case. The ACCOUNTING utility should extract the first and last dates represented in the data and include that in the summary report. SIR: F85-44 Abstract: Add volume initialization parameters to Standalone BACKUP. Description: The Standalone BACKUP utility should allow the user to initialize an output volume with explicitly specified parameters. This is particularly important for single-disk systems, where it is otherwise impossible to change volume parameters such as cluster factor. SIR: F85-45 Abstract: Provide facilities for estimating and monitoring time required for a BACKUP. Description: BACKUP utility should optionally be able to estimate the time and number of tapes required for a BACKUP operation. This would allow operators to budget their time and tape volumes. BACKUP should also include the currently active file spec VAX-59 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot as part of its message requesting a new tape volume. This would allow the operator to monitor the progress of the backup and would allow selection of tape volumes of the appropriate size. SIR: F85-46 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: F85-47 Abstract: Improve STANDALONE BACKUP's handling of write-protected disks. Description: To avoid accidents with STANDALONE BACKUP, it is desirable to write-protect the disk being backed up. This is unworkable if the backup date is to be recorded following the operation. BACKUP should re-check the write-ability of the disk when it begins the recording pass, and possibly ask for operator intervention to make the disk write-able. SIR: F85-48 Abstract: Provide a "manual recover" mode for BACKUP Description: While BACKUP has generally excellent error recovery capabilities, there ar occasionally times when some part of the tape information cannot be read. For example, a damaged label might prevent a saveset from being usable, or a damaged file name might prevent the data from being reloaded. For such cases, BACKUP should have an interactive "recovery" mode in which the user could be prompted to supply values for missing information. Obviously, such a facility would make it impossible to guarantee the integrity of the data restored. It would be the user's responsibility to review and assess the validity of the data. However, often recovering imcomplete data may be better than not recovering any at all. VAX-60 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-49 Abstract: Provide a 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. SIR: F85-50 Abstract: Add /INTERACTIVE and /IMAGE qualifiers to SHOW SYSTEM and MONITOR PROCESS. Description: When examining the processes on the system, it is sometimes only the interactive processes which are of interest. SHOW SYSTEM should have an /INTERACTIVE qualifier similar to its /BATCH qualifier. This is particularly important on systems which have a large number of detached or batch processes which clutter the display. The same feature should also be available in MONITOR/PROCESS. Both utilities should also have the ability to display the currently executing image for all processes. This is particularly important in MONITOR when it is essential to know what image a troublesome process is running. SIR: F85-51 Abstract: Support SYS$WELCOME in group logical name tables. Description: It is frequently necessary to tailor the appearance of a VAX for different user groups (e.g., in-house users, research sponsors, application users, etc.). To aid in such tailoring it should be possible to define SYS$WELCOME in the group logical name tables (instead of just in the system table). A requirement for EXEC mode logical names would provide additional control over use of this feature. SIR: F85-52 Abstract: Provide more flexibility in the SHUTDOWN procedure. Description: The current facility for site modifications to the SHUTDOWN procedure (SYSHUTDWN.COM) is not sufficiently flexible. It would be useful to have an additional site exit available at the time the SHUTDOWN is initally invoked, which could be minutes or hours before the actual shutdown occurs. Such an exit would allow all shutdown related questions to be asked and answered at the same VAX-61 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot time. It would also allow "idle-down" processing (i.e., stop accepting new work) to be started, before a final cutoff in SYSHUTDWN. SIR: F85-53 Abstract: Provide support for "restricted" DCL environments Description: It should be possible to create an environment similar to a captive command procedure by reducing the facilities accessible from DCL. This would be much more convenient than custom building a new command interpreter (the captive procedure) for each application. The current SET COMMAND utility provides the base of this capability. Additional support is required to insure that only the images specified in the DCL tables could be executed, and that tables could not be modified by the captive user. Even if this facility were somewhat complex to use, it would probably be easier than insuring each custom written captive procedure is secure and effective. SIR: F85-54 Abstract: "Unbundle" the functions of the CAPTIVE login flag Description: The login flag CAPTIVE is currently the only way to enforce the execution of the command file specified in the /LGICMD field. Unfortunately, CAPTIVE also disables the use of the login /DISK qualifier and implies the flag DEFCLI. This is not necessary when the /LGICMD field contains a full file spec for the procedure. Control of the /DISK qualifier and of the /LGICMD should be available as separate flags. SIR: F85-55 Abstract: Enhance the SHOW command in AUTHORIZE Description: Very often a need arises to check all of the users in the UAF for one particular AUTHORIZE parameter, such as who has what privileges, or how many people have an increased WSEXTENT. It would be very handy to be able to enter "SHOW/WSEXTENT [*,*] rather than having to write a program to do this or go through a full record for hundreds or thousands of usernames. This could be extended also with the ability to specify a range for the parameter within which to choose records. Another handy item would be to extend the wildcard specifiers for UICs to alow the use of "%" signs. This way an entire range of UIC's can be scanned or listed without VAX-62 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot having to include the entire file or enter the command repeatedly. SIR: F85-56 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 tracing malicious users. Commercial SIR: F85-57 Abstract: Provide for dependency networks of print and batch jobs. Description: Large production shops often have the need to specify the interdependencies between the running of related jobs. For example, job A should run after job B and job C have run; Jobs D and E should be printed after job F has finished, etc. The SYNCHRONIZE command provides a limited form of this capability. It is desireable to have a simple mechanism to specify larger networks of dependencies for both print and batch. SIR: F85-58 Abstract: Enhance handling of TAB characters in SORT Description: With the present SORT software, it is very difficult to sort input files which contain the horizontal TAB character. Such a file usually is produced by entering data from a terminal. It is very difficult to determine the sort key position. This is because the records are displayed (via TYPE for example) with TABs expanded while SORT treats the TAB as a single character. If "spacing" in the file is created with a combination of TABs and blanks, it is even more difficult to properly sort the file. The SORT facility should have an option to expand TAB characters to blanks prior to isolation of the SORT keys. VAX-63 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-59 Abstract: Support Asynch printers thorugh a terminal server. Description: A large source of terminal I/Os on many systems is the use of asynchronous terminal printers (LA50s, LA120s, etc.). It would be desirable to offload some of this I/O overhead by connecting these printers to an Ethernet terminal server. The use of a terminal server also privides additional flexibility and redundancy. The DEC terminal servers should be enhanced to fully support such printers. Since these devices might be remotely located and may not have keyboards, it must be possible to configure "dedicated" connections for these devices in the server. Since VMS print queues must be defined for these devices, they must appear tto the VAX with fixed, known device names. SIR: F85-60 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 allowed to change the labeling on the tape without special privilege. The BACKUP utility must also conform to such labeling 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 than tan unlabeled tape which happens to be on a drive be automatically assigned. VAX-64 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-61 Abstract: Support RMS segmented keys of different types Description: RMS should allow segmented keys where the segments are of different types. For example, it might be desirable to have one segment be a string and another an integer. This would be particularly useful since the VAX convention for storing the bytes of an integer does not support sorting an integer as if it were a string. SIR: F85-62 Abstract: Add support for descending keys in RMS indexed files Description: It should be possible to access RMS files using both ascending and descending keys. There are many query applications where such facility provides the most natural solution. Languages and Tools SIR: F85-63 Abstract: VMS data structure definitions and entry point definitions should be provided for ALL DEC languages to the fullest extent that they can be used by that language. Description: When using high-level languages, it is extremely inefficient for each user to code and maintain the definitions of VMS data structures and entry points (RTL and system services). Some languages currently lack even the system service and STARLET data structures. Most languages lack the VMSRTL and LIB definitions. In the case of Pascal, the STARLET data structure definitions provided are not strongly typed to the degree which would be expected by someone who has chosen that language to take advantage of its strong typing. While the "escape hatches" to avoid strong typing may be an appropriate option to give users, they should not be used by DEC as a cheap way out of properly defining the entry points and data structures for ALL languages. SIR: F85-64 VAX-65 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot Abstract: Provide a /D_LINES (debug lines) compile-time switch on the VAX-11 C compiler Description: VAX-11 C should provide an external mechanism to conditionally compile code intended for use while debugging C programs like the /D_LINES switch implemented in VAX-11 FORTRAN. SIR: F85-65 Abstract: The DEBUGGER should permit MACRO language syntax when debugging high-level-language source code. Description: There are occasions when it is necessary to examine data structures, such as stacks and argument lists. This cannot usually be done from the high-level-language syntax, so it becomes necessary to perform a "SET LANGUAGE MACRO" command. Later, it may be necessary to revert to the original high-level-language syntax. It is awkward to have to "toggle" between MACRO language syntax and a high-level-language syntax while using the debugger. When parsing a debugger command, it would be convenient if the debugger could first apply the high-level-language syntax rules. If the command could not be properly parsed, then the debugger would revert to the MACRO syntax. IR: F85-66 Abstract: All DEC supplied editors for VMS should follow a common protocol for protecting against simultaneous edits to the same file. Description: While source code control software is normally used to synchronize source code changes, there are situations where it is not appropriate (e.g. changing the system startup command procedure). All DEC supplied editors for VMS should use a consistent mechanism to insure that two processes cannot be simultaneously editing the same file. In addition, this mechanism must allow other readers to access the file. Under VMS V4.1, EDT and TECO both handle this differently, so as not to be interlocked against each other. TECO, additionally does not allow for readers to get the old version of the file by default. Perhaps one implementation mechanism would be to have writers of a replacement version lock the PREVIOUS version for write (allowing other readers). A prime criterion for evaluating this scheme would be to ensure that DCL can execute a command procedure which is open for write. VAX-66 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-67 Abstract: Enhance the pattern matching capabilities of the EDT search command to include column bounds and "negative" searches. Description: EDT would be more useful if it allowed more elaborate specifications of the pattern to be searched for. It should be possible to restrict the column positions to be searched. For example: FIND "ABC"/POS=1:15 would search for the first occurrence of the string "ABC" located in columns 1 through 15. It would also be helpful to have a "negative" search specification. For example: FIND -"Mr."/POS=1 would find the next line which did NOT begin with the string "Mr.". SIR: F85-68 Abstract: The select region in EDT should remain active after the region is written to a file, so that further operations can be performed on it. Description: In EDT a range of code can be selected in KEYPAD mode, and this range can be written to a file. This action causes the code to be de-selected, and no further operations can be performed unless the range is selected again. There needs to be an option which controls whether a selected region is de-selected after an operation is performed on it. SIR: F85-69 Abstract: EDT should leave an extra space at the end of each line when word-wrapping is performed. Description: It would be useful if there was an option that would cause EDT to leave a space at the end of each line when performing word-wrapping. This action would greatly simplify the transfer of text files by DECdx to DECmates. Currently, when DEXdx inserts a soft return, the last word on one line will be concatenated with the first word on the following line, after DECmate re-wraps the text. The current work-around is to manually insert end-of-line blanks. SIR: F85-70 Abstract: Provide unnumbered FORMAT statements to improve the readability and appearance of FORTRAN code. VAX-67 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot Description: Many FORTRAN FORMAT statements are used just once, and placing the FORMAT statements immediately after the I/O statements makes it easier to follow the code. When these FORMAT statements are in an indented section of code, the statement numbers destroy the appearance. Eliminating unnecessary statement numbers also makes it easier to locate statement numbers which are targets of branches. SIR: F85-71 Abstract: Provide a method to improve the readability of RUNOFF input files. Description: It is difficult to keep track of elements in nested lists, when the list depth exceeds two. If indentation were permitted on lines that contained list directives, readability could be greatly improved. Security SIR: F85-72 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 the 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 VAX-68 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot 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: F85-73 Abstract: Implement government standard security classifications for files (i.e., unclassified, confidential, secret, and top secret) 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 classifed 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, itt should retain its classification. A utility should be provided to allow a person with a (SECURITY) privilege to change the classification of a file. SIR: F85-74 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 trustworth. 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: F85-75 Abstract: Better node authentication should be provided by DECnet-VAX. VAX-69 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot 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. Improvements to the SIR Process The purpose of this section is to obtain your input on how the SIR process can be improved. The following include a number of suggestions which have been received at past DECUS symposia. Please let us know how you feel on each of these items. To simplify the tally, use the following scale to describe your preference: -10 Strongly agree + 5 Somewhat agree 0 Neutral or no opinion - 5 Somewhat disagree -10 Strongly disagree Enter your response on the specially numbered lines on the ballot. This section will be summarized separately from the rest of the ballot. SIR: F85-100 Abstract: The SIR ballot is important enough to be conducted by a separate mailing. Description: The SIR ballot has traditionally been conducted through the Pageswapper. The primary advantage of this mechanism has been the low cost. However, since the advent of paid newsletter subscriptions, not all SIG members receive the Pageswapper. If a wider distribution of the ballot is really important, the SIG could pay to conduct one or both ballots by directly mailing to the SIG membership. This would, however, reduce the funds available for projects in other areas. VAX-70 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot SIR: F85-101 Abstract: The process of filling out an SIR ballot should be simplified. Description: It has been suggested that people are discouraged from participating in the SIR ballot because of the time it takes to do the voting. The voting scheme used on the SIR ballot has traditionally involved dividing 100 points among the available SIRs, with a 10 vote per SIR limit. An alternative format might list all of the SIRs and ask for a 1 to 5 rating for each SIR. The goal of the original scheme was to force voters to strongly distinguish between the most important SIRs and those of only moderate interest. The alternative format might encourage people to mark "5" for every SIR, rather than carefully considering each one. SIR: F85-102 Abstract: The quality of the SIR items should be improved. Description: One possible reason that people don't participate in the SIR ballot is that they don't find anything worth voting on. This may be due to lack of interesting SIRs, or it may be due to unclear or poorly worded ballot items. The ballot is currently reviewed by the VAX SIG working groups to generate clear, comprehensive, technically correct items. Emphasis could be placed on improving this review process. SIR: F85-103 Abstract: Some form of electronic voting on SIRs should be available. Description: With electronic mail becoming increasingly familiar to many people, some form of electronic voting might become feasible as an adjunct to the paper ballot. The large size of the ballot text (and the time required to analyze it) might discourage online reading of the entire ballot. However, some mechanism of electronic vote collection is more feasible, and could be investigated, if there is sufficient interest. SIR: F85-104 Abstract: Some percentage of the SIRs not making top 10 should be automatically included on the next ballot. VAX-71 PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Ballot Description: The typical SIR ballot contains 50 to 75 items, of which DEC responds to the top ten. Most good ideas tend to be submitted repeatedly if they fail to make the cutoff. To help insure that good ideas are not lost, the second 10 or 15 items could automatically be added to the next ballot. A possible objection to this policy is that, over the course of a year, action by DEC or users might alter the importance or direction of a previously submitted SIR. SIR: F85-105 Abstract: The SIR process should try to encourage the inclusion of hardware improvements. Description: While the SIR ballot has always been open to all VAX issues (software, hardware, service, etc.) almost all SIRs received pertain to software. An effort could be made to encourage the inclusion of hardware items on the ballot. It may be that hardware requests would not show strong popularity on the ballot. The various groups within the VAX community might not share common hardware interests to the same degree as software interests. Traditionally, it has been harder to get hardware issues addressed by Digital. The SIR ballot might lend extra credibility to such efforts. SIR: F85-106 Abstract: The SIR process should narrow its scope to concentrate on issues which ONLY Digital can resolve. Description: It has been suggested that too many ballot items are "wasted" on requests which can be resolved by user written programs. These tend to obscure requests which can only be solved by DEC (changes to the operating system or major features). However, some users do not have the resources to develop their own solutions and cannot depend on unsupported "public domain" software for critical applications. SIR: F85-107 Abstract: Several SIR's requesting small enhancements to a particular program should be combined on the ballot. Description: Very often a number of SIR's are received requesting very minor additions to a particular program (e.g. BACKUP). When they are combined together, there is more chance for that combined ballot item to make top ten status. This does make it impossible to oppose one particular change out of a group of desired ones. VAX-72 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX System SIG Committee List VAX System SIG Committee List As of July 18, 1985 Osman K. Ahmad - TOPS-VAX Association of American Railroads Technical Center, Research and Test Department 3140 South Federal Street Chicago, IL 60616 Joe Angelico - System Management US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA. 70130 June Baker - Planning Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660 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 Tom Danforth - Handout Editor Woods Hole Oceanographic Institute Woods Hole, MA 02543 Doug Dickey - Data Management SIG Interface CTEC, Inc. 6862 Elm Street McLean, VA 22101 VAX-73 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX System SIG Committee List 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 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 Gary Grebus - System Improvement Request Battelle Columbis Labs Room 11-6011 505 King Avenue Columbus, OH 43201-2693 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 J C C Post Office Box 381 Granville, OH 43023 614-587-0157 VAX-74 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX System SIG Committee List Ken Johnson - VAXcluster Working Group Chair Meridian Technology Corporation Post Office Box 2006 St. Louis, MO 63011 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 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-2693 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 VAX-75 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX System SIG Committee List Douglas J. Wilson - Office Automation MIT Joint Computer Facility Room 5-137, 22 Massachusetts Avenue Cambridge, MA 02139 VAX-76 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. indent (5) blanks before (1) test page (2) INPUT/OUTPUT 433 Caption: Hewlett-Packard 7550A Plotter -- Reply to I/O # 371 Message: We use the following for PLOT QUEUE definitions for hp 7585: $ SET TERM TTA1:/DEVICE_TYPE=UNKNOWN/SPEED=9600/PERM/NOWRAP/- NOECHO/NOFORM/HARDCOPY/NOBROADCAST/WIDTH=511 ! Plotter TDV $ SET DEV/SPOOLED TTA1: $! $! INIT/START QUEUES $ DEFINE/FORM/WIDTH=511 PLOTTER 1 $ INIT/QUEUE/START/TERM/- DEFAULT=(NOFLAG,NOBURST,NOFEED,NOTRAILER)/- SEPARATE=(NOBURST,NOFLAG,NOTRAILER,NORESET)/- FORM=PLOTTER/SCHED=NOSIZE TTA1: $ INIT/QUE/START/GENERIC=55A1: HP7585 We then send HP-GL-Plotfiles with record length 511 to the device by $ PRINT/QUE=HP7585/FORM=PLOTTER/NOHEAD file-spec Under VMS 4.1, DEF/FORM/WIDTH is necessary instead of SET TERM/WIDTH under VMS 3.7. Contact: Bernd Grothkopp Robert Bosch GmbH/ZWI Postfach 50 D 7000 Stuttgart 1 West Germany Telephone 0711-8116538 Date: July 3, 1985 VAX-77 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT 434 Caption: Disable/Enable CTRL/Y in FORTRAN code -- Reply to I/O # 409 Message: Use the run-time library routines: LIB$DISABLE_CTRL (Volume 5B page RTL-79) LIB$ENABLE_CTRL (Volume 5B page RTL-90) These routines are available under VMS version 3 and 4. Contact: Glenn Zorn Bunker Ramo 95 Merritt Boulevard Trumbull, CT 06611 Telephone (203) 386-2098 Date: May 23, 1985 INPUT/OUTPUT 435 Caption: Disable CTRL/Y -- Reply to I/O # 409 Message: Refer to the Run-Time Library Routines (LIB$ENABLE_CTRL) and (LIB$DISABLE_CTRL). If you disable control Y in a program, you need to enable it within the program after you are done. If you don't, CTRL/Y will be disabled for the process completely until you enable it or logof. Refer to V4.0 documentation. It gives a better explanation than V3.n documentation. Contact: Patrick J. Holmay Academic Computer Services Science Hall, Room 018 St. John's University Collegeville, MN 56321 Telephone (612) 363-2706 Date: May 29, 1985 VAX-78 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT 436 Caption: Disable CTRL/Y -- Reply to I/O # 409 Message: One way to disable control/Y in a FORTRAN program is to use the system service LIB$M_CLI_CTRLY, as in the following example: external lib$m_cli_ctrly mask=%loc(lib$M_cli_ctrly) status=lib$disable_ctrl(mask,oldmask) !(disables control Y) c c ******************************************* c Body of program where control Y is disabled c ******************************************* c status=lib$enable_ctrl(mask,oldmask) !(enables control Y) end Contact: Christopher M. Gordon Hughes Research Labs RL86 3011 Malibu Canyon Road Malibu, CA 90265 Date: May 30, 1985 INPUT/OUTPUT 437 Caption: How to Disable CTRL/Y -- Reply to I/O # 409 Message: The Run-Time Library allows enabling or disabling CTRL-Y from any high level language. In FORTRAN: IOSTAT = LIB$DISABLE_CTRL('02000000'X) or IOSTAT = LIB$ENABLE_CTRL('02000000'X) Contact: Ron Williams Southwest Research Institute Div15 6220 Culebra Road San Antonio, TX 78285 Telephone (512) 684-5111 ext 3490 Date: Jun 4, 1985 VAX-79 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT 438 Caption: VAX to Prime/Prime to VAX file transfer Message: We are looking for a fast (>= 9600 baud), easy to use, file transfer program between VMS and Primos, possibly using X.25 interface. Other than KERMIT and BLAST, which use asynchronous transmission, is anything available? Contact: Jack Patteeuw Ford Motor Company Diversified Products Technical Center - C309 17000 Rotunda Drive Dearborn, MI 48121 Telephone (313) 323-8643 Date: May 31, 1985 INPUT/OUTPUT 439 Caption: Ditto Foreign Tape Copy Message: Can anyone suggest a method for doing a bit-wise copy of a tape with protection for bad spots on the target tape? This comes up in a requirement for making copies of IBM, UNIVAC, PRIME and DEC20 tapes on a VAX. IBM has a DITTO program but we couldn't use that to copy VAX BACKUP tapes (tested prior to /INTERCHANGE mode) and there may be similar problems going the other way. Contact: Edward E. L. Mitchell Mitchell and Gauthier Associates 290 Baker Avenue Concord, MA 01742 Telephone (617) 369-5115 Date: May 30, 1985 VAX-80 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT 440 Caption: VAX to LSI via DAV11 Message: I would like to talk to anyone using a DAV11 to comunicate between a VAX and an LSI (PDP11/03). I am interested in sharing information about drivers, diagnostics, etc. Contact: Pete Ruch SPACECMD/INDPI Cheyenne Mountain Complex, CO 80914-5601 Telephone (303) 473-4010 x3529 Date: June 24, 1985 INPUT/OUTPUT 441 Caption: Backup to tape via DECnet -- Reply to I/O # 418 Message: Sourcenode command : $ BACKUP XYZ TAPENODE::"0=NETTAPE"/SAVE/BLOC=4096 nettape.com (use proxy access): $ ALLO MTA0: $ MOUNT MTA0: LABEL /BLOC=4096 $ CONVERT SYS$NET:/FDL=NETIN MTA0:SRCDAT.BCK/FDL=MTA0OUT netin.fdl: ORG=SEQ; CAR-CON=NONE; FORMAT=VARIABLE; SIZE=4096 netout.fdl: ORG=SEQ; CAR-CON=NONE; FORMAT=FIXED; SIZE=4096 Contact: Allen P. Rueter 510 South Kingshighway Boulevard Bx8131 Department of Radiology Washington University St. Louis, MO 63110 Telephone (314) 362-7133 Date: May 28, 1985 VAX-81 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT 442 Caption: VMS <--> RSX DECnet Message: We have a MicroVAX I, with a DHV11 running MicroVMS 4.0 and end-node DECnet. We are trying to communicate, using asynchronous DECnet, to a PDP-11/23+ with a DLV11E, running RSX-11M Version 4.1. We are able to get each end to work in loop-back, but can not get the two systems to talk to each other. If we connect each system to Ethernet, they will communicate. Although DEC claims (in the VMS software product description) that this is not supported, has anyone been successful in getting VMS and RSX to communicate asynchronously? Contact: James R. Bennett Manager of Engineering Services Genigraphics Corporation Post Office Box 591 Liverpool, NY 13088 Telephone (315) 451-6600 ext. 226 Pageswapper Editor's Response I believe I recall people at the Spring US Symposium in New Orleans saying that there had been a protocol implementation error in the VMS async DECnet which has since been corrected to allow the two systems to communicate. INPUT/OUTPUT 443 Caption: SUPREM Semiconductor Processing Simulator Message: I need to run SUPREM II or SUPREM III on our 11/750 under VMS. SUPREM is a program which originated at Stanford University and which simulates the processing involved in semiconductor manufacture. Please contact me if you have this program running under VMS or if you know of anyone who has it. Contact: Bill Jones Datalinear Corporation 11211 Prosperity Farms Road Palm Beach Gardens, FL 33410 Telephone (305) 694-0050 VAX-82 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT Date: May 30, 1985 INPUT/OUTPUT 444 Caption: Exquota from Print Symbionts driving Versatec Message: Versatec device drivers check process quotas by calling EXE$BUFFRQUOTA after tab expansion. Tab expansion causes increase in record size making buffer larger than the SYSGEN parameter MAXBUF. To fix: change driver to call EXE$BUFQUOPRC which bypasses comparison with IOC$GW_MAXBUF. Contact: Tom Moog Building 203 Argonne National Lab 9700 South Cass Avenue Argonne, IL 60439 Telephone (312) 972-3073 Date: June 6, 1985 INPUT/OUTPUT 445 Caption: Disable CTRL/Y -- Reply to I/O # 409 Message: This is something I use a lot when I have to write code which requires the process be installed with privileges not given to normal users, however, it has to be used by them. It is described in detail in the Run-Time Library Manual. include '($libclidef)' !+ ! Disable control Y recognition !- istatus=lib$disable__ctrl(lib$m__cli__ctrly) if(.not. istatus) call lib$stop(%val(istatus)) !+ ! Enable control Y recognition !- istat=lib$enable__ctrl(lib$m__cli__ctrly) if(.not. istat) call lib$stop(%val(istatus)) VAX-83 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT Contact: T.W. Heim Jr. (Tom) Simpact Associates, Incorporated 5520 Ruffin Road San Diego, CA 92123-1390 Date: June 6, 1985 INPUT/OUTPUT 446 Caption: Operator Interface Program -- Reply to I/O # 410 Message: The company I used to work for sells a product they developed called SADI which sounds like the menu interface you described. SADI is an inexpensive, easy-to-use menu system which transfer control to and from a spawned subprocess. Contact: Mark Crego c/o ManTech Services Corporation 2320 Mill Road Alexandria, VA 22314 Contact: Herbert J. Matthews IV E.R.C. 5686 Medallion Court Alexandria, VA 22303 Telephone (703) 663-2177 Date: June 6, 1985 INPUT/OUTPUT 447 Caption: Disable CTRL/Y -- Reply to I/O # 409 Message: The disabling and enabling of CTRL/Y can be accomplished from a Fortran program by calling the run-time library procedures LIB$ENABLE_CTRL and LIB$DISABLE_CTRL. Check the RTL manual for the usage. Instead of disabling CTRL/y, you might want to detect it, trap it, set a flag, and handle it in your program with a normal exit. Read about out-of-band AST's under QIO (IO$_SETMODE!IO$M_OUTBAND) in the system services manual. Contact: Herbert J.Matthews IV E.R.C. 5686 Medallion Court Alexandria, VA 22303 Telephone (703) 663-2177 VAX-84 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT Date: June 6, 1985 INPUT/OUTPUT 448 Caption: Return Receipt in VAXmail Message: I am interested in a VMS program that will provide a return receipt for VAXmail under Version 4.1. Contact: Charles Sheets Walter Reed Army Instutute of Research 6825 16th Street, North West Building 83, Division of Biometrics Washington, DC 20307-5100 Telephone (202) 576-3146 Date: June 18, 1985 INPUT/OUTPUT 449 Caption: Seeking information on dual 780 on one SBI using MS780 memory Message: I have a vague memory of reading in the Pageswapper about a user who put two 780 CPU's together on one backplane thus making it a 782 without the multiport memory. We have a 782 with MA780 multiport memory but would like to expand beyond its capacity. Using MS780 memory seems to be the only option. None of my back issues seem to contain this article. Has anyone actually made this conversion? Contact: David Ruhoff Digital Productions 3416 South LaCienega Boulevard Los Angeles, CA 90016 Telephone (213) 938-1111 Date: June 23, 1985 Pageswapper Editor's Response The Pageswapper article was "LUG Meeting Reports" (essentially a paraphrase from a LUG newsletter) in Volume 6 Number 1 (July 1984) referring to work done with VMS. Those who did that work referred to an article in the preprint volume of the 9th Annual Symposium on Computer Architecture regarding a prior effort VAX-85 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT of the same nature under Unix. INPUT/OUTPUT 450 Caption: P and WHAT for VMS 4.x Message: I'm still on version 3.7 of VMS on a VAX 11/750. I will be moving to version 4.x soon, and I will be losing two valuable but unsupported tools - P and WHAT. P is, as explained in the notes I have, "... a program for looking at other jobs, somewhat similar to 'J' of 'K' on the pdp-10." The sources are P.MAR, DPY.MAR, DPYDEF.MAR, P.COM, the system symbol table, and P.HLP. I could modify it if I were a guru, but... Does anyone have a version of P that runs on v4.x? For WHAT, I have no notes or source. It comes up showing a dynamic display of the processes. You can SHOW MAIL, SHOW MUTEXES, ADD columns to various displays, etc. This is a big help to watch messages going from process to process, identify MWAIT problems, etc. Same question, does anybody know someone who has this goodie? Contact: Frank W. Croft Post Office Box 2042 Wilmington, NC 28403 Date: June 26, 1985 INPUT/OUTPUT 451 Caption: SNOBOL for VMS Message: Does anyone have or knoww of a native mode SNOBOL interpreter and/or compiler for VMS? Contact: Clyde T. Poole University of New Orleans Computer Research Center New Orleans, LA 70148 Telephone (504) 286-6760 Date: June 26, 1985 VAX-86 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT 452 Caption: VAX Pascal Pretty Printer -- Reply to I/O # 409 Message: We have a so-called Pascal Formatter which indents the lines in dependance of the Pascal keywords, translation fo the key words to upper/lower case. It is simple to use. The documentation is in the German language. Contact: Rudolf, Reusch AEG Hafenstr D 2000 Wedel West Germany Telephone 04103/200-565 Date: July 4, 1985 INPUT/OUTPUT 453 Caption: Reading IBM 3470 exchange Floppies -- Reply to I/O # 379 Message: We have a program for reading IBM Exchange Format Floppies (8 inch single density, 128 bytes per sector) which runs under VMS (MCR). The software and source are: FLXIBM ERIK A. Rosdol District Software Support AUEA/VIENNA Project VMB 707013 Contact: Alfonso Garcia Cores System Manager Banco Pastor Paseo de Recoletos, 19 28004 - Madrid Spain Telephone 1-4335800 exte. 264 Date: July 8, 1985 VAX-87 PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT INPUT/OUTPUT 454 Caption: Disable CTRL/Y -- Reply to I/O # 409 Message: Fortran Routines are provided to disable and enable CTRL/Y or C: SUBROUTINE DISABLE J=0 ! INTEGER*4 J=JIBSET(J,25) ! SETBIT 25 II=LIB$DISABLE_CTRL(%REF(J),) RETURN END call DISABLE to disable CTRL/Y SUBROUTINE ENABLE J=0 J=JIBSET(J,25) ! SETBIT 25 II=LIB$ENABLE_CTRL(%REF(J),) RETURN END call ENABLE to enable CTRL/Y Contact: Paul Paskaran Planning and Transsportation Department Westminster City Council Victoria Street London SW1 UK Telephone 01-798-2626 Date: July 8, 1985 INPUT/OUTPUT 455 Caption: Looking for Route Accounting Package Message: We are in need of a route accounting package for laundries. This is to run under VMS on an 11/750. Contact: Jim Hatlelid Midco Data System, Incorporated Box 5009 Minot, ND 58702 Telephone (701) 857-1155 Date: July 15, 1985 VAX-88 PAGESWAPPER - September 1985 - Volume 7 Number 2 Steering Committee Nominations Steering Committee Nominations It's that time again! Every two years the VAX SIG elects seven (7) people to be the steering committee. These seven people have the primary responsibility for the operations of the SIG. Prior to each Fall DECUS Symposium the steering committee meets to elect its chair and to make job assignments. A few additional non-voting members may be added to this core group in order to fill major areas. Currently the major areas are: chair, vice-chair, secretary, symposia (2 positions), volunteeers, publisher, newsletter editor, special projects, SIRs, local user groups, library, tape copy, and working group coordination. Who can be nominated? Any US Chapter DECUS member of the VAX SIG who has five DECUS members sign a nomination form. What are the time commitments? The time commitment varies during the year and with the job(s) to be done. A rough average is 2-10 hours per week. This includes weekly (minimum) electronic communications with other DECUS leaders via DECUS's DCS system , and attending each symposia including the extra 1-2 leadership days. The steering committee conducts one or two "woods meetings" per year -- these planning meetings are usually 2 1/2 days each. There may be other out-of-town meetings depending on your responsibilities. And finally, there is the actual work to be done! DECUS will pay for non-symposia travel and expenses incurred. What are the benefits? This level of involvement in DECUS does require a substantial commitment from you and support from your employer is really important. What you and your employer get in return is a closer working relationship with DEC, especially in product development. Your contacts within the VAX community are also a big benefit. And DECUS provides on-the-job training in areas such as management, public speaking, group dynamics, politics, and organization. What is the schedule? The nomination forms are due to the DECUS office no later than 15 September. And yes, you may nominate yourself! You just need a total of five supporting signatures of DECUS members. The nominee's resume is also due into the office at the same time. The balloting will be done in late September-early October and the results announced at Fall DECUS. PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX SIG Steering Committee Nomination Form VAX SIG Steering Committee Nomination Form (please print or type all except signature) Nominee name _______________________________________________ address _______________________________________________ ________________________________________________ ________________________________________________ phone ___________________ DECUS # ___________________ The following five DECUS members sponsor the above nomination: Name DECUS# date signature 1. 2. 3. 4. 5. Please return form by 15 September 1985 to: DECUS VAX SIG Nominations 249 Northboro Road Marlboro, MA 01752 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX SIG Steering Committee Nomination Form Tear out to submit a nomination DECUS VAX SIG Nominations 249 Northboro Road Marlboro, MA 01752 PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX Systems SIG Fall 1985 SIR Ballot VAX Systems SIG Fall 1985 SIR Ballot Questionnaire DECUS membership number __________________ (six digits) 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 ____ Data Acquisition/Control____ CAD/CAM ____ Service Bureau ____ Hardware Development ____ Scientific/Engineering ____ Office Automation ____ Telecommunications _____ Other ____________________________ Our principal programming language is _________________________ PAGESWAPPER - September 1985 - Volume 7 Number 2 VAX Systems SIG Fall 1985 SIR Ballot VAX SYSTEMS SIG FALL 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 NOVEMBER 4 TO BE ASSURED OF COUNTING. SIR Number: Points: SIR Related Questions ___________ ________ F85-100 ____________ ___________ ________ ___________ ________ F85-101 ____________ ___________ ________ ___________ ________ F85-102 ____________ ___________ ________ ___________ ________ F85-103 ____________ ___________ ________ ___________ ________ F85-104 ____________ ___________ ________ ___________ ________ F85-105 ____________ ___________ ________ ___________ ________ F85-106 ____________ ___________ ________ ___________ ________ F85-107 ____________ ___________ ________ ___________ ________ ___________ ________ ___________ ________ ___________ ________ ___________ ________ ___________ ________ ___________ ________ ___________ ________ ___________ ________ Mail to: Mr. Gary Grebus Battelle Columbus Laboratories Room 11-6011 505 King Avenue Columbus, Ohio 43201 PAGESWAPPER - September 1985 - Volume 7 Number 2 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: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA PAGESWAPPER - September 1985 - Volume 7 Number 2 INPUT/OUTPUT Submission Form Tear out to submit an I/O item Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA PAGESWAPPER - September 1985 - Volume 7 Number 2 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - September 1985 - Volume 7 Number 2 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-2693 USA