PAGESWAPPER Larger VAX Processors by Larry Kilgallen, Pageswapper Editor The official word on larger VAX processors at the Saint Louis Symposium came not at the VAX Sessions at all, but at the Large System opening session. A slew of DEC officials, including three vice presidents, were present to tell 10/20 users that DEC has abandoned further work on Jupiter, the project to build a faster 36 bit machine. In this context, with 10/20 users expressing anguish over the lack of a larger 36 bit machine in their future, DEC officials spoke of the work which still continues and is planned for the future on larger VAX processors. "We've got several projects in place right now" said Sam Fuller, Manager of Research, "to develop a 32 bit machine that has on the order of twice the performance of the 2060 that you're using today." "Our new high-end multi-MIPS VAX product is proceeding extremely well," was the characterization from Vice President of Corporate Operations Win Hindle. He went on to say "It has been turned on and is running in DEBUG mode today." Looking further into the future, Sam Fuller said "DEC's committed to coming up with a machine that will have a price below a 2060, yet will have the power beyond a Cray-1 in the 1991-1992 time frame." 1 PAGESWAPPER - June 1983 - Volume 4 Number 8 O Your Last Pageswapper Unless, of course, you have sent in your money for the new DECUS subscription service. For those who do not have one, a subscription form is attached at the back of this issue. 2 PAGESWAPPER - June 1983 - Volume 4 Number 8 In this issue... In this issue... Larger VAX Processors . . . . . . . . . . . . . . . 1 Your Last Pageswapper . . . . . . . . . . . . . . . 2 In this issue... . . . . . . . . . . . . . . . . . . 3 Editor's Workfile . . . . . . . . . . . . . . . . . 3 "Pass the Paper" at the BAYVAX LUG . . . . . . . . . 6 Leadership Continuity in the Boston VAX LUG . . . . 7 New Mexico VAX LUG . . . . . . . . . . . . . . . . . 8 West Michigan LUG . . . . . . . . . . . . . . . . . 8 VMS Mail Re-direction, Expansion or Aliasing . . . . 9 Speling Cheker Works Gud . . . . . . . . . . . . . 10 The Role of the Computer Operator in the VAX Shop 11 VMS Application Downward Compatibility . . . . . . 13 VMB -- Beware of Field Servants Bearing Gifts . . 14 Using the VMS TKB for RSX-11M Software Development 14 Philosophy of Editing . . . . . . . . . . . . . . 16 ACP Failure Problem with spooled terminals. . . . 17 Commercialism . . . . . . . . . . . . . . . . . . 18 VAX SYSTEM SIG CAMPGROUND for Las Vegas . . . . . 18 Symposium Thanks . . . . . . . . . . . . . . . . . 19 Comments on the Symposium Novice Sessions . . . . 19 Spring 1983 SIR Response from DEC . . . . . . . . 21 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . 29 INPUT/OUTPUT Submission Form . . . . . . . . . . . 37 System Improvement Request Submission Form . . . . 39 DECUS US Chapter Subscription Service Form . . . . 41 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 Preference is given to material submitted as machine-readable Runoff source or text. 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 3 PAGESWAPPER - June 1983 - Volume 4 Number 8 Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter, MRO2-1/C11 Attention: Publications Department One Iron Way Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. Editor's Workfile by Larry Kilgallen, Pageswapper Editor Starting next month the Pageswapper will include a section entitled "The DBMS Monitor" devoted to issues concerning DBMS-32. That section has been edited by Julie Llewellyn and published by Ed McCabe up until now as a private newsletter of the DBMS-32/CDD Product Group of the Data Management SIG. For the near-term, Ed and Julie will continue the separate mailing as well as submitting the material to the Pageswapper, and after several months have elapsed will decide whether to drop one or the other distribution mechanism. As of a report that newsletter editors received at the Saint Louis Symposium, the Pageswapper has received 1166 subscriptions under the new subscription plan. That is only about 10% of the number on the mailing list under the previous system. In my own conversations at Saint Louis I found instances of all three obvious possible reasons: o "Phantom" readers In some cases 10 copies were going to a single department where 2 would do. Having established a market economy, these things should be sorted out. o Feel it isn't worth the money That's a fair decision, and we should not be devoting resources, whether from a subscription fee or from general DECUS funds, to sending a newsletter to someone who does not feel it is worth those funds. 4 PAGESWAPPER - June 1983 - Volume 4 Number 8 Editor's Workfile o Haven't gotten around to it yet Well, if that is your situation, this is the last reminder you will get. In my opinion (although not necessarily in the opinion of every member of the VAX Systems SIG leadership), the subscription service seems to be doing its job -- weeding out those who are not really interested in reading the Pageswapper. Whatever the case, we will continue to do our best to bring you timely information each month, and hopefully that will include a drastic shortening of the turn-around time between when the Pageswapper is submitted to the DECUS office and when it reaches your mailbox. At the Saint Louis Symposium the VMS Development Group helped us get an account called PAGESWAPPER on the demonstration machines so that members could use MAIL to transmit newsletter submissions throughout the week. (The VMS Product Management Group then helped us get the results back after the Ethernet Department started unwiring early). The results are spread throughout this Pageswapper and are the reason symposium material is contained in this issue. Our regular symposium review issue will be in July, for those who have decided to subscribe. In response to one of my many submission pleas at the symposium, one member said the notice of coming topics had not been sufficiently prominent. The notice below should correct that. Larry Kilgallen, Pageswapper Editor ************************************************************ ************************************************************ ************************************************************ **** **** **** Topic for August **** **** **** **** Source Control/Revision Control/etc. **** **** **** ************************************************************ ************************************************************ ************************************************************ 5 PAGESWAPPER - June 1983 - Volume 4 Number 8 "Pass the Paper" at the BAYVAX LUG "Pass the Paper" at the BAYVAX LUG by Dave Johnson, BAYVAX Chmn Lockheed Research Laboratory, M/S 5233/255 3251 Hanover Street Palo Alto, CA 94304 Two features which are part of every BAYVAX meeting are the "Open Forum" and "Pass-the-Paper". The Open Forum is just what it sound like; a lively interchange of problems, questions, ideas and whatever seems appropriate. It is open-ended, but normally lasts 60-90 minutes. Some members, for whatever reason, are reluctant to assert themselves in the Forum (our meeting attendance runs between 100 and 150); hence "Pass-the-Paper". At the beginning of the meeting, clip-boards begin to wend their way through the auditorium, forming a written Open Forum. There is no particular structure, except that each entry must be accompanied by a name and telephone number. Members are encouraged to ask question, make comments on others' questions, or anything else that seems appropriate. The entries (with obscenities excised) are printed in the following VOX VAX, our newsletter. May of the questions are answered by the time it gets into print most of the others get phone calls. "Pass-the-Paper" was intended to serve the timid; in practice, it has turned out to be more than that. We try to capture the Open Forum questions and answers for publication, but note-taking being what it is, not everything makes it. The clip-boards, however, can be edited as time permits, and everything gets into print. 6 PAGESWAPPER - June 1983 - Volume 4 Number 8 Leadership Continuity in the Boston VAX LUG Leadership Continuity in the Boston VAX LUG by Wendy Koenig, former LUG Chair The Greater Boston VAX LUG was started 4 years ago, at MIT. It was an offshoot of the MIT PDP-11 LUG. At the time, most of the VAX'es in the area were at MIT (excluding DIGITAL itself, of course!). Since then, the group has expanded to encompass many of the companies, universities and hospitals in the Boston area. The LUG meets monthly and combines an informal interaction among users with a scheduled speaker at all meetings. This article will discuss the role of the chairperson in running the LUG and a method we use to continue the existence of the group as people shift in and out of the Boston VAX community. The LUG was founded by Art Hermes of MIT, who basically ran the LUG by himself, with assistance from other people. Vicki Woolf, also of MIT, was the first assistant chairperson. When Vicki left the Boston area, I was asked to become the assistant chairperson. Very soon afterwards, Art also left the area, and suddenly, I found myself running the LUG. The chairperson has sole responsibility for running the LUG. After a few months, I realized there was a real need to develop a continuity in the leadership, as well as expanding the number of people involved in running the LUG. The LUG had grown tremendously in size during that time. In order to provide speakers for our monthly meetings, it is necessary to have a streamlined leadership which can act quickly and efficiently. Often, there isn't a lot of time to arrange the next meeting. On occasion, I had a speaker cancel out the day before, and managed to find a replacement on less than a day's notice. The LUG chairperson has to be willing and able to make most decisions singlehandly. On the other hand, we have attempted to divide much of the workload among various members of the LUG - for example, the mailing list, SIG tape distribution, monthly newletter and question referals. The chairperson is ultimately responsible for all of these things, but the workload is spread out among other people, for whom the LUG is very thankful. Two years ago, we instituted a revolving plan for the position of chairperson. Every year the LUG elects a new assistant chairperson. This assistant serves a one-year term as assistant. One year later, the chairperson is "retired", the assistant becomes chairperson, and a new assistant is elected (volunteered is much closer to the reality of this situation!). So far, this method has been very effective for several reasons - 1) it is much easier to get someone to volunteer to be an assistant (this has been the case in almost all of the leadership), 2) it gives the assistant a full year to ease into a position of complete responsibilty, 3) it brings new blood and ideas into the leadership on a regular basis while maintaining a 7 PAGESWAPPER - June 1983 - Volume 4 Number 8 Leadership Continuity in the Boston VAX LUG continuity at the same time, and 4) it provides a responsible backup for the chairperson, in case anything happens to the chairperson. So far, we have had 2 complete transitions of leadership, and they have been very smooth. As the year winds down, the assistant takes on more and more responsibility and finally assumes all of the responsibility for the group. New Mexico VAX LUG New Mexico LUGs will be having a regional meeting in late September. I'll check on the date and send the Pageswapper more information. We don't have a regularly scheduled meeting time; but meet every 4 to 8 weeks. Contact the LUG chair for more information. New New Mexico VAX LUG Chairman: Capt Patrick R. Werner AFWL/ARLB Kirtland AFB, NM 87117 (505) 844-4691 West Michigan LUG The West Michigan Local Users Group of DECUS invites all non-members in the area to join the LUG. For more information contact: WMLUG c/o G. Thomas PO Box 354 Byron Center, MI 49315 Serving the Greater Grand Rapids and Kalamazoo areas. 8 PAGESWAPPER - June 1983 - Volume 4 Number 8 VMS Mail Re-direction, Expansion or Aliasing VMS Mail Re-direction, Expansion or Aliasing by Tom Keck, Texas Instruments P. O. Box 226015 M/S 238 Dallas, TX 75265 When the same users have accounts on multiple network nodes, a common problem is time-important mail being sent to them on infrequently used nodes. this problem can be solved with low system resource overhead by using the fact that VMS mail does logical name translation of the TO: field entries. A file like the one below can contain the logical name assignments necessary to automatically re-route mail to a user's "home base" node where he or she logs in most frequently. The sender may override the automatic routing established there and force delivery to a specific node by prefixing the username field with an underscore. This method can also be used to set up aliases or pseudonyms for mail or to redirect mail to someone else during a period of extended user absence such as vacation or illness. Or it can be used to automatically cause a copy of mail sent to a single username to be sent to additional users. If only incoming network mail need be re-routed, these logical names can just be assigned at system startup on a group basis for the default network account group ([20,20] on our systems). This avoids any logical name clutter or overhead for any normal processes. The same file can also be used in any of three ways to re-route mail sent with a local destination (ie, no node name or number prefix). The logical names could be defined on a system wide basis at startup, or on a process basis at user login, or a new pseudo mail command equal to $mai*L == "@MList:MailRoute.com MAIL_WITH_ROUTING" could be define at login and user mode logical names that just exist for the mail image duration will be created when the mail command is entered. The tradeoffs between these approaches are logical name table clutter versus mail image activation speed. $! File Mlist:MailRoute.com $! $ Log_Name_Mode = "Process" $ If F$User() .eqs. "[20,20]" Then Log_Name_Mode = "Group" $ If P1 .eqs. "SYSTEM" Then Log_Name_Mode = "System" $ If P1 .eqs. "MAIL_WITH_ROUTING" Then - Log_Name_Mode = "User_Mode" $! MAIL must be next image run $! $! Local username Desired Mail Destination $DEFINE/'Log_Name_Mode' SYSTEM 2::SMITH $DEFINE/'Log_Name_Mode' FIELD "_FIELD,_VAX2::SMITH" 9 PAGESWAPPER - June 1983 - Volume 4 Number 8 VMS Mail Re-direction, Expansion or Aliasing $! $! Do not make any changes below this line of the file $! done if not pseudo mail $ If P1 .nes. "MAIL_WITH_ROUTING" Then Exit $! Keep mail interactive $ Assign/User_Mode Sys$Command Sys$Input $! Must be the last command in the file!! $ Run Sys$System:Mail.exe Speling Cheker Works Gud by Paula Sharick From LUG Notes of the Rocky Mountain VAX Local Users Group The SPELL program off the fall 82 DECUS tape is missing one piece of useful installation info: namely that you must create your own DEFAULT.DIC and DEFAULT.WRD files in the directory where SPELL software resides. You put words in these files that are site-dependent and specific to your needs. I asked our secretaries for donations and came up with an excellent list. These files are made with any editor, one word/line, uppercase only, and are identical except for the last line. The .WRD file must have a '[' as the last record in the file. the '[' is omitted from the .DIC file. After you make these files, installation proceeds smoothly. Two .CLD files are included and the only omission is a verb definition for the WORDS command. I've been meaning to write the authors for the WORDS definition since no source was included on the tape!! In any case, we discovered a couple of semi-serious bugs (at least at our installation!!). In interactive mode, it is necessary to force a default extension on the input file to .TXT to avoid losing the source file if no corrections are made. In any mode, if a file is longer than 895 lines, the source can disappear. Pageswapper Editor's Note Sharick goes on to say that at her installation they use a DCL command procedure to get around those two problems, and in the RMVLUG original she gives a sample of the command procedure. 10 PAGESWAPPER - June 1983 - Volume 4 Number 8 The Role of the Computer Operator in the VAX Shop The Role of the Computer Operator in the VAX Shop by Lonnie R. Caldwell Manager of Computer Operations/Communications William B. Tanner Company, Incorporated 2714 Union Avenue Extended Memphis, Tennessee 38128 During the Spring Symposium (DECUS) in St. Louis, I was appalled at the several references to the lack of trust in the areas of computer operations, especially for computer operators, by attendees. My background is extensive, and I feel I can speak to this issue. I am a seventeen year (degreed) data processing professional. My job specifications have included tab operator, computer operator, operations supervisor, operations specialist (consultant), Operations Manager, VP and president of my own EDP service company. I have also performed much work in the systems and programming areas. I have a high regard for professionals in both areas of data processing. Operations is generally regarded as a "lower" or less important data processing function than S & P, but this is a fallacy. Both areas require a certain type of person to function well. Both areas are mentally and sometimes physically demanding for the dedicated professional. I wish all operators could work, for a time, with programmers and also that all programmers could work, for a time, with operations personnel. This would give both a greater appreciation and understanding for the other's point of view. S & P staff usually are not "promoted" to operations positions, but those operations individuals who show themselves "worthy" may be given the option to "grow" in a new position in S & P. If a manager cannot "trust" the operations personnel (or any other personnel), then that manager probably is failing in the areas of counseling and motivation. An employee who cannot be trusted is of no use to the company. Contrary to belief in some circles, operators and operations personnel also have very demainding jobs at times. These two areas MUST work together, and not look down upon each other. Blame for failures must not be passed off, but instead the two groups should work together to resolve problems and prevent them from happening again. 11 PAGESWAPPER - June 1983 - Volume 4 Number 8 The Role of the Computer Operator in the VAX Shop I completely trust my operations staff. They work very hard, sometimes alone when we have gone home, and must make important decisions. The final product of a data processing department, the printed reports produced by the operations staff, is what the users see and judge us all by. Please, then let us all work together. 12 PAGESWAPPER - June 1983 - Volume 4 Number 8 VMS Application Downward Compatibility VMS Application Downward Compatibility M. Erik Husby Project Software Development, Inc. _ 14 Story St. Cambridge, MA. 02138 617-661-1444 One of the nice features of VMS is that its software is upwardly compatible. The VMS RTL is an example of this compatiblity; one can link a program against the VMS 3.1 RTL and have it run under the VMS 3.2 RTL. However, there are times where one needs to be downwardly compatible. In our case we distribute executable images to our customers; but not all of our customers will be at the same level of VMS as we are. If we were to link a program under VMS 3.2 it would not run under VMS 3.1. We do not want to distribute object modules so that the customer would have to do a link on his system. The other option is to keep our system at the lowest level of all of our customers. That is not desirable since we want to benifit from the fixes in new releases of VMS. Thus we needed to be able to link a program under VMS 3.2 and have it run under VMS 3.0. This is possible but is not obvious how to do it (The telephone support center claimed it was not possible). For those of you who need this capability, this is how to do it. The first step is to save a copy of the VMS RTL or other sharable image before one does the system update. Then when one links the programs, you reference the older sharable image. Thus one has an image linked under VMS N that will run on VMS N-1. Assume that the VMS RTL has been saved in the directory SYS$SYSROOT:[SYSLIB.VMSOLD], then at link time the following commands would be needed. $ DEFINE/USER_MODE VMSRTL SYS$SYSROOT:[SYSLIB.VMSOLD]VMSRTL.EXE $ LINK/NOSYSSHR IMAGE,SYS$INPUT:/OPTION SYS$SYSROOT:[SYSLIB.VMSOLD]VMSRTL.EXE/SHARABLE The DEFINE statement is needed because the LINKER always attempts to find the sharable image in SYS$SHARE unless a logical name is provided. Without the logical name, the LINKER will complain about the difference in creation dates between the old RTL and the one in SYS$SHARE. The /NOSYSSHR option is needed to prevent the LINKER from searching SYS$LIBRARY:IMAGELIB and getting confused. 13 PAGESWAPPER - June 1983 - Volume 4 Number 8 VMB -- Beware of Field Servants Bearing Gifts VMB -- Beware of Field Servants Bearing Gifts Corot Reason, University of Toronto I was asked to submit this to you because it seems to be of general interest to any site with a 780 running VMS. Sites that have had the Revision 7 hardware FCO installed since they began running VMS V3.0 on their 780 should check that they have the correct bootstrap program on their console floppy (VMB.EXE). This hardware upgrade involves installing new microcode on the floppy and Field Service (in their infinite wisdom) also modified other files on the floppy. In particular, they remove the DU drivers and they install a back-level VMB.EXE. For most sites this will cause no problems until the VMS 4.0 upgrade. With this back-level bootstrap, the upgrade will fail. This problem can be fixed very simply: Copy the floppy to disk (using SYS$UPDATE:CONSCOPY.COM), copy SYS$SYSTEM:VMB.EXE to the directory with the floppy files on it, purge the directory and then copy the files back to the floppy again with CONSCOPY. Using the VMS TKB for RSX-11M Software Development Frank J. Nagy Fermi National Accelerator Laboratory P. O. Box 500 Mail Stop 306 Batavia, IL 60510 (312)-840-4935 A version of the RSX Task Builder is supplied with VMS as the image TKB.EXE in SYS$SYSTEM:. This compatibility mode TKB can be invoked in any of several different manners: $ LINK/RSX11 ... or $ RUN SYS$SYSTEM:TKB or $ MCR TKB ... This particular version of TKB has the following differences from the RSX TKB (or one built from an RSX distribution kit): 1. The default file type of the task image file is ".EXE" rather than ".TSK". This is because executable images (both native and compatibility mode) use the default file type of ".EXE". 14 PAGESWAPPER - June 1983 - Volume 4 Number 8 Using the VMS TKB for RSX-11M Software Development 2. The VMS TKB understands VMS file specifications (including VMS logical names). 3. The default system library is SYS$LIBRARY:SYSLIB.OLB. The major differences between this library and an RSX SYSLIB is in the FCS modules concerned with parsing file specifications. Linking with this library permits a compatibility mode program (using FCS) to handle VMS file specifications. At this time I know of no other major differences between the VMS TKB and the RSX TKB. I also do not know if the RMS-11 libraries distributed with VMS include modifications similar to those in the FCS modules. I have used the VMS SYSLIB and TKB to link PDP-11 FORTRAN 77 to produce an F77 compiler which understands VMS file specifications. We regularly use TKB to build privileged tasks and tasks using shared libraries and commons which run on RSX systems. In the majority of the cases we use the RESLIB and RESCOM TKB options to provide the explicit file specification for the shared library (or common) files. The TKB options LIBR and COMMON can be used but the image and symbol table files must be placed in SYS$LIBRARY: (and the image file type must be ".EXE" rather than ".TSK"). All in all we find the use of the VMS TKB to be quite acceptable for RSX software development. Our only gripe is that we wish it would run faster (on a VAX-11/780). Maybe some day we will get a VAX native mode RSX Task Builder. 15 PAGESWAPPER - June 1983 - Volume 4 Number 8 Philosophy of Editing Philosophy of Editing by Scott Sibley Philosophy of Editing Scott B. Sibley ABSTRACT: Why are users unhappy with DEC text editors? Why are there so many different text editors in the user community? Are text editors important? AUTHOR: B.S. in Computer Science/Math from Univ. of South Alabama; M.S. in Information & Computer Science from Georgia Institute of Tech.; 15 years experience in computer science studies. DISCONTENT - At the 1983 Spring DECUS U.S. Symposium held May 23-27 in St. Louis, Mo., users in several DECUS sessions seemed dissatisfied with text editors provided by DEC. Some DECSYSTEM users expressed the opinion that the DEC Standard Editor, EDT, was much less useful than various screen editors being passed around in the user community. Some VAX users who have non-DEC terminals are using the PDP-11 "MCR EDI" editor, rather than line-mode EDT. Other VAX users, also with non-DEC terminals, demand a terminal-independent screen editor; a line-mode editor is believed unacceptable. Some SOS editor users are unwilling to sacrifice the character pattern-matching capabilities of the SOS string-substitution command. USER SOLUTIONS - Through the years, computer users have tried to solve the problem of providing productive, enjoyable text editors. Commercial text editors have been purchased to add to the basic operating system. Many experienced programmers have resorted to writing their own text editors. Today, there exist thousands of text editors all over the world. EDITOR IMPORTANCE - By observing the proliferation of text editors, it appears obvious that users think text editors are important. Is there an underlying reason? I believe that editors are important mainly because people make mistakes. Imagine if users could type at almost infinite speed -- corrections could be made almost instantaneously. What would text editors look like? Would text editors be needed? These questions seem to put text editing in a proper perspective; perhaps many text editors are "Much Ado About Nothing". GENERAL EDITING - Despite the diversity of editors, many editors each have useful selling points; however, more importantly, all editors have similar, or identical features. In addition, besides text editors, DEC provides other editors with VAX/VMS. For example: 16 PAGESWAPPER - June 1983 - Volume 4 Number 8 Philosophy of Editing AUTHORIZE - Edits the VMS User Authorization File. DISKQUOTA - Edits disk quota files on each disk. SYSGEN - Edits VMS system tuning parameters. Considering the other types of editing programs, text editing is now seen as a special case of a more general concept -- Data Editing. Notice that the AUTHORIZE, DISKQUOTA, and SYSGEN data editors are line-mode editors. I believe that line-mode editors have a lot more capability than most people realize. In fact, I personally prefer using a properly-designed line-mode editor to using a screen editor. If DEC were to properly design and market a line-mode editor (EDT line mode is not properly designed), many user complaints would very likely disappear. MORE INFORMATION - The proper design of a line-mode editor is a complicated subject, more directed to development programmers than to general users. Anyone interested in detailed editor design should refer to the 1982 Fall DECUS U.S. Symposium Proceedings formal paper, "EE - A Text Editing Subsystem with VMS Capabilities". This scientifically-designed, line-mode (terminal-independent) editor is on the 1982 Fall VAXSIG Tape. Until DEC releases an improved line-mode editor, users may wish to use the EE editor (source code based on VAX-11 FORTRAN, no MACRO assembly language). ACP Failure Problem with spooled terminals. Many may know about this problem but for those who don't I would like to help the unsuspecting. For the various groups of users on our system we have setup logical names for the serial line printers(i.e. LA120's) that they use so that they refur to them by logical names PR1:,PR2: etc. Now if you have set up a device queue by the name of TTD1: and TTD1: has been assigned the logical name of PR1: and the user does a SET DEVICE/SPOOLED command using the logical name PR1: and then start the que PR1: every thing will appear to work until you do a close of a file sent to "PR1:". The close causes RMS to do an implied send to SYMBIONT but when it gets the no such QUEUE error you will receive the error ACP FAILURE and nothing will go to the spooled device. 17 PAGESWAPPER - June 1983 - Volume 4 Number 8 Commercialism Commercialism by Dave Johnson Lockheed Research, MS 5233/255 3251 Hanover St., Palo Alto, CA 94304 As a LUG chairman, I have been constrained by the "commercialism" policy of DECUS, and have been careful to see that any "Third- party" presentations to the LUG are completely and purely technical. I have done so willingly; I agree with the commercialism policy, and I support it 100%. I now find that DEC (and DECUS?) do not feel similarly constrained. Third party vendors are littering the Exhibition Hall at a DECUS symposium, hawking their wares. Speaking as an individual (I have not had time to pulse the LUG membership on this issue) I am extremely disappointed, if not outraged. I feel that this sets a terrible precedent. I would rather see DEC do away with the Exhibit, if they are having trouble financing it, than pollute it in this way. And finally, I see absolutely no reason why I should feel bound by any "non-commercialism" policy, now that DEC/DECUS has seen fit to tear it up. VAX SYSTEM SIG CAMPGROUND for Las Vegas by Joe Angelico Now that St. Louis Symposium is history, I would like to hear from all of you who visited the campground. Tell me what you liked about it, what you didn't like, and what you want to see at the campground in Las Vegas. I have volunteered to coordinate the campground and I need your input. Send comments to Joe Angelico c/o CCGDEIGHT(dt) Hale Boggs Federal Building 500 Camp Street New Orleans, LA. 70130 18 PAGESWAPPER - June 1983 - Volume 4 Number 8 Symposium Thanks Symposium Thanks I just wanted to express my appreciation for all the work that went into the DECUS symposium. This was my first DECUS symposium and I was very impressed with the quality of the presentations and the way everything worked in a well organized manner. I was also very impressed with the freedom of expression exhibited by the Digital employees and the information available from them. I have not seen many vendors as open to the suggestions and requests of their users as DEC appears to be. Once Again, Thank you Lloyd E. Sampsel, Director of Educational Computing Walla Walla College Just wanted to send a note to tell you and the staff of the DECUS Symposia that I think you did a fantastic job of organizing the meeting. I have never seen soooo many people coordinated in such a magnificant way. The facilities were great, the food was (for the most part) excellent, and the organization of the sessions was super. For my first time at a DECUS meeting I am very impressed. Thanks, (sure hope you can repeat the feat at the Las Vegas meet). From Orin R. Wells General Electric Company - Nuclear Energy Div. San Jose, Ca. Comments on the Symposium Novice Sessions From an anonymous member As a fairly new VAX user, I was greatly disheartened in Anaheim (my first DECUS) when most of the "novice" sessions turned out to be anything but. My thanks to the VAX SIG this time around for filling in the need for more novice session. They were a big help. Another new VAX user comments on the Pageswapper 19 PAGESWAPPER - June 1983 - Volume 4 Number 8 Comments on the Symposium Novice Sessions As a novice to VAX, I find the Pageswapper somewhat helpful, although many (if not most) of the articles are very jargon-filled, making them harder to comprehend than they need to be. General VAX Systems SIG Service to Novice Users Joe H. Gallagher, Ph. D. Director, Medical and Research Computing Cleveland Clinic Foundation 9500 Euclid Avenue, Cleveland, Ohio 44106 (Chairman of SIG-18 and Editor of the SIG-18 Newsletter BANK and PAGE from 1974 to 1979) In one of the novice sessions during the early part of the week at the St. Louis Symposium you asked if the questions and answers which were being presented during the session were appropriate for inclusion in the PAGESWAPPER. The session was a novice to intermediate one. The answer should be an overwhelming YES. The attendees at the symposium and readers of the PAGESWAPPER are two, not necessarily overlapping groups. The PAGESWAPPER (and Symposium sessions) should address the needs of the many diverse groups within the VAX SIG. With the growth of the use of the VAX into many new marketing and application areas, there are many "new" users of VMS. Devoting some page space in the news letter is important to help make the novice users of VMS into intermediate and advanced users. If page space can not be increased to accomodate all the material, then priority should be given in the following order: 1. serious problems and bug fixes 2. news of the SIG and symposium activities 3. information (hints) for novice and intermediate users 4. information (hints) for advanced users 5. problem solving for individual users. Using on-line entry of material to the PAGESWAPPER and the editor of the PAGESWAPPER is an excellent idea. It should be continued, consistant with system security and editorial quality and good taste. 20 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC Spring 1983 SIR Response from DEC by Gary Grebus, SIR Coordinator with a little help from The VMS Development Group One of the highlights at the St. Louis symposium was the System Improvement Request (SIR) session at which DEC responded to the results of the recent SIR ballot. C. W. Hobbs of the VMS Development Group presented DEC's responses to the top ten items from the ballot. The SIR ballot was published in the February 1983 issue of the Pageswapper. Only 237 responses were received, a disappointingly small number given the circulation of the Pageswapper. However, there was a very strong consensus in the selection of top ten items across all processor types and applications areas. The text of the SIR's and the DEC response is given, along with the total number of points which the SIR received in the voting. 1: SIR: S83-020 (1777 points) Abstract: Implement the capability to do a DIRECTORY by UIC. Description: It is frequently necessary to locate all the files on a volume owned by a particular user. This is especially important in resolving problems involving disk quotas. The DIRECTORY command should have a qualifier which would allow a selective listing of file by owner UIC. Response: In the next major release of VMS the DIRECTORY command will have the ability to select files according to the identification of the owner. 21 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC 2: SIR: S83-018 (1599 points) Abstract: The VMS COPY command needs a /OWNER=uic qualifier. Description: Frequently, files are created by one set of users on a system for use by another set. These files must be "delivered" to their end users with the correct ownership. The COPY command should have a /OWNER qualifier which allows a suitably privileged user to specify the ownership of an output file. Response: We will seriously consider this feature for the next major release of VMS. 3: SIR: S83-019 (1251 points) Abstract: A tape transfer utility is needed. Description: A tape handling utility should exist in VMS to read and write non-VMS tape formats. This is especially useful when conducting projects which encompass the use of more than one computer. Presently available utilities will not allow transfer between DEC supported operating systems, e.g. VMS, RT-11, and TOPS-10. Response: The VMS system does not define a tape format, it supports the ANSI standard for magnetic tape labels and file structure. As support for the ANSI standard becomes more widespread among the systems supplied by DIGITAL and other vendors, the need for a special tape utility will become less and less significant. Therefore, it is unlikely that VMS will provide a special utility to process non-ANSI tape volumes. 22 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC In the next major release of VMS a new native-mode utility will replace the existing compatibility-mode utility FLX. In addition to the FLX capability of manipulating RT-11 disks and DOS-11 tapes, the new EXCHANGE utility will have some ability to read and write RT-11 format magtapes. Support for RT-11 tapes is not a first-order goal for EXCHANGE, however. The problems and restrictions in this support are due to the fact that RT-11 only partially implements the ANSI standard for magnetic tape labels and file structures. The VMS development group has been working with members of the DECsystem development group to improve the ability to interchange data with the DECsystems. Unfortunately, it is very unlikely that any interchange utility will be available with the next major release of VMS. 4: SIR: S83-010 (1230 points) Abstract: Improved documentation of VMS system service capabilities. Description: There should be an Applications manual as part of the VMS documentation set. The manual would present topics according to application or use, as opposed to system service. It should also present topics in a "How to" format and should be oriented toward high level language use of the system services. Response: Several changes are planned for the systems services documentation in the next major release of VMS. The manual will be focused more directly on the the high-level language user, and most examples will use high-level languages. There will also be a programming guide which will provide application-oriented information about programming under the VMS operating system. 23 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC 5: SIR: S83-029 (942 points) Abstract: There should be full support for print and batch jobs in VAX to VAX networks. Description: There should be full support for directing a file to a print or batch queue which resides on another VAX node in a DECnet network. All options that can be specified for a local job should be supported. This simplifies having certain machines in a network dedicated to batch or applications processing. The work can be conveniently routed to the appropriate batch queue. This also simplifies routing of printed reports, etc. to various destination nodes. Response: This subject is being addressed at the DECnet architectural level, therefore it is inappropriate at this time for VMS to attempt a solution for this problem. When the DECnet architectural issues are resolved, VMS will implement support. In VAXcluster systems, the system job controller will be able to operate across different members of the cluster, as long as all mass storage referenced by the print or batch job is visible to the cluster. 6: SIR: S83-004 (882 points) Abstract: Multiple levels of control are needed for terminal broadcast messages. Description: There need to be at least three levels of control over BROADCAST messages to terminals. These levels are: a. Never send a BROADCAST message (this is not an interactive terminal) b. Send only "high priority" messages (allows system manager to warn that system is going down, etc.) c. Allow all BROADCASTS (MAIL, /NOTIFY, etc.) 24 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC Response: The next major version of VMS will have many changes in terminal broadcast services. The implementation currently being studied has multiple classes of broadcast messages (for example, messages from MAIL would constitute a separate class) which can be individually enabled or disabled from the terminal. There is a provision for installation-defined broadcast classes. The three levels of control which are suggested could easily be implemented by enabling or disabling appropriate classes. 7: SIR: S83-016 (806 points) Abstract: Enhance the INQUIRE command to reduce the need for editting of responses. Description: The INQUIRE command should be enhanced to have at least the capability of the MCR .ASK, .ASKN, and .ASKS. This makes the migration from MCR to DCL much easier. It also saves considerable coding in DCL. INQUIRE should provide for checking of responses for such things as YES/NO, string, and numeric (with range and radix checking). If the response does not meet the checks, the question is automatically repeated. It should also be possible to specify default values to be taken, and to support timeout of the INQUIRE. Response: We do not anticipate providing the capability of the MCR .ASKx commands in a future release of VMS. In the next major release of VMS it will be possible to easily determine what the format of a response is, for example whether it is a string or an integer. 25 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC 8: SIR: S83-013 (803 points) Abstract: The DCL SPAWN command needs a /CONTINUE qualifier. Description: One of the most common uses of the SPAWN command is following the Control-Y interruption of an image. It should be possible to perform the SPAWN with a /CONTINUE which indicates that the interrupted image is to be CONTINU'ed following a return from the subprocess. This would prevent accidental loss of the executing image (which was probably a text editor). Response: Providing this capability is reasonably straightforward in the case of a command like: $ SPAWN /CONTINUE ANALYZE /SYSTEM where a single command is executed and the interrupted image is continued. Unfortunately, the general case is much more difficult to solve. This is when a tree of subprocesses have been spawned, and where ATTACH and LOGOUT are used to move around the tree. We will investigate this request, but it is unlikely that this capability will be present in the next major release of VMS. It is possible that the /CONTINUE qualifier would have to be restricted to the simpler case where a command follows the SPAWN verb. 26 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC 9: SIR: S83-024 (802 points) Abstract: Disk bad block reporting should be more explicit. Description: If the error logger detects a bad block in an existing file, it will continue to report errors for each access to the block. Only if the file is deleted will it be flagged as bad and put out of service. While the system must know where the bad block is, it does not provide enough information to determine the file in which it is contained. Only with this information is it possible to do something about the recurring errors. Response: When a bad block is detected on a Files-11 disk, the ACP marks the file header for that file as containing a suspected bad block. When the file is deleted, the bit is used to initiate the bad block scan of the file. This results in the retirement of any unusable blocks. The VERIFY utility (ANALYZE /DISK_STRUCTURE) reports files which are marked as containing bad blocks, for example: $ ANALYZE /DISK_STRUCTURE DYA0: . . . %VERIFY-I-BBLHEADER, file (1936,42,1) MPTIMER.LIS;1 contains suspected bad blocks . . . VERIFY does not report information about the directory containing the suspect file. A short program could be written which would use RMS to open the file by file id, and then display the resultant file name information. An alternative to writing a program would be to use the compatibility-mode utility PIP (or DMP) to open the file. A sample command would be: $ MCR PIP TT:=DY0:/FI:1936.:42. (Note the decimal points after the file id numbers -- PIP assumes that file ids are octal unless they contain decimal points.) After giving this command, the output should be stopped with a CONTROL/S. If the command $ SHOW DEVICE /FILES DYA0: is given from another terminal while the file is open by PIP, the SHOW DEVICE display will give the full file name of the file containing the bad blocks. For the next major release of VMS we will attempt to make it much simpler to find the full file specification of a file containing bad blocks. 27 PAGESWAPPER - June 1983 - Volume 4 Number 8 Spring 1983 SIR Response from DEC 10: SIR: S83-008 (767 points) Abstract: The $GETJPI system service should return a process default device and directory. Description: These two pieces of information are very useful. Particularly, this would allow locating a users's default directory from a Process ID. Response: There are some significant problems in providing this information. The default directory is maintained by RMS in the process control region (P1 space). This information can be obtained using techniques currently employed by $GETJPI to retrieve other information stored in P1 space. The default device, however, is contained in the translation of the logical name SYS$DISK. Obtaining this information would require $GETJPI to use the translate logical name system service in the context of the target process. In addition, a directory specification in SYS$DISK can override the directory specification maintained by RMS. We will investigate providing this information for the next major release of VMS, but due to the technical problems involved it quite possibly will not be implemented. 28 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 137 Caption: Macro generator (for any language) Message: We are looking for a macro generator that would be language independent and allow us parameter substitution, conditional macro expansion, include files, etc... Contact: Alberic MULLER C.I.R., Neumarkt 2076 G A L S /Switzerland (032) 83 13 33 Date: April 18, 1983 INPUT/OUTPUT 138 Caption: File recoverability (rollback) for RMS Message: We are looking for a package providing a recovery feature for RMS files (similar to DBMS rollback) both on VMS and RSX systems. Contact: Sam Norton Tennessee Eastman Company B-284 Kingsport, Tennessee 37662 (615) 229-6279 Date: April 25, 1983 29 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT INPUT/OUTPUT 139 Caption: High Speed VAX-Multibus Link Message: MESA Technology Corporation has developed an Intel Multibus board to provide high speed (1 MB/S) data transfer between a VAX DR11-W and the Multibus. The standard DR11-W driver (XADRIVER) may be used on the VAX and a programming guide with examples is provided for Multibus based systems. MTC is using this board in several of its systems. Contact: MESA Technology Corporation 16021 Industrial Drive Gaithersburg, Maryland 20877 (301) 948-4350 Date: April 26, 1983 INPUT/OUTPUT 140 Caption: Looking for DP Operations Tools Message: We are looking for a workload scheduling system that would print out operations run sheets (run instructions) based on some sort of forecasted schedule. We are also looking for a tape library management system. Will trade our VAX BASIC Automated Program Documentation and/or Automated Program Modification History systems, or will improve a scheduling system and make it available to others. Contact: Dave Harris or Lee Wysocki Jensen Tools, Incorporated 7815 South 46th Street Phoenix, AZ 85040 (602) 968-6241 Date: April 27, 1983 INPUT/OUTPUT 141 Caption: Formatting Tape Cartridges on a TU58, VAX 11/730 Message: We are running UNIX on the 730 and need the ability to format/reformat the DECtape cartridges under UNIX or via a cartridge loadable utility using the monitor. 30 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT Contact: Donn Fisher Integrated Office Systems 1340 Saratoga-Sunnyvale Road San Jose, CA 95129 (408) 257-0171 Date: April 28, 1983 INPUT/OUTPUT 142 Caption: Spread Sheet Program available for VAX Message: A spread sheet program written in Pascal is available for the VAX. It is based on SuperCalc as available on the Osbourne. The implementation is written in largely standard Pascal. Not free, but priced very competitively. Contact: Neil S. James Computing Centre, University of Otago Box 56 Dunedin, New Zealand 771640 extension 612 Date: April 29, 1983 INPUT/OUTPUT 143 Caption: Want Process Accounting Chargeback in BASIC Message: We are looking for a Process Accounting Chargeback System written in VAX-11 BASIC. Any information leading to the acquisition of such a package would be appreciated. Contact: Doug Balsdon, System Manager Edwards/General Signal 625 6th Street East Owen Sound, Ontario N4K 1G5 (519) 376-2430 x219 Date: April 29, 1983 31 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT INPUT/OUTPUT 144 -- RESPONSE TO I/O # 98 Caption: Personal Bibliographic System Message: I have some portable Fortran software which efficiently maintains personal bibliographic collections of up to a few thousand documents. Facilities include retrieval based upon Boolean combinations of author nnames and descriptor terms, document modification, author index generation, KWIC index generation, document unloading and reloading, and a macro processor for interfacing to any text processing system. Distribution tape, user's guide and implementation notes available for $(A) 100. Contact: Dr. Ken J. McDonell Department of Computer Science Monash University Clayton, Victoria, 3168 Australia (03) 541-3900 Date: April 25, 1983 INPUT/OUTPUT 145 Caption: Interactive Command Editor, Version 3.0 Message: Watch for ICE Version 3.0 on the Spring SIG Tape (St. Louis). This new release of ICE is "EDT-compatible" and supports only the VT100 terminal family. (i.e., it uses the keypad and arrow keys). From the SYSTAT/SYSDPY folks. Contact: Stuart Renes Western Electric Company 3000 Skyline Drive, Department 477 Mesquite, Texas 75149 (214) 288-2286 Date: May 25, 1983 32 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT INPUT/OUTPUT 146 Caption: WYLVAX now available through NESC Message: WYLVAX, the interactive text editor developed at the Stanford Linear Accelerator Center, is now available through the National Energy Software Center. WYLVAX is a powerful, high speed text editing system which simulates the English-like Stanford WYLBUR editor. Contact: NESC Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 Date: May 3, 1983 INPUT/OUTPUT 147 Caption: Need LISP for VMS Message: I am looking for a LISP interpreter/compiler to run on a VAX/VMS system. Contact: David J. Effa, System Manager Northrop Corporation 600 Hicks Road, Room 6214 Rolling Meadows, IL 60008 (312) 259-9600 x5436 Date: May 4, 1983 INPUT/OUTPUT 148 -- RESPONSE TO I/O # 117 Caption: LISP for VMS Message: Laboratory for Computer Science has released V0 of a New Implementation of LISP (NIL). This is in public domain and while it may have a few bugs, it is supposed to be reasonably stable. An internal compiler generates very fast threaded code. Order from: G. S. Burke MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139 The cost is $100. 33 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT Contact: John Mealing Mead Office Systems 1307 Glenville Drive Richardson, Texas 75081 (214) 669-1500 Date: May 9, 1983 INPUT/OUTPUT 149 Caption: $ SET PROCESS/USERNAME= Message: Does anyone have a program (or patch) which will allow modification of the username of a process? We had a program called "SETUSER" for our V 2.5 system that doesn't like V3.n. Any code, images, or ideas on this topic will be appreciated. Contact: David G. Dugal 126 Bloomfield Street Pawtucket, RI 02861 (401) 792-2559 Date: May 15, 1983 INPUT/OUTPUT 150 Caption: MUX200 RJE Emulator Message: Has anyone used the emulator package with more than one modem (i.e. two users connected to different remote sites) ? Contact: Chuck Rothauser United Technologies Research Center (203) 727-7241 Date: May 25, 1983 34 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT INPUT/OUTPUT 151 Caption: DTR32 Hint Message: If you would like to print a date and time in VMS standard form and you have a USAGE IS DATE field, use PRINT field-name USING X(25). Contact: EYE::USER !!! Date: May 25, 1983 INPUT/OUTPUT 152 Caption: Need COBOL Compiler Message: I would like to know if anyone has for sale a COBOL compiler (source code) written in either FORTRAN or PASCAL. Contact: David Slater Mantech International 2320 Mill Road Alex. VA 22314 Date: May 25, 1983 INPUT/OUTPUT 153 Caption: COBOL Question Message: We are new VAX users in a COBOL environment. Contrary to popular belief, COBOL is a language and it is used effectively on a VAX. However, we have a question that we have not been able to get an answer to so maybe you can use your powers and find out for us. would appreciate an answer in either pageswapper or if you could relay it to the "reserved word" (please).We are converting from an antiquated CDC-6400, and all programs create report files using explicit carriage control characters. we realize VMS has a "FORTRAN carriage control" record type, but, we cannot find anyone that can tell us how (or if) we can create a FORTRAN carriage control file out of COBOL. Contact: EYE::USER !!! Date: May 25, 1983 35 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT INPUT/OUTPUT 154 Caption: Request For Session Tape Message: If anyone taped Stan Amway's presentation, "Designing & Implementing VAX/VMS Applications for Performance", (10:15 - 11:15, Friday, May 27, 1983), I am interesting in buying a copy of it. Contact: W. Lynn McKinney DBA Systems, Inc. P.O. Drawer 550 Melbourne, FL 32902-0550 Date: May 25, 1983 INPUT/OUTPUT 155 Caption: Logging of terminal tranasactions for deferred printing Message: Wait till Las Vegas! The author will present a paper on how to capture transactions to/from a non-hardcopy terminal and capture them in a file, possibly for later printing. This is being presented because of being listed in Pageswapper as one of the most wanted items. The program will be submitted to DECUS to go on the Fall 1983 tape from Las Vegas. Contact: Steve Berman Ultrasystems, Inc. 2400 Michelson Drive Irvine, California 92715 (714) 752-7500 Date: May 25, 1983 36 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ Telephone ____________________________ If this is a reply to a previous I/O, which number? ________ Signature _____________________________ Date ________________ Mail this form to: PAGESWAPPER Editor, DECUS, MRO2-1/C11, One Iron Way, Marlborough, MA 01752, USA 37 PAGESWAPPER - June 1983 - Volume 4 Number 8 INPUT/OUTPUT Submission Form Tear out to submit an I/O item PAGESWAPPER Editor DECUS, MRO2-1/C11 One Iron Way Marlborough, MA 01752 USA 38 PAGESWAPPER - June 1983 - Volume 4 Number 8 System Improvement Request Submission Form System Improvement Request Submission Form SIG ref no. _________ Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ Circle application area(s) most closely related to yours (OEMs circle end use): Transaction Processing Business EDP (accounting) Program Development Systems Development General Timesharing Student Timesharing Shared Small Applications Shared Large Applications Process Control Word Processing Large Simulation ________________________________________________________________ System Configuration: CPU Model: System Disk: Memory Size: Average User Load: Operating System: Version: ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description (include justification and expected usefulness): Use additional pages if required Completed SIR should be returned to: Gary L. Grebus, Battelle Columbus Laboratories, 505 King Avenue, Columbus, Ohio 43201, USA 39 PAGESWAPPER - June 1983 - Volume 4 Number 8 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories 505 King Avenue Columbus, Ohio 43201 USA 40 PAGESWAPPER - June 1983 - Volume 4 Number 8 DECUS US Chapter Subscription Service Form DECUS US Chapter Subscription Service Form 41