PAGESWAPPER Building a Demanding Real-Time Simulation Under VAX/VMS Charles W. Bolz Brian F. Beal Boeing Computer Services Co. Boeing Aerospace Co. Kent, WA Kent, WA ABSTRACT A demanding real-time simulation using hardware from diverse sources failed because of VAX/VMS scheduling and timeout overhead and powerfail handling. Success of the simulation required consolidating many of the high duty-cycle tasks, redirecting the VMS one-second timer queue element to a user-written routine, and bypassing the standard device driver powerfail handling. BACKGROUND An air-launched anti-satellite missile program uses a VAX 11/780 to create a simulated environment for embedded aircraft and missile onboard computers. These computers provide navigation and autopilot, plus command, control and communications capabilities. The air-launched missile part of the simulation uses eight DR11-B, two DR11-L and five DR11-M UNIBUS interface boards plus a custom debug interface to communicate with flight computers. A second UNIBUS interfaces eight DR11-B's to the embedded aircraft computer; this UNIBUS also supports command 1 PAGESWAPPER - February 1984 - Volume 5 Number 8 Building a Demanding Real-Time Simulation Under VAX/VMS terminals and electrostatic printer/plotters. Massbus disk drives are used for journalling of simulation data. The simulation must perform a large number of tasks. Many, such as trajectory and dynamics computation and airborne equipment simulation are time-critical; others, such as maintaining controls and displays and journalling simulation data can be done in the background. The simulation is synchronized by a missile inertial platform clock which interrupts on a DR11-B every five milliseconds. The simulation must handle as many as 400 interrupts per second from all other devices. A typical scenario lasts two or more hours. During this time non-real-time users may use the VAX for interactive program development work, accepting degraded response. The simulation was initially set up as a number of demand-driven processes; e.g., an aircraft computer interrupt might schedule an aircraft computer simulation process. Process context switching overwhelmed the simulation. Once the scheduling overhead had been made manageable, it was noticed that clock-controlled event flags were occasionally not set, causing the VAX simulation to fall behind the onboard computers. This was traced to extensive housekeeping code in the VMS one-second timeout handler EXE$TIMEOUT. Then a transient powerfail condition on the second UNIBUS sometimes caused the simulation to be lost. The following sections discuss modifications made to the simulation, the system and to the drivers to solve these problems. DEVELOPING THE SIMULATION The designers of the simulation were quite aware of VAX/VMS $QIO system service overhead. This overhead was eliminated by borrowing two ideas from the CONINTERR (Connect-to-Interrupt) driver. First, the driver interrupt service routines do not call the I/O post-processing routines (REQCOM); they reinitialize for another I/O operation on the device. And second, the drivers access user buffers by double-mapping them into system space. The designers were not aware, however, of the VAX/VMS context switching overhead (about 300 microseconds on the VAX 11/780). So, as originally implemented, scheduling overhead was excessive. It was noted that although data came in frequently and asynchronously, the VAX only needed to transmit data to external devices at twenty millisecond intervals. The simulation was therefore modified as follows. (1) The time-critical tasks of the aircraft simulation and of the missile simulation were consolidated into two processes which run every twenty milliseconds. Less time-critical processes such as displays and journalling are invoked as required by the twenty-millisecond tasks and run in the background. 2 PAGESWAPPER - February 1984 - Volume 5 Number 8 Building a Demanding Real-Time Simulation Under VAX/VMS Processes communicate via a simulation database which is implemented as a global section. (2) The driver handling the five millisecond clock was modified to set an event flag every fourth interrupt to schedule the twenty millisecond tasks. (This required that the driver fork to Interrupt Priority Level (IPL) 6 to achieve synchronization with the system data base.) The twenty millisecond processes in turn schedule the less time-critical processes as required. (3) Input device drivers use chained buffers. When data comes in they time-tag the buffer, set flags in the simulation database for the twenty millisecond process and remap the UNIBUS adapter to the next buffer in the chain. They may also perform device-specific time-critical code. REDIRECTING EXE$TIMEOUT At system startup time VMS sets up a repeating timer queue element (TQE) to call EXE$TIMEOUT once per second. EXE$TIMEOUT performs the following functions: (1) Calls SCH$SWPWAKE to determine if the swapper should be awakened. (in addition to its normal duties the swapper writes modified page list entries to disk and delivers powerfail AST's) (2) Increments the system one-second clock, EXE$GL_ABSTIM. (3) Calls ERL$WAKE to determine if the error log formatter process should be awakened. (4) Calls ECC$REENABLE to determine if memory controller errors should be logged. (5) Scans all device UCB's for timeouts and power failures. (6) Checks for timed-out locks. (7) Scans PCB's for processes needing a temporary priority boost This code runs at IPL$_SYNCH. Connect-to-interrupt drivers fork to IPL 6, one level lower, so they can synchronize event flag servicing. The error routines involve substantial code, much of which executed at 31 second intervals under VMS 2.0. When most or all of the EXE$TIMEOUT activities coincided, IPL 6 interrupts could be blocked out for many milliseconds! (Under VMS 3.0 these intervals are staggered; we haven't checked the effectiveness of this strategm.) 3 PAGESWAPPER - February 1984 - Volume 5 Number 8 Building a Demanding Real-Time Simulation Under VAX/VMS We decided that we could do without most of the EXE$TIMEOUT servicing; we only needed to make sure that the one-second clock and the page lists were maintained. So we decided to provide our own one-second timer routine and, at the beginning of the simulation, redirect the timer queue entry to it. At the end of the simulation we restore EXE$TIMEOUT as the timer routine. We chose to put the code to do this in the mission clock driver. We placed the following code in the Start I/O routine to search the system timer queue for the one-second timer element, and to modify it to point to our own timer routine. SAVE_ONESECOND_TQE .BLKL 1 ; address of redirected TQE ... DSBINT ; disable all interrupts CLRL SAVE_ONESECOND_TQE ; flag as not redirected MOVAL G^EXE$GL_TQFL,R0 ; get timer queue listhead MOVL R0,R2 ; save address for end check MOVAL G^EXE$TIMEOUT,R1 ; get one-second timer address 10$: MOVL (R0),R0 ; get address of next TQE CMPL R0,R2 ; reached end of timer queue? BEQL 20$ ; yes - desired TQE not found!?! CMPL 12(R0),R1 ; is this TQE EXE$TIMEOUT? BNEQ 10$ ; no - go check next TQE MOVL R0,SAVE_ONESECOND_TQE ; yes - save the TQE address MOVAL OUR_TIMEOUT,R1 ; get address of our routine... MOVL R1,12(R0) ; and substitute in TQE! 20$: ENBINT ; enable interrupts & continue. We placed the following abbreviated timeout routine code after the Start I/O routine. OUR_TIMEOUT: ; our version of EXE$TIMEOUT JSB G^SCH$SWPWAKE ; write out modified pages INCL G^EXE$GL_ABSTIM ; increment one-second clock ...do some mission-specific one-second processing! RSB We placed the following code in the Cancel I/O routine to restore the system timeout routine: DSBINT ; disable interrupts MOVL SAVE_ONESECOND_TQE,R1 ; get one-second TQE address BEQL 10$ ; was TQE redirected? MOVAL G^EXE$TIMEOUT,R0 ; get orig timeout address MOVL R0,12(R1) ; and restore TQE 10$: ENBINT ; reenable interrupts 4 PAGESWAPPER - February 1984 - Volume 5 Number 8 Building a Demanding Real-Time Simulation Under VAX/VMS When timeouts are disabled users will not be notified of such events as printers running out of paper and logins timing out. More important, drivers will not be notified of failure of an I/O operation. If this is critical to a driver, it should set up its own timer queue element. THE POWERFAIL PROBLEM During the simulation development a UNIBUS power supply intermittently failed just long enough to trigger a UBA powerfail interrupt; when this happened the simulation would terminate. Because the problem was transient and because there were some marginal non-DEC interfaces on the UNIBUS the problem took some time to diagnose. Meanwhile we had to continue development of the simulation. VAX/VMS does many things when notified of a UNIBUS powerfail; one of them is to scan the UCB's for all devices on the UNIBUS and, for any which have I/O in progress, clear the interrupt expected bit, set the timeout and powerfail bits in the UCB status word and set the timeout duetime to the current time. Thus drivers are notified within the second that something went wrong somewhere and given a chance to recover. Unfortunately, this sequence caused our simulation to fall out of synchronization with the flight computers by many twenty millisecond cycles. And of course once we modified EXE$TIMEOUT our drivers were not even notified! We decided to bypass this mechanism by defining our own "interrupt expected" bit, UCB$M_OURINT in UCB$W_DEVSTS. If our interrupt bit is set when an interrupt comes in, but the standard interrupt bit is not set, we check UCB$M_PWR in UCB$W_STS. If that bit is set indicating a power failure, we recover any failed I/O operation, log the event, and continue the simulation. This technique should be used only after thorough analysis of the devices involved and of the simulation requirements. We used it only to continue running until an obscure hardware problem was diagnosed and corrected. CONCLUSIONS VAX/VMS provides an outstanding environment for development and execution of complex real-time applications. The VAX is, however, a general purpose computer and operating system features supporting the larger community can sometimes degrade real-time tasks. But VAX/VMS is robust and well documented. Once the timeout and powerfail problems described in this note were diagnosed, the workarounds presented were quickly implemented. 5 PAGESWAPPER - February 1984 - Volume 5 Number 8 In this issue... In this issue... Building a Demanding Real-Time Simulation Under VAX/VMS . . . . . . . . . . . . . . . . . . . . . . 1 In this issue... . . . . . . . . . . . . . . . . . . 6 Editor's Workfile . . . . . . . . . . . . . . . . . 7 Suggestions for TECO . . . . . . . . . . . . . . . . 7 Implementing a resource chargeback system on VMS . . 9 The VAX Systems SIG Symposium Tape for Fall 1983 (Las Vegas) . . . . . . . . . . . . . . . . . . . 20 Fall 1983 VAX Systems SIG Tape Distribution . . . 24 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . 41 LUG Meeting Reports . . . . . . . . . . . . . . . 44 VAX System SIG Committee List . . . . . . . . . . 46 INPUT/OUTPUT Submission Form . . . . . . . . . . . 49 System Improvement Request Submission Form . . . . 51 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 text (best is Runoff source). Please do not submit program source, as that is better distributed on the VAX SIG tape. Material for "The DBMS Monitor" section of the Pageswapper (pertaining to VAX-11 DBMS) should be sent to: Julie Llewellyn United Technologies Microelectronics Center 1365 Garden of the Gods Road Colorado Springs, CO 80907 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. 6 PAGESWAPPER - February 1984 - Volume 5 Number 8 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor Remember to voice your opinion on the value of various suggested changes to VAX software. Send in the SIR ballot found in the January 1984 Pageswapper. All members are eligible to vote, so if you share someone else's copy of the Pageswapper, send in a facsimile of the ballot, but with your own membership number (and your own choices, of course !). Suggestions for TECO Editor's Note The following letter is addressed to DECUS supporters of TECO, but the TECO most people use on the VAX comes from DEC (with common roots). I decided to publish it here though because I am the fourth person in DECUS to be passed this letter for processing, and I think we should not let our internal bureaucracies get in the way of communication. If there is somebody else who thinks this letter really belongs to them, I hope they read the Pageswapper. 02-Dec-83 TECO SIG C/O DECUS ONE IRON WAY MARLBORO MA 01752 Gentlemen: 7 PAGESWAPPER - February 1984 - Volume 5 Number 8 Suggestions for TECO 1. First, let me say how much I enjoy working with TECO, and creating MACRO's using TECO. VERY VERY NICE. 2. A "missing" feature of TECO has become apparent, as I work with the editor. I would like to be able to specify a MATCH CHARACTER which specified "ANY NUMBER OF CHARACTERS". This would enable me to search for a PARAGRAPH which started with the string "ABCDE", had any number of characters, and was terminated with the string "END.OF.TEXT". For example, if I had the text: Now is the time for all good men to come to the aid of their fellow man. I could search for this amount of text with the search construct of: SNOW^EZMAN.$ This would find the string "NOW", anchor, and search for the string "MAN.", which if not found would default to the end of the buffer. A successful search would set up ^Y correctly. Imagine what you could do. 3. The second thing I would like to be able to do would be to compare two strings contained in Q registers. I would want the comparison to return a number indicating: -1 first Q register < second Q register 0 first Q register = second Q register 1 first Q register > second Q register however, I would be willing to work with anything else. Naturally, I would expect the current match modes to remain in effect for the test. You could then code the following: ^ETAB "L In which case if A$ < B$ then do, ^ETAB "E In which case if A$ = B$ then do, ^ETAB "G In which case if A$ > B$ then do, This would enable easy sorting, and other string functions. I would hope, but do not expect that you will implement these new routines. Hopefully, they may be of general interest. Sincerely, ABACUS Computing Limited 1401 West Broadway, Vancouver, B.C. V6H 1H6 Donald A. (Sandy) Lyall Systems Analyst, CDP 8 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS Implementing a resource chargeback system on VMS by Greg Hubbard Brown & Root, Inc. P. O. Box 3 Houston, Texas 77001 Introduction. In Brown & Root, computer resource accounting is a very important issue. The shop is composed primarily of IBM-style mainframes which support user groups in worldwide offices. An extensive resource accounting system is available on these machines, and a portion of Brown & Root revenues for both engineering and construction work comes from data processing services. When the first VAX computers were purchased to supplement the IBM mainframes, a chargeback scheme similar to the mainframe billing system was required. In particular, the chargeback system needed had to provide separate detail items reflecting the resources used by each batch and interactive session, along with the user-supplied charge numbers associated with each session. This information was necessary for compatability with the corporate mainframe computer billing system. This article will discuss the implementation of such a chargeback system on the VAX/VMS systems at Brown & Root. Items discussed will include the accounting features available with VMS, and the obstacles which must be overcome in order to implement a chargeback system. The Brown & Root chargeback system will be briefly described, and some suggestions will be made regarding VMS improvements for enhancing its chargeback abilities. 9 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS VMS accounting features. VMS accounting file. VMS systems provide some accounting features, the most important of these being the fact that VMS keeps extensive records of system activity if accounting is enabled. Records are written to the VMS accounting file when a process or subprocess is deleted, a print job is completed, or an image is deleted. In addition, system initialization information, user-supplied data records, and file linking records may also be found in the accounting file. The VAX system manager may control which records are present in the VMS accounting file by issuing the proper SET ACCOUNTING DCL command. ACCOUNT field. The system User Authorization File (UAF) contains an eight byte field called ACCOUNT which may be defined or modified by the system manager by running the AUTHORIZE utility. This field is copied into the process header of processes which log in through the UAF, and is part of the ACR$K_ID portion of any accounting records which are written to the accounting file on the behalf of a process. There is (through VMS 3.4) no provision for modifying this ACCOUNT field with DEC software once a process has been created. In fact, using the $GETJPI system service to fetch the ACCOUNT field for a process will return the value which is stored in the UAF, not the value in the process header, almost as if DEC does not expect this value to be dynamic. ACCOUNTING utility. The nicest of the VMS accounting features is the ACCOUNTING utility which arrived with VMS 3.0. This utility allows many different types of operations to be performed with the standard VMS accounting file, allowing the system manager to generate ad hoc reports on system usage quickly and easily. ACCOUNTING can be used to filter the accounting file, sort the file, copy it, and also to generate system resource usage summaries over time in various formats. 10 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS Obstacles to implementing a chargeback system. Unfortunately, the VMS accounting features are not adequate for implementing the type of chargeback system which may be used to bill users directly for a VAX session. This type of billing often requires one record for each VAX session and a way to associate charging information with the record. A session, of course, is either an interactive session or a batch job. The information necessary for charging includes not only the information about the resources used by that job, but also the resources used by any subprocesses which are created by the main process plus the resources used in any printing. VMS tracks all of this information, but does not supply any means of condensing the information into a single record except through the ACCOUNTING utility, and then only by the production of an ASCII report file! Problems with the ACCOUNT field. The ACCOUNT field appears to be intended for storing charge numbers, but most data processing charging methods bind charge numbers to computer runs, not to the person making the run. This is especially true in engineering firms where an engineer or other employee may be working on more than one project at a time. In this case, it is desirable that each session be associated the charging information applicable to the appropriate project. The ACCOUNT field is too cumbersome to change in this fashion in standard VMS because it must be modifed by either running AUTHORIZE or by using user-written kernel mode software. The ACCOUNT field may only store eight characters of information, which is probably not long enough for the account identification information used by many organizations. Brown & Root's required charging information for computer usage contains at least eleven characters, and can contain as many as 24 characters. Fortunately, DEC allows user software to place a data record containing as many as 255 characters of information in the accounting file with the $SNDACC system service. A clearly obvious solution to the charging information storage problem is to run a program during the system login procedure which retrieves charging information from the user, validates it, formats it properly, and then sends it to the VMS accounting file with a call to the $SNDACC system service. This program may also enforce the collection of this information by terminating any process which does not supply the proper information. 11 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS Problems with accounting file condensation. The search for a sort key. Another problem involves the condensation of the VMS accounting file into the "one session, one record" format required by the billing software. Once again, it is obvious that a program may be written to do this condensation, but the condensation process is not entirely straightforward. The VMS accounting file contains different types of records for process terminations, print job terminations, and subprocess terminations which are written to the accounting file when the appropriate event occurs. The condensation process becomes much easier if there is some unique per-process identifying information available in the accounting records which will allow the accounting file to be sorted using this unique information as a sort key, forcing all of the records for a particular session to be grouped together. If this is possible, then the condensation process becomes a mere transaction processing exercise and not such a nightmare. A possible candidate -- the process ID. One possible candidate for a unique identifier for sorting is the process identifier (PID). The PID is a longword which is used by VMS for uniquely identifying a process in the system. It consists of a two byte process slot number and a two byte sequence number which is incremented every time a new process occupies the slot. The PID is present in every accounting record generated by a process. Why the PID will not solve the problem. PID generation starts over when the system is bootstrapped because all of the sequence counters are reset to zero. This, coupled with the fact that the accounting file remains in use until explicitly closed with a SET ACCOUNTING/NEW_FILE command means that PIDs are generally NOT unique within the accounting files of systems bootstrapped between accounting file closures. If long periods of time elapse between accounting file closures and particular process slots are heavily used, it becomes possible that some of the PIDs for those particular slots will 12 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS "wrap around" when their counters roll over to zero again, once again causing nonunique PIDs to be present in the accounting file. A possible workaround is to sort on PID and username, but then subprocesses become a problem. Subprocesses receive their own PID, and the PID of their owner process is stored in a different field in their accounting file record. Now that the SPAWN command is available to easily generate them, subprocesses have become very common and can represent significant usage of system resources. If PIDs are known to be nonunique, it may be difficult to match a process in the accounting file with its subprocesses without having to resort to careful examination of the login times and logout times for all of the processes and subprocesses in the accounting file. A solution -- use the ACCOUNT field A solution to the condensation problem is writing a unique number into the process ACCOUNT field which is guaranteed to be unaffected by both bootstrapping and system load. This is possible because the value present the ACCOUNT field portion of the process header of any process will be copied to the ACCOUNT field of all accounting records for that process. In addition, the ACCOUNT field in the process header is copied to all subprocesses created by the process. Sorting the accounting file by the new ACCOUNT field makes all of the records which are to be condensed end up grouped contiguously in the file. Many different generation schemes for this unique ACCOUNT value are possible, but the most reliable methods are based upon the system time. The Brown & Root scheme generates a six byte sequence of printable characters from the current time of year. This value has a resolution of 10 milliseconds, virtually guaranteeing that it will be unique, even for processes which attempt to log in simultaneously. This sequence is concatenated with a sequence byte (a hook which allows other software to enable a user to change his charging information without having to log out first) and a check byte which allows determination of whether or not the process which generated the accounting record went through the accounting system's login program. The only drawback to modifying the ACCOUNT field is that it must be done in kernel mode, making security of the login program rather important. 13 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS Problems in reading the VMS accounting file. The final obstruction to a viable chargeback system is the format of the current VMS accounting file. In VMS version 2, the file consisted of six different kinds of records, all with their own particular fixed lengths and offsets. VMS 3.0 changed all of that by instituting a packed, variable length record format which conserves disk space, but makes the file very difficult to process in FORTRAN, and even more difficult to handle in COBOL. Since many commercial environments are not likely to possess the languages more suited to the processing of this file (PASCAL, C, PL/I, or BLISS), this is indeed unfortunate. All VAX systems have MACRO, so a solution to this problem is a MACRO program which reads the accounting file and reformats it. This reformatting involves expanding the variable length fields in the various records into fixed length formats, as well as the addition of fixed header information which helps facilitate sorting. The Brown & Root chargeback system. Utilizing the methods described above, a chargeback system was successfully developed. The total VAX accounting system is divided into three phases. The first phase is the login phase and deals with collecting the charging information and storing it in the VMS accounting file. The second phase concerns itself with the condensation of the VMS accounting file into a form which is then added to a master billing file. The third phase, of course, processes the master billing file in order to produce billing reports, system usage reports, and the like. Login phase. The login phase utilizes several programs, the first of which is called ACCLOGIN. ACCLOGIN modifies the ACCOUNT field for the process before it asks for charging information. The routine which modifies the ACCOUNT field checks to see if it has already been modified, preventing clever users from running the login program on their own, overwriting their ACCOUNT field, and thus circumventing the system. After modifying the ACCOUNT value, the program determines whether the process is batch or interactive. If interactive, the user is prompted for the required information. If the process is batch, the runtime library routine LIB$GET_COMMAND is used to acquire the first 14 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS record in the batch stream. This record is then checked for the presence of the proper charging information. The information is validated after it has been acquired. Depending upon the success or failure of the validation, the information is either written to the accounting file or the process is logged out. The charge numbers are next stored in process logical names so that DCL and applications software may access the information throughout the remainder of the session. In addition to ACCLOGIN, a program called NEWACC is used when a user wishes to change his charging information without having to log out and then log back in. This program validates the new information, and then sends a record to the VMS accounting file which contains all of the available values for the resources used up to that point by the process. In addition, the sequence byte of the ACCOUNT field is incremented, allowing the total session to be reconstructed later if necessary. Since VMS does not write out process resource usage statistics to the accounting file until the process is deleted, merely adding a new charge number data record and then changing the ACCOUNT field will cause the previous charge number record to become "orphaned." By writing out process statistics at the time that the charging information is changed the condensation program is able to split the total usages for the process among the various charge numbers. NEWACC allows the user to modify his charge information up to 64 times per session. This limitation is due to a requirement that the sequence byte in the ACCOUNT field be printable in order to maintain compatability with the rest of the ACCOUNT field. A third program, RCU3, is used to display for the user his current resource utilizations, both in raw form and the charging units used in the corporate computer billing system (RCU stands for Resource Charge Units; the 3 is for version 3 of VMS). This program is run as part of the user's logout procedure, and allows him to see his computer usage charge as he uses the computer. The heart of the program is a call to the $GETJPI system service. The system manager may run RCU3 and see the resource charges for other processes in the system by supplying the program with the PID of the process desired. 15 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS Accounting file processing phase. The second phase also involves three different programs and is run daily by a scheduling process. The first part of the procedure is to start a new accounting file and add the old one to a monthly file. The file to be processed is then processed by REFMTACC, the MACRO program described previously. In addition to reformatting the VMS accounting file, REFMTACC filters out any records which are not relevant to the rest of the system. The records which are passed to the rest of the system include user data records, process termination records, and print job termination records. A program DUMPR is available for the production of a formatted listing of the reformatted records; this is used primarily as a debugging tool. The actual condensation of the reformatted file begins with a file sort upon the ACCOUNT field, found in the header information of each record generated by the REFMTACC program. After the sort, the program ACCMERGE is used to merge any leftover records from previous accounting runs into the file. After the merge step, the file is again sorted and then it is processed by the condensation program ACCMAIN3. ACCMAIN3 generates the records which are added to the billing file, and also checks for errors. Any errors are reported, and the associated records are saved for possible salvage. As mentioned previously, this entire process is done automatically. The billing and reporting phase The master billing file is processed by a host of different programs, most of which are of no particular interest to anyone other than the responsible Brown & Root personnel. One highlight of this phase of the billing system should be mentioned. It is the ACCEXTRCT program, modeled after the VMS ACCOUNTING utility. ACCEXTRCT provides the ability to extract records from the billing file based upon login times, username, terminal name or batch queue, charging information, charging information type (i.e. reimbursable or overhead), and process type (interactive or batch). The extraction criteria may be entered on either the command line or in a criteria file. The criteria used for the extraction are written to the output file so that the billing programs know what they are reporting. In addition, ACCEXTRCT supports sorting of the output file on up to ten different items in any arbitrary order, whether ascending or descending. This capability shifts the load of record selection and sorting in the billing system to one program. Ad hoc billing or resource usage reports are possible by creating an arbitrary collection of records with ACCEXTRCT and printing them 16 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS with a generalized report writer. Responding to VMS changes. Any VAX billing system must be able to respond to changes in the VMS operating system if it is to prove effective for any length of time. DEC reserves the right to improve VMS, so the inclusion of the possibility of change in the design of a chargeback system will save a lot of future grief. Changes in the VMS accounting file format. DEC boldly reserves the right to change the format of the accounting file in any future release of VMS. Although the presence of the ACCOUNTING utilty should make substantial changes in the accounting file format less attractive to DEC and thus less likely, all dependence upon the physical VMS file format has been isolated entirely to the REFMTACC program. Should the VMS format change, rewriting REFMTACC will restore the proper functioning of the system. When DEC made the switch from the version 2 format to the version 3 format, a conversion program was provided so that version 2 dependent software would continue to function. DEC is likely to provide such a utility in the future if major changes are made to accounting file format. Changes in the interpretation or implementation of the ACCOUNT field. Should VMS support arbitrary changing of the ACCOUNT field for a process, the system will suffer tremendously. It is hoped that if DEC decides to support this feature, they will make it optional by requiring some sort of privilege like the SET UIC command requires in present day VMS systems. Otherwise, the processing scheme for the accounting file will have to be revised extensively. This threat is the largest weakness in the Brown & Root chargeback system. It is strongly hoped that the ACCOUNT field feature is not implemented unless it is done according to the methods suggested in the next section. 17 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS Suggestions for VMS improvements for accounting purposes. Should the VMS designers choose to modify the accounting features in the operating system, some of the following changes would be useful, and would make most of this chargeback system unnecessary. The following paragraphs describe some of these suggestions. Fully support the ACCOUNT field. The ACCOUNT field will become very useful if the following changes are made: 1. Make the ACCOUNT field longer. A maximum length of 80 characters should prove to be sufficient. The extra space required in the process header for storing the added characters should not be a big problem on a machine with the address space of a VAX system. 2. Support the ACCOUNT field for batch processes by adding a qualifier to the SUBMIT command (e.g. SUBMIT/ACCOUNT=). If this qualifier is not supplied, set the batch job's ACCOUNT field to either the value in the UAF or to the value in the header of the interactive process which submits the job. Support the ACCOUNT field for interactive processes by adding a prompt to the login sequence. Allow the system manager to allow or disallow null responses to the ACCOUNT prompt. 3. Make the ACCOUNT field which is currently active available to customer software through either $GETJPI or a runtime library routine. Allow suitably privileged software to modify the ACCOUNT field via a system service, say $SETACC, with CMKRNL privilege required for usage. 4. Finally, if any change is made to the ACCOUNT value, dump the process statistics to the accounting file and reset the various process resource usage counters. This is necessary so the resources used by the process may be correctly apportioned among the different accounts. 18 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS Enhance the ACCOUNTING utility. Give ACCOUNTING the capability to condense the information in the VMS accounting file into a "single job, single record" format which includes the fields specified by the user of the utility as well as any user data records. The record schema for this file could be specified via DATATRIEVE or DML definitions, and stored in the data dictionary. The condensed file should be available in either ASCII or binary format. If this capability is not possible, add a field to the process accounting records which is both unique to that process' records throughout the accounting file and able to be used as a sort key. It is essential that this unique key is located in the same place in every record, otherwise sorting will be unnecessarily difficult. Other suggested improvements. Finish implementing all of the fields documented in the current accounting file, and make the statistics which are reported in the file truly reflect their purpose. One historical problem with the accuracy of the reported information involves print records; the reported pages printed value is a calculated value, not a true count, and no way of retrieving an accurate count of lines printed is available. Perhaps this will be "fixed in a future major release of VMS." Also, add a hook to the LOGOUT and LOGOFF commands which allows customer software to report the process resource usage statistics in terms of whatever charging units the customer uses at the time the process logs out. Conclusion. In conclusion, the resource accounting features of VMS are not yet entirely adequate for the successful implementation of resource billing systems. The problems which must be addressed in a billing sytem include the condensation of the VMS accounting file into a "one session, one record" format, as well as a method for associating user-supplied charging information with the session. These problems may be solved by setting the ACCOUNT field of the process header to a unique value and by storing the charging information in user data records in the VMS accounting file. When a billing system is designed, some thought should be accorded to the impact which possible VMS 19 PAGESWAPPER - February 1984 - Volume 5 Number 8 Implementing a resource chargeback system on VMS changes would have on the system. Particular changes to be considered include possible changes in the physical format of the VMS accounting file and the possibility that VMS will allow processes to set their ACCOUNT fields to arbitrary values. Though it is possible to produce a viable billing system for VAX computers under the current generation of VMS, the operating system could be improved in several different ways in order to assist the resource usage billing process. The VAX Systems SIG Symposium Tape for Fall 1983 (Las Vegas) by Joe Bingham, VAX Systems SIG Librarian FREE SOFTWARE!! Free software that works and is documented?? Well, I can't promise that, but I can say that most of it that I have tried works, and that the documentation is usually adequate and frequently outstanding. I am referring, of course, to the VAX Systems SIG Symposium Tapes put together from submissions to the DECUS Tapecopy project, specifically the tape put together from submissions made at the DECUS Symposium held in Las Vegas October 24 through 28. For the tenth consecutive Symposium, the VAX Systems SIG has issued a symposium tape. Since Fall 1981, the SIG has also been responsible for distributing them, using a tree distribution scheme of interested DECUS members, primarily Local User Group (LUG) Librarians. If you are new to the VAX community, you may want to get some of the older tapes. There is an incredible amount of material there, so finding something, especially finding the best version of it, is no easy task. If you have something specific in mind, the index in [VAX000.INDEX] on all of the more recent tapes is a big help. Many submissions wind up being resubmitted with improvements by the original author or someone else, so it is wise to start with the latest tape. Here is what you need to be completely up to date with the SIG tapes: o The composite Spring 1979 through Spring 1982 tape, which is available from nodes in the distribution tree. This tape has been submitted to the DECUS Program Library but as of this writing they have not assigned an order number for it. (The composite tape is somewhat smaller than the total of the five individual tapes, since some material which was resubmitted to 20 PAGESWAPPER - February 1984 - Volume 5 Number 8 The VAX Systems SIG Symposium Tape for Fall 1983 (Las Vegas) subsequent tapes through Fall 1982 is not on it.) o The Fall 1982 (Anaheim) tape, available from the tree or from the DECUS Program Library. The Library order number is V-SP-15. (one 2400-foot tape) o The Spring 1983 (St. Louis) tape, available from the tree or from the Library. The Library order number is V-SP-17. (two 2400-foot tapes) o The Fall 1983 (Las Vegas) tape which was injected into the top of the tree and subimitted to the Library in December 1983. (two 2400-foot tapes) Contributions of original, useful, working, documented software are needed to continue to make the SIG Tape project worthwhile for all concerned. Contributions of rehashed, marginally-useful, buggy, undocumented software will be accepted. Please at least include some indication of what it is supposed to do and known problems. Contributions of material identical to previously submitted material (if it adds to the size of the tape but not its usefulness) are not welcome. If you submit something which depends on material which has been on earlier tapes for its operation, use your own judgement as to whether to include the old material or not, taking into consideration its size and probable availability to the people who will be interested in your submission. Submissions to the SIG tape should be turned in at the Library Booth at a DECUS symposium. Your tape will be copied and returned later in the week. If you cannot go to the symposium, send your tape with someone else but be sure to send a signed tapecopy release form (available from the preliminary symposium schedule). You may also submit your program to the DECUS library at the same time. Please read relevant information on [VAX000] before making up your submission. The Las Vegas tape is smaller than the St. Louis tape, but is still large at 73,500 blocks plus 11,500 blocks of index, etc. on [VAX000]. The tape is again too large for a single tape - one tape will contain [VAX000] and about two thirds of the submitted material in a directory structure called [VAX83C], the other will contain a duplicate copy of [VAX000] and the remainder of the submitted material in [VAX83D]. When I started to put the Las Vegas tape together, I thought there might be a chance of getting it down to one tape so I deleted some of the .EXE, .OBJ and .MEM files which can easily be regenerated. I also compressed some of the libraries and got rid of some duplicate files. You should not have any trouble regenerating those files if you need them but you may find cases where the contributor's readme file refers to files which are not included on the tape. 21 PAGESWAPPER - February 1984 - Volume 5 Number 8 The VAX Systems SIG Symposium Tape for Fall 1983 (Las Vegas) This is an outstanding tape with resubmissions of LBLTOOLS, KERMIT, the VAX Professional Workstation, Dension University's spelling and grammar checker, VAXNET and ICE (to mention a few), many games, and many other interesting and useful programs. Some of the games have appeared on previous tapes but this looks like a good selection and includes procedures to control access to them. The distribution tree for the Fall 1983 tape follows this article. To get the Fall 1983 tape, contact one of the nodes near you and arrange to exchange tapes with him or borrow his copy of the tape. If there is no node from which you can conveniently obtain the SIG tapes, you may want to establish one. I will be happy to put you on the next tree if you: o Represent a LUG which is not already on the tree, and o Have the capability and are willing to make copies of the tapes for other VAX users. This means either a machine with at least two tape drives for tape-to-tape copying or a VAX with a lot of spare disk space for tape-to-disk-to-tape copying. If you do not meet these criteria, please do not ask to be put on the tree. If you have been on past trees but are missing from this one, one or more of the following apply: o You did not return the node verification/distribution progress form I sent all nodes last July. (Nodes on the Fall 1983 tree please note: I am using the same scheme again to try to verify your continued interest in being a node on the tree. When I modified the form for the Fall of 1983, I unfortunately failed to change every reference to the Spring 1983 tape to the Fall 1983 tape. Please do not be confused. The form I sent you in early December 1983 is intended to ask about receipt of the Fall 1983 tape and verify your interest and pertinent information for the Spring 1984 tree.) o Your DECUS LUG license has expired. o Your LUG did not return the form in Suggestions requesting a copy of the VAX tape. (These are passed to me but I prefer to get my verification form back.) CHANGES COMING IN THE DISTRIBUTION SCHEME. The National LUG organization thinks that they can do a better job of distributing the SIG tapes than the individual SIG's can and they want to take over the task. The current plan is that they 22 PAGESWAPPER - February 1984 - Volume 5 Number 8 The VAX Systems SIG Symposium Tape for Fall 1983 (Las Vegas) will handle the distribution to the Northeast Region of all of the SIG tapes which come out of the Cincinnati symposium to see how it goes. It seems to me that there is general agreement that the tree distribution scheme has been working well and I hate to see us violate the old adage about not fixing it if it ain't broke. If you agree that we should keep the tree distribution scheme, especially if you are one of the guinea pigs in the Northeast Region, it would be beneficial to make your voice heard in DECUS and the DECUS Library and the LUG organization. I would also like to hear your opinions - I do not get a lot of user-level feedback as to how the tape distribution is going. Joe Bingham VAX Systems SIG Librarian ManTech International Corporation 2320 Mill Road Alexandria, VA 22314 (703) 838 5600 23 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution Fall 1983 VAX Systems SIG Tape Distribution JOE BINGHAM MANTECH INTERNATIONAL 2320 MILL ROAD ALEXANDIRA VA 22314 (703) 838 5600 1 1___ PAM SARMANIAN 1 DECUS US 1 ONE IRON WAY 1 MAIL STOP MR2-1/C11 1 MARLBORO, MA 01752 1 (617) 467 4178 1 (DECUS FOR LIBRARY) 1 1___ OZAN YIGIT 1 YORK UNIVERSITY 1 DEPT OF COMPUTER SCIENCE 1 4700 KEELE ST 1 DOWNSVIEW, ONT M3J 1P3 1 (416) 667 6308 1 (CANADIAN DISTRIBUTION) 1 1___ GLENN C EVERHART 1 RCA 1 ROUTE 38 1 CHERRY HILL, NJ 08358 1 (609) 338 6022 1 (RSX SIG) 1 1___ ALAN ZIRKLE 1 NAVAL SURFACE WEAPONS CENTER 1 CODE K105 1 DAHLGREN, VA 22448 1 (703) 663 7815 1 WASHINGTON DC AREA VAX LUG 1 ) 1 )___ TOM SHINAL 1 ) GENERAL SCIENTIFIC CORP 1 ) 1684 EAST GUDE 1 ) ROCKVILLE, MD 20850 1 ) NAT CAPITAL AREA RT-11 LUG 1 ) 1 )___ FRED RYBCZYNSKI 1 ) COMMANDER, USAMRICD 1 ) BUILDING E3100 1 ) ABERDEEN PROVING GR, MD 21010 1 ) (301) 671 4582 1 ) APG LUG 1 ) 1 ) 24 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 ) 1 ) 1 ) 1 ) 25 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 )___ RICK POWELL 1 ) US ARMY DAAG-ID 1 ) ROOM 1156 1 ) 2461 EISENHOWER AVE 1 ) ALEXANDRIA, VA 22331 1 ) (703) 325 6157 1 ) WASH DEFENSE COMMUNITY LUG 1 ) 1 )___ BUZ BROWN 1 ACADEMIC COMPUTING EAST 1 MEDICAL COLLEGE OF VIRGINIA 1 BOX 16, MCV STATION 1 RICHMOND, VA 23298 1 CENTRAL VIRGINIA LUG 1 1___ DAVE SCHMIDT 1 MANAGEMENT SCIENCE ASSOCIATES 1 5100 CENTER AVENUE 1 PITTSBURGH, PA 15232 1 (412) 683 9533 1 THREE RIVERS VAX LUG 1 / 1 /___ WENDY S KOENIG 1 / STRATEGIC INFORMATION 1 / 80 BLANCHARD STREET 1 / BURLINGTON, MA 01803 1 / (617) 273 5500 1 / \ 1 / \___ KEN A L COAR 1 / \ ENGINEERING COMPUTER STATION 1 / \ 100 ENGINEERING EAST 1 / \ UNIVERSITY OF MASSACHUSETTS 1 / \ AMHERST, MA 01003 1 / \ (413) 545 1580 1 / \ PIONEER VALLEY VAX LUG 1 / \ 1 / \___ GERALD McGAFFREY 1 / \ MIT LINCOLN LABORATORY 1 / \ RM C-391 1 / \ LEXINGTON MA 02173 1 / \ 863-5500 X3532 1 / \ MIT/LL LUG 1 / \ 1 / \___ THOMAS VIANA 1 / \ NAVAL UNDERWATER SYSTEMS CTR 1 / \ CODE 3511 1 / \ BLDG 1711-1 1 / \ NEWPORT, RI 02841 1 / \ (401) 841 2648 1 / \ NAVAL UNDERWATER SYS CTR LUG 1 / \ 1 / \ 1 / \ 1 / \ 26 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 / \___ STEVE LADD 1 / \ TSC INC 1 / \ BOX 683 1 / \ HANOVER NH 03755 1 / \ (603) 448 3838 X159 1 / \ UPPER VALLEY PDP-11 LUG 1 / \ 1 / \___ JOHN N GUIDI 1 / \ JACKSON LABORATORY 1 / \ COMPUTING SERVICE CENTER 1 / \ OTTER CREEK RD 1 / \ BAR HARBOR, ME 04609 1 / \ (207) 288 3371 X391 1 / \ MAINE LUG 1 / \ 1 / \___ DOUGLAS BICKFORD 1 / UNIVERSITY OF VERMONT 1 / ACADEMIC COMPUTING CENTER 1 / COOK SCIENCE BUILDING 1 / BURLINGTON, VT 05405 1 / (802) 656 3190 1 / VERMONT INSTALL AND ASSC LUG 1 / 1 /___ JOHN HASSTEDT 1 / PHYSICS DEPARTMENT 1 / SUNY 1 / STONY BROOK, NY 11794 1 / (516) 246 7110 1 / LI LUG 1 / ; 1 / ;___ DONALD ELLIS MERUSI 1 / ; PRATT & WHITNEY AIRCRAFT 1 / ; 400 MAIN ST. 161-05 1 / ; E. HARTFORD, CT 06108 1 / ; (203) 565 3970 1 / ; CONNECTICUT VALLEY LUG 1 / ; 1 / ;___ DONALD E STERN, JR 1 / ; WARNER LAMBERT CO 1 / ; 10 WEBSTER RD 1 / ; MILFORD, CT 06460 1 / ; (203) 878 9351 X302 1 / ; S CONNECTICUT LUG 1 / ; 1 / ;___ BOHDAN SEREDA 1 / ; AT&T INFORMATION SYSTEMS 1 / ; LZ ID-212 1 / ; 307 MIDDLETOWN LINCROFT ROAD 1 / ; LINCROFT, NJ 07738 1 / ; (201) 576 2375 1 / ; HOLMDEL VAX LUG 1 / ; 1 / ; 1 / ; 27 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 / ;___ C A IANNIELLO 1 / ; MOBIL OIL CORP/TOXICOLOGY DIV 1 / ; PO BOX 1029 1 / ; PRINCETON, NJ 08540 1 / ; (609) 452 9440 X25 1 / ; PDP-11/VAX SEABOARD LUG 1 / ; 1 / ;___ RICHARD GARLAND 1 / COLUMBIA UNIV, CHEMISTRY DEPT 1 / BOX 351, HAVEMEYER HALL 1 / NEW YORK, NY 10027 1 / (212) 280 3183 1 / NY METRO LUG 1 / 1 /___ RICHARD MARISA 1 / UNIV OF ROCHESTER 1 / PRODUCTION AUTOMATION PROJ 1 / RIVER CAMPUS 1 / ROCHESTER NY 14627 1 / (716) 275 5342 1 / I 1 / I___ PAUL KESSLER 1 / I AMD 1 / I BUILDING 515 1 / I BROOKHAVEN NATIONAL LAB 1 / I UPTON NY 11973 1 / I (516) 282 4156 1 / I UPTON LUG 1 / I 1 / I___ GLEN E GUY 1 / I GENERAL ELECTRIC CO 1 / I CS5-Z3 1 / I PO BOX 4840 1 / I SYRACUSE, NY 13027 1 / I (315) 456 1728 1 / I CNY LUG 1 / I 1 / I___ EDWARD F BEADEL JR 1 / I CAUSE INSTRUCTIONAL COMP CTR 1 / I SUNY - OSWEGO 1 / I OSWEGO NY 13126 1 / I (315) 341 3055 1 / I LAKESHORE LUG 1 / I 1 / I___ DENNIS P COSTELLO 1 / I CORNELL UHIVERSITY 1 / I NATIONAL SUBMICRON FACILITY 1 / I G-02 KNIGHT LAB 1 / I ITHACA NY 14853 1 / I (607) 256 2329 1 / I ITHACA MINICOMPUTER LUG 1 / I 1 / I 1 / I 28 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 / I___ JOHN F STITZINGER 1 / I HRB SINGER 1 / I PO BOX 60 1 / I 300 SCIENCE PARK ROAD 1 / I STATE COLLEGE PA 16801 1 / I (814) 238 4311 1 / I 1 / I___ THOMAS W BURTNETT 1 / DICKINSON COLLEGE 1 / COMPUTER CENTER 1 / CARLISLE PA 17013 1 / (717) 245 1256 1 / EASTERN PA RSTS LUG 1 / 1 /___ JANET E ANDERSON 1 / ROCKWELL INTERNATIONAL 1 / 800 EASTOWNE DRIVE 1 / SUITE 200 1 / CHAPEL HILL NC 27514 1 / (919) 493 2471 1 / RESEARCH TRIANGLE LUG 1 / i 1 / i___ ERIC BLOOM 1 / i F101 1 / i SMITH KLINE AND FRENCH LABS 1 / i 1500 SPRING GARDEN STREET 1 / i PHILADELPHIA PA 19101 1 / i (215) 751 3494 1 / i MID ATLANTIC VAX LUG 1 / i 1 / i___ R E GRANDLE 1 / i NASA 1 / i NASA LANGLEY RES CTR 1 / i MAIL STOP 461 1 / i HAMPTON VA 23365 1 / i (804) 865 2645 1 / i TIDEWATER LUG 1 / i 1 / i___ RONALD H KLAUSEWITZ 1 / i WEST VIRGINIA WESLEYAN COLLEGE 1 / i 59 COLLEGE AVE 1 / i BUCKHANNON WV 26201 1 / i (304) 473 8008 1 / i WEST VIRGINIA PDP-11 LUG 1 / i 1 / i___ DAN W OLDS 1 / i WOFFORD COLLEGE 1 / i SPARTENBURG, SC 29301 1 / i (803) 585 4821 1 / i CAROLINAS LUG 1 / i 1 / i 1 / i 1 / i 29 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 / i___ TRINA S JACKSON 1 / ATLANTA REGIONAL COMMISSION 1 / 100 EDGEWOOD AVE NE 1 / ATLANTA, GA 30225 1 / (404) 656 7730 1 / ATLANTA LUG 1 / 1 /___ FRANK BUSH 1 D W MATTESON COMPUTER CENTER 1 TENNESSEE TECHNOLOGICAL UNIV 1 BOX 5071, CLEMENT HALL RM 220 1 COOKEVILLE, TN 38505 1 (615) 528 3387 1 TENNESSEE LUG 1 ( 1 (___ WILLIAM F LAKE 1 ( AD/KRESS 1 ( BLDG 380, ROOM 234 1 ( EGLIN AFB FL 32542 1 ( (904) 882 5818 1 ( FPU LUG 1 ( 1 (___ ARTHUR SMITH 1 ( UNIVERSITY OF FLORIDA 1 ( DEPT OF STATISTICS 1 ( 219 ROLFS HALL 1 ( GAINESVILLE, FL 32611 1 ( GATOR LUG 1 ( 1 (___ JOSEPH M HILLEBRANDT 1 ( FACILITIES MGT SER 1 ( ORLANDO, FL 32801 1 ( (305) 422 5880 1 ( CENTRAL FLORIDA LUG 1 ( 1 (___ MICHAEL NEWELL 1 ( FLORIDA INSTITUTE OF TECHNOL 1 ( ACADEMIC COMPUTER SERVICES 1 ( 150 WEST UNIVERSITY BLVD 1 ( MELBOURNE, FL 32901 1 ( (305) 723 3701 X212 1 ( FLORIDA VAX/PDP LUG 1 ( 1 (___ DAVID STANFSKI 1 ( TRT TELECOMMUNICATIONS CORP 1 ( PO BOX 8876 1 ( FORT LAUDERDALE, FL 33310 1 ( (305) 792 5100 1 ( TRI COUNTY LUG 1 ( 1 ( 1 ( 1 ( 1 ( 30 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 (___ MARK PAULK 1 SYSTEM DEVELOPMENT CORPORATION 1 4810 BRADFORD BLVD N W 1 HUNTSVILLE AL 35805 1 (205) 837 7610 X210 1 NORTH ALABAMA LUG 1 1___ GARY GREBUS 1 BATTELLE MEMORIAL INSTITUTE 1 505 KING AVE 1 COLUMBUS OH 43201 1 (614) 424 7156 1 ) 1 )___ JACK D CUNDIFF 1 ) MUSKINGUM COLLEGE 1 ) NEW CONCORD OH 43762 1 ) (614) 826 8151 OR 8493 1 ) CENTRAL OHIO LUG 1 ) | 1 ) |___ ROBERT WAYNE HAYES 1 ) | UNION CARBIDE CORP 1 ) | P O BOX X 1 ) | BUILDING 3500 1 ) | OAK RIDGE TN 37830 1 ) | (615) 574 5726 1 ) | EASTERN TENNESSEE PDP-11 LUG 1 ) | 1 ) |___ JERRY ETHINGTON 1 ) | FEDERAL LAND BANK 1 ) | PO BOX 32390 1 ) | LOUISVILLE, KY 40232 1 ) | (502) 556 7187 1 ) | KENTUCKY PDP-11 LUG 1 ) | 1 ) |___ JOHN S TOMS 1 ) | ALLEN-BRADLEY CO 1 ) | 747 ALPHA DRIVE 1 ) | HIGHLAND HTS OH 44143 1 ) | (216) 449 6700 X3979 1 ) | OHIO VAX LUG 1 ) | 1 ) |___ RONALD J FERGUSON 1 ) | XAVIER UNIVERSITY 1 ) | 3800 VICTORY PARKWAY 1 ) | CINCINNATI, OH 45207 1 ) | (513) 754 3111 1 ) | TRI-STATE LUG 1 ) | 1 ) | 1 ) | 1 ) | 1 ) | 1 ) | 1 ) | 31 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 ) |___ JAMES E BARNES 1 ) AFWL/AAAN-2 1 ) WRIGHT PATTERSON AFB, OH 45433 1 ) (513) 255 6843 1 ) DAYTON LUG 1 ) 1 )___ STEVE BURNS 1 ) EATON CORPORATION 1 ) 9475 CENTER ROAD 1 ) FENTON, MI 48430 1 ) (313) 629 5361 1 ) ! 1 ) !___ BRUCE DANNER 1 ) ! ROSE-HULMAN INST 1 ) ! 5500 WABASH 1 ) ! TERRE HAUTE, IN 47803 1 ) ! (812) 877 1511 1 ) ! RSTS USERS OF INDIANA (RUIN) 1 ) ! 1 ) !___ TIM GARDNER 1 ) ! AG DATA NETWORK 1 ) ! SMITH 105 1 ) ! PURDUE UNIVERSITY 1 ) ! W LAFAYETTE, IN 47907 1 ) ! (317) 494 8333 1 ) ! CENTRAL INDIANA LUG 1 ) ! 1 ) !___ JAMES DOWNWARD 1 ) ! KMS FUSION 1 ) ! 3941 RESEARCH PARK DRIVE 1 ) ! P O BOX 1567 1 ) ! ANN ARBOR MI 48106 1 ) ! (313) 769 8500 X362 1 ) ! SEM LUG 1 ) ! 1 ) !___ ROBERT DYKSTRA 1 ) ! LEAR SIEGLER INC 1 ) ! INSTRUMENT DIVISION 1 ) ! 4141 EASTERN AVE SE 1 ) ! GRAND RAPIDS, MI 49508 1 ) ! (616) 241 7970 1 ) ! WEST MICHIGAN LUG 1 ) ! 1 ) !___ JIM FLATTEN 1 ) ! IOWA STATE UNIVERSITY 1 ) ! METALLURGY 304 1 ) ! AMES LABORATORY USDOE 1 ) ! AMES IA 50011 1 ) ! (515) 294 4823 1 ) ! SKUNK LUG 1 ) ! 1 ) ! 1 ) ! 1 ) ! 32 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 ) !___ BOB STREEPER 1 ) CEDAR RAPIDS GAZETTE 1 ) THIRD AVE AND FIFTH STREET SE 1 ) CEDAR RAPIDS, IA 52401 1 ) (319) 398 8275 1 ) BI-STATE LUG 1 ) 1 )___ GARY BREUCKMAN 1 ) COMPUTER SERVICES DIVISION 1 ) MARQUETTE UNIVERSITY 1 ) 517 N 14 ST 1 ) MILWAUKEE WI 53233 1 ) (414) 224 7395 1 ) MILWAUKEE LUG 1 ) * 1 ) *___ MICHAEL HAMIN 1 ) * A O SMITH DATA SYSTEMS 1 ) * 8901 NORTH KILDEER COURT 1 ) * BROWN DEER, WI 53209 1 ) * (414) 357 2772 1 ) * SOUTH EAST WISCONSON LUG 1 ) * 1 ) *___ TOM MOOG 1 ) * UNIVERSITY OF WISCONSIN 1 ) * PHYSICAL SCIENCES LABORATORY 1 ) * 3725 SCHNEIDER DRIVE 1 ) * STOUGHTON WI 53589 1 ) * (608) 873 6651 1 ) * MADISON WISCONSIN LUG 1 ) * 1 ) *___ BRUCE L GAARDER 1 ) * MACALESTER COLLEGE 1 ) * 1600 GRAND AVE 1 ) * ST PAUL, MN 55105 1 ) * (612) 696 6170 1 ) * TWIN CITIES TIMESHARING LUG 1 ) * 1 ) *___ JOHN VILANDRE 1 ) * UNIVERSITY OF MINNESOTA 1 ) * LAB OF PHYSIOL HYG 1 ) * 1-210 HSUA 1 ) * MINNEAPOLIS MN 55455 1 ) * (612) 376 4056 1 ) * LOON LUG 1 ) * 1 ) *___ JIM LEEDHAM 1 ) MAYO FUNDATION 1 ) 200 1ST ST SW 1 ) ROCHESTER, MN 55905 1 ) (507) 284 2620 1 ) SOUTHEASTERN MINNESOTA LUG 1 ) 1 ) 1 ) 33 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 )___ STEPHEN D GABELNICK 1 ) CHEMICAL TECHNOLOGY DEVISION 1 ) ARGONNE NATIONAL LABORTORY 1 ) 9700 SOUTH CASS AVENUE 1 ) ARGONNE IL 60439 1 ) (312) 972 4365 1 ) CARTS LUG 1 ) + 1 ) +___ OSMAN AHMAD 1 ) + ASSOC OF AMERICAN RAILROADS 1 ) + 3140 S FEDERAL STREET 1 ) + CHICAGO, IL 60616 1 ) + (312) 567 3627 1 ) + CHICAGO AREA LUG 1 ) + 1 ) +___ JERALD J WRAY 1 ) + UNIVERSITY OF ILLINOIS 1 ) + 487 LOOMIS LAB OF PHYSICS 1 ) + 1110 W GREEN STREET 1 ) + URBANA IL 61801 1 ) + (217) 333 4922 1 ) + CENTRAL ILLINOIS LUG 1 ) + 1 ) +___ MICHAEL T SCOTT 1 ) + WASHINGTON UNIVERSITY 1 ) + 660 S EUCLID AVE 1 ) + MAIL STOP 8094 1 ) + ST LOUIS MO 63110 1 ) + (314) 454 3625 1 ) + ST LOUIS LUG 1 ) + 1 ) +___ ROBERT W FAIRCHILD 1 ) NEBRASKA WESLEYAN UNIVERSITY 1 ) 50TH & ST PAUL STS 1 ) LINCOLN NE 68504 1 ) (402) 466 2371 x341 1 ) MIDLANDS LUG 1 ) 1 )___ MARGARET H KNOX 1 UNIVERSITY OF TEXAS 1 COMPUTATION CENTER 1 AUSTIN TX 78712 1 (512) 471 3241 1 AUSTIN MINICOMPUTER LUG 1 / 1 /___ JOHN WILKES 1 / TULANE UNIVERSITY COMPUTER LAB 1 / RICHARDSON BLDG 1 / NEW ORLEANS, LA 70118 1 / (504) 865 5631 1 / LA OK TX AR LUG (LOTALUG) 1 / 1 / 1 / 34 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution 1 /___ SCOTT STEVENSON 1 / TANO CORPORATION 1 / 4301 POCHE COURT WEST 1 / NEW ORLEANS, LA 70129 1 / (504) 254 3500 1 / S. LA AND MI (SLAM) LUG 1 / 1 /___ GENE DUGGER 1 / HARDING UNIVERSITY 1 / BOX 753 1 / SEARCY, AR 72143 1 / (501) 268 6161 X266 1 / ARKLUG 1 / 1 /___ PAUL SANDWELL 1 8611 E 78 ST S 1 TULSA, OK 74133 1 (918) 252 5815 1 TULSA LUG 1 1___ RAYMOND P BOVET NCAR PO BOX 3000 BOULDER CO 80307 (303) 497 8907 ROCKY MOUNTAIN VAX LUG \ \___ DOUGLAS H THREATT \ BROOKS AIR FORCE BASE \ SCHOOL OF AEROSPACE MEDICINE \ SAM/BRSO \ SAN ANTONIO TX 78235 \ (516) 536 3886 \ ALAMO PDP-11 LUG \ ; \ ;___ ERIC S ZIPP \ ; 624 SIX FLAGS DR \ ; ARLINGTON, TX 76011 \ ; (817) 461 1242 X287 \ ; DALLAS/FORT WORTH VAX LUG \ ; \ ;___ ROBERT W HUTCHINSON \ ; DOW CHEMICAL U S A \ ; TEXAS DIVISION \ ; A P BEUTEL BUILDING \ ; FREEPORT TX 77541 \ ; (409) 238 1515 \ ; BRAZOSPORT LUG \ ; \ ; \ ; \ ; \ ; \ ; 35 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution \ ;___ PETER BUREK \ ; SIVALLS TANKS \ ; ODESSA, TX 7976X \ ; WEST TEXAS LUG \ ; \ ;___ HUGO BRAESICKE \ CELANESE CHEMICAL CO \ PO BOX 9077 \ CORPUS CHRISTI, TX 78469 \ (512) 241 2343 X4276 \ COSTAL BEND LUG \ \___ DAVID TAFF \ BOX 25048, STOP 978 \ DENVER FEDERAL CENTER \ DENVER, CO 80225 \ (303) 234 6479 \ DENVER AREA PDP-11 LUG \ I \ I___ JAMES M LIND \ I INMOS CORPORATION \ I P.O. BOX 16000 \ I COLORADO SPRINGS, CO 80935 \ I (303) 630 4390 \ I PIKES PEAK AREA LUG \ I \ I___ DARWIN L MECHAM \ I E G & G IDAHO \ I BOX 1625 \ I CFA 690 \ I IDAHO FALLS ID 83415 \ I (208) 526 2199 \ I \ I___ ROGER L ENGLEMAN \ I COMPUTER PARTNERS, INC \ I 2151 N. COLE \ I BOISE, ID 83704 \ I (208) 377 2080 \ I IDAHO LUG \ I \ I___ J R WESTMORLAND \ UTAH POWER AND LIGHT CO \ ROOM 184 \ 1407 WEST NORTH TEMPLE \ SALT LAKE CITY, UT 84116 \ (801) 535 2387 \ IMA LUG \ \ \ \ \ \ \ 36 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution \___ RICHARD OLDS \ AF WEAPONS LAB \ AFWL/ARLB \ KIRTLAND AFB NM 87117 \ (505) 844 2496 \ NEW MEXICO VAX LUG \ i \ i___ JANE FURZE \ i GENRAD - ATD \ i 4620 N 16TH ST \ i PHEONIX, AZ 85016 \ i (602) 264 2475 \ i \ i___ BOB NORBY \ i GTE MOCROCIRCUITS \ i 2000 W 14TH ST \ i TEMPE, AZ 85282 \ i (602) 968 3968 \ i ARIZONA LUG \ i \ i___ TED FROHLING \ i MOUNTAIN STATES ENGINEERS \ i PO BOX 17960 \ i INTERSTATE 10 AND VAIL ROAD \ i TUCSON, AZ 85731 \ i (602) 792 2800 \ i TUCSON LUG \ i \ i___ FRANCIS T KIELTYKA \ i LOS ALAMOS SCIENTIFIC LAB \ i PO BOX 1663 \ i X-DO MAIL STOP B218 \ i LOS ALAMOS NM 87544 \ i (505) 667 4159 \ i LOS ALAMOS VAX LUG \ i \ i___ DOUG GLADDEN \ i WHITE SANDS MISSILE RANGE \ i NR-AD-A \ i WSMR NM 88002 \ i (505) 678 3348 \ i SOUTHERN NM LUG \ i \ i___ CLIFFORD P LLOYD \ PO BOX 1912 \ LAS VEGAS, NV 89125 \ (702) 739 0541 \ EG&G LUG \ \ \ \ \ \ 37 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution \___ DICK ADAMS \ DOUGLAS AIRCRAFT CO \ MAIL CODE 41-56 \ 3855 LAKEWOOD BLVD \ LONG BEACH CA 90846 \ (213) 593 0290 \ LA AIRPORT AREA VAX LUG \ ( \ (___ BRADFORD A LUBELL \ ( LA CARDIOVASCULAR RESEARCH LAB \ ( UCLA A3-381 CHS \ ( LOS ANGELES CA 90024 \ ( (213) 825 6713 \ ( UCLA LUG \ ( \ (___ CHARLES SOUTH \ ( HUGHES RESEARCH LABS \ ( M/S RL86 \ ( 3011 MALIBU CANYON ROAD \ ( MALIBU, CA 90265 \ ( (213) 456 6411 X402 \ ( LOS ANGELES VAX LUG \ ( \ (___ SANDRA LYDDON \ ( CHEVRON OIL FIELD RESEARCH \ ( P O BOX 446 \ ( 3282 BEACH BLVD \ ( LA HABRA, CA 90631 \ ( (213) 694 7132 \ ( PACIFIC AREA VAX LUG \ ( \ (___ RICHARD A BALDWIN \ ( NO CTY COMP SERV \ ( 2235 MYERS AVE \ ( ESCONDIDO CA 92025 \ ( (619) 745 6006 \ ( SAN DIEGO COMMERCIAL LUG \ ( \ (___ PAUL WILFONG \ VERAC, INC \ SUITE 300 \ 10975 TORREYANA \ SAN DIEGO, CA 92121 \ (619) 457 5550 \ SAN DIEGO PDP-11/VAX LUG \ \___ STEVE SWENSON \ HARRIS CORPORATION \ 1691 BAYPORT AVE \ SAN CARLOS, CA 94070 \ (415) 594 3524 \ BAY VAX LUG \ ) \ ) 38 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution \ )___ JON FORREST \ ) DEPARTMENT OF PHYSICS \ ) UNIVERSITY OF CALIFORNIA \ ) SANTA BARBARA, CA 93106 \ ) (805) 961 2602 \ ) SANTA BARBARA USERS GROUP \ ) \ )___ MARK VIERS \ ) NAVAL WEAPONS CENTER \ ) CODE 3872 \ ) CHINA LAKE CA 93555 \ ) (619) 939 3169 \ ) CHINA LAKE LUG \ ) \ )___ ALLAN LESLIE VAN LEHN \ ) LAWRENCE LIVERMORE LAB \ ) BLDG 151, ROOM 2323 \ ) 7000 EAST AVE \ ) LIVERMORE, CA 94550 \ ) (415) 422 6652 \ ) LIVERMORE AREA LUG \ ) \ )___ ROBERT WALRAVEN \ UNIVERSITY OF CALIFORNIA \ APPLIED SCIENCE \ DAVIS CA 95616 \ (916) 752 0360 \ U. C. DAVIS LUG \ \___ STEVE LORENTZEN UNICOMP CORP 500 FOURTH & BATTERY BLDG SEATTLE WA 98121 (206) 223 6453 SEATTLE AREA LUG | |___ KEVIN DOUGLAS WALKER | UNITEK ELECTRONICS, INC | 2850 PAA STREET, STE 222 | HONOLULU, HI 96819 | (808) 836 0877 | ALOHA LUG | |___ ROBERT N PERRY | TEKTRONIX | P O BOX 500 | DELIVERY STATION 50-454 | BEAVERTON OR 97077 | (503) 627 5410 | PORTLAND AREA PDP11 LUG | | | | 39 PAGESWAPPER - February 1984 - Volume 5 Number 8 Fall 1983 VAX Systems SIG Tape Distribution |___ ROSS W MILLER | ONLINE DATA PROCESSING, INC | N 637 HAMILTON | SPOKANE, WA 99202 | (509) 484 3400 40 PAGESWAPPER - February 1984 - Volume 5 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 227 Caption: Computer to tape punch communication Message: We have a VAX-11/750, Remex tape punch (RPM 612 XBAA/B), Remex tape reader (RPS612 XBB/RPF 612XBB), and a Remex interface (RJA2322B). We would like to correctly punch an ASCII file sent from the computer. Does anyone have a program which will allow us to do this? Contact: Sharon Kotow 2567 S.E. Main Street Irvine, CA 92714 (714) 660-1600 Date: December 15, 1983 INPUT/OUTPUT 228 Caption: Remote Site Systems Management Message: We are installing a VAX network of 6 systems, 4 of which are in other states. Data Entry clerks via a menu system will perform base system operator tasks, but what (if anyone has experience in this) might be the best way to handle VMS updates and other matters that require on-site console work, especially if there is one primary license and 5 right-to-copy agreements. Contact: Arthur Mann Ball Corporation, P. O. Box 589 Broomfield, CP 80027 (303) 457-5309 Date: December 19, 1983 41 PAGESWAPPER - February 1984 - Volume 5 Number 8 INPUT/OUTPUT INPUT/OUTPUT 229 Caption: VAX I/O Driver for Tektronix GPB Interface Message: We would like to use the Tektronix GPIB UNIBUS interface (CP1100IEEE/021-0230-00) on our VAX 11/730 to control a set of transient digitizers (Tektronix 7612 and 7912AD units) and would like to acquire a VAX Driver for it and any FORTRAN utilities that may also be available. Alternate suggestions for interfaces to these digitizers and experience of others will also be welcome. Contact: Gary Powley Los Alamos National Laboratory PO Box 1663, MS J970 Los Alamos, NM 87545 (505) 667-6881 Date: December 27, 1983 INPUT/OUTPUT 230 Caption: Forms Type on Print Job Accounting Record Message: We are looking for a method to capture the forms type for accounting purposes. We would prefer that the information be recorded in the accounting record for each print job. Contact: John Newman Western Carolina University Computer Center Cullowhee, NC 28723 (704) 227-7282 Date: January 3, 1984 INPUT/OUTPUT 231 Caption: Print Symbiont - Scheduling by size Message: We would appreciate any method (program) other than manual intervention by operators - for scheduling the print queues by size. The smaller jobs should be printed first. The program might assume all print jobs were submitted with /HOLD and it would be smart enough to release the jobs in ascending order of size based on current attributes of the queue including 42 PAGESWAPPER - February 1984 - Volume 5 Number 8 INPUT/OUTPUT forms type and characteristics. Contact: John Newman Western Carolina University Computer Center Cullowhee, NC 28723 (704) 227-7282 Date: January 3, 1984 INPUT/OUTPUT 232 Caption: Magnetic Tape Software - REPLY TO I/O # 214 Message: We have a simple foreign tape read/write/dump utility which is perfectly adequate for handling simple multiple file foreign tapes. We use it to transfer data and programs between our VAX-11/780 and many other types of computers. We also use it to "recover" backup and ANSI tapes that have inadvertantly been partially destroyed. Contact: Mark Frolli Mission Research Corporation PO Drawer 719 Santa Barbara, CA 93102 (805) 963-8761 Date: January 11, 1984 INPUT/OUTPUT 233 Caption: Tektronix Interface Message: I am looking for software to operate under VMS on a VAX 11/780 to simulate scrolling for a Tektronix 4013. Contact: Michael Serotta, M/S 181 Raytheon Company P. O. Box 360 Portsmouth, RI 02841 (401) 847-8000 Date: January 16, 1984 43 PAGESWAPPER - February 1984 - Volume 5 Number 8 LUG Meeting Reports LUG Meeting Reports o BAYVAX LUG (San Francisco area) - November 17, 1983 From VOX VAX, the BAYVAX LUG Newsletter Meeting of November 17th at Four Phase in Cupertino. The speaker was (and still is) Richard Ptak/DEC and his topic was Digital's view of the UNIX operating system and where it is appropriately used. He has been with DEC for 5 years and 9 years with the Bell System, mostly involved with Unix, so he knows whereof he speaks. In his view, Unix (and its look-alikes) are very nice user environments, if you are: - a sophisticated user - with an easily recoverable application The major advantages of Unix are its small size, and the combination of a consistent yet easily modifiable interface. On the other hand it is 13 years old, based on a 16-bit world, and bound to have some old concepts built in. On the other hand [is that 3 hands?], it is in widespread use in the academic community, so that a large number of CS graduates think they need it to do real work. On the other hand [wait a minute!], it appears to have a somewhat fragile user/file system interface; but if your application doesn't present this to your user, who cares? [Etc.] One of Ptak's favorite stories is of the man who, upon learning that his bank just installed a Unix-based account handling application, withdraws all his funds except $5. When asked why, he responds "When that system goes belly up and tacks all those zeros on someone's balance, it may just be mine!" DEC already has a 16-bit Unix product on the market: "V7M-11". It is a full-fledged DEC product, with the resulting high quality documentation and software support. It is apparently an enhanced V7 version. It features error-logging, separate/non-separate I and D space versions, the VI screen editor, interactive semi-automatic sysgen, and device drivers for many of the PDP devices. It is only available as binaries, although a C compiler comes with it. It is already in shipment. The product for the Pro 350 is called "Pro V7M" and may ship in the first quarter of '84. 44 PAGESWAPPER - February 1984 - Volume 5 Number 8 LUG Meeting Reports The VAX Unix product is considerably more hazy, in part because two approaches are being explored. The "best" approach is to provide any useful Unix features in the VMS environment. This has been started with the "VNX" products (a "C" compiler and the CMS and MMS products), the capability to install a user-specific DCL, and byte-stream file support in RMS. The other approach is to fix up as many of the deficiencies of Unix as possible, and present that to the users. 45 PAGESWAPPER - February 1984 - Volume 5 Number 8 VAX System SIG Committee List VAX System SIG Committee List As of November 2, 1983 Joe Angelico - Volunteer Coordinator and System Management US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA. 70130 June Baker - Planning Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 C. Doug Brown - Security Sandia Labs P.O. Box 2644 Albuqueque, NM 87185 Jack Cundiff - Assistant Symposium Coordinator Muskigum College New Concord, OH 43762 James R. Cutler - Hardware Software Results Corporation 2887 Silver Drive Columbus, OH 43211 Doug Dickey - Data Management SIG Interface CTEC, Inc. 6862 Elm Street McLean, VA 22101 Jim Downward - Migration and Host Development KMG Fusion Inc. 3621 So State Road, P.O. Box 1567 Ann Arbor MI 48106 Dan Fleury - Education University of Hartford West Hartford, CT 06117 Dennis Frayne - Real Time/Process Control McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals In House Systems 165 William Street 46 PAGESWAPPER - February 1984 - Volume 5 Number 8 VAX System SIG Committee List New York, NY 10038 Stephen Gill - Commercial Ball Aerospace P.O. Box 1062 Boulder, Colorado 80306 Don Golden - Overseas Coordinator 500 Corporate Drive Sugarland, TX 77478 Gary Grebus - System Improvement Request Battelle Columbis Labs 505 King Avenue Columbus, OH 43201 Dr. Mark Hale - Education University of Florida 411 Weil Hall Gainesville, FL 32611 B. Hancock - Network Sohio Petroleum Company Two Lincoln Center 5420 LBJ Freeway, Suite 900/LB 03 Dallas, TX 75240 R. Haydt - Foreign Devices, Hardware/Software Information Consultants International Incorporated P. O. Box 2014, E. V. STA Ormond Beach, FL 32074 Jeffrey S. Jalbert - Symposium Coordinator Dennison University Granville, OH 43023 Ken Johnson - Handouts 800 N. Lindbergh Monsanto MS V2B St. Louis, MO 63043 Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 47 PAGESWAPPER - February 1984 - Volume 5 Number 8 VAX System SIG Committee List Bob Robbins - VAXElan Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA P. Sandwell - Graphics Seismograph Service Corporation P. O. Box 1590 Tulsa, OK 74102 David Schmidt - LUG Coordinator Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201 D. Slater - Artificial Intelligence Mantech International 2320 Mill Road Alexandria, VA 22314 Louise Wholey - Languages and Tools Measurex Corporation One Results Way Cupertino, CA 95014 Douglas J. Wilson - Office Automation MIT Joint Computer Facility Room 5-137, 22 Massachusetts Avenue Cambridge, MA 02139 48 PAGESWAPPER - February 1984 - Volume 5 Number 8 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: PAGESWAPPER Editor, DECUS, MRO2-1/C11, One Iron Way, Marlborough, MA 01752, USA 49 PAGESWAPPER - February 1984 - Volume 5 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 50 PAGESWAPPER - February 1984 - Volume 5 Number 8 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) 51 PAGESWAPPER - February 1984 - Volume 5 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 52