CHAPTER VAX PAGESWAPPER - October 1985 - Volume 7 Number 3 "It's in the Fiche" - Unexpected Interrupt Handling under VMS . . . . . . . . . . . . . . . VAX-3 Editor's Workfile . . . . . . . . . . . . . . . VAX-8 Patch to Fix an EDT Line Mode Problem . . . . . VAX-9 Cluster Notes . . . . . . . . . . . . . . . . VAX-11 The Jury is Still Out . . . . . . . . . . . . VAX-14 VAX System SIG Committee List . . . . . . . . VAX-17 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-21 LUG News . . . . . . . . . . . . . . . . . . . VAX-27 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-37 System Improvement Request Submission Form . . VAX-39 PAGESWAPPER - October 1985 - Volume 7 Number 3 General material for publication in the Pageswapper should be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters. Please do not submit program source, as that is better distributed on the VAX SIG tape. Material for "(THE (LINKED LIST))" section of the Pageswapper (pertaining to Artificial Intelligence) should be sent to: Terry C. Shannon Technical Editor THE DEC* PROFESSIONAL Magazine 921 Bethlehem Pike Springhouse, PA 19477 USA (215)-542-7008 Material for "The DBMS Monitor" section of the Pageswapper (pertaining to VAX-11 DBMS) should be sent to: Julie Llewellyn United Technologies Microelectronics Center 1365 Garden of the Gods Road Colorado Springs, CO 80907 USA Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - October 1985 - Volume 7 Number 3 "It's in the Fiche" - Unexpected Interrupt Handling under VMS "It's in the Fiche" - Unexpected Interrupt Handling under VMS G. Greene Seaport Systems 165 William Street, New York, NY 10038 Vax Interrupts. This discussion focuses on software handling of interrupts generated by the UNIBUS. On the VAX the VMS operating system is 'interrupt driven', which means that the signals it uses to coordinate activities and handle events are primarily interrupts of various priorities. There are other mechanisms that VAX/VMS uses but interrupt handling is the primary one and the only one which concerns us at the moment. Interrupts come in a variety of flavors, i.e. each one has a priority associated with it. Each interrupt and exception condition is routed to a software handling routine. The central dispatcher for this routing is a table called the System Control Block (SCB), of which more will be said later. An Interrupt Priority Level (IPL) is the mechanism used to define a specific position in the hierarchy of priorities. IPL's run from 0 to 31, with 0 through 16 being software related (the machine normally runs software at IPL 0 ) and 17 through 31 being used for hardware related interrupts. If the machine is running at a given IPL and an interrupt occurs that has a higher IPL, the machine drops what it's doing and services the interrupt. If an interrupt with a lower IPL occurs it is ignored until the IPL at which the machine is running is lowered below that value. A device such as a disk drive will have a specific IPL associated with it and will normally issue a hardware interrupt to get the attention of the CPU and thus interface with software. It may do this when it finishes an I/O request, when an error occurs, or when it first comes on line etc. A device hardware interrupt is usually a signal transmitted via a pathway known as a BUS. The UNIBUS is one bus structure that can connect devices to all VAX's. The MicroVAX device bus is the QBUS. For the purpose of interrupt dispatches the QBUS is handled in the same way as the UNIBUS on the smaller VAXes. A device interrupt on the UNIBUS will usually have an IPL ranging from 20 to 23. Between the UNIBUS and the CPU is a VAX-3 PAGESWAPPER - October 1985 - Volume 7 Number 3 "It's in the Fiche" - Unexpected Interrupt Handling under VMS UNIBUS ADAPTER (UBA), of which there are two kinds currently in use. One version for 750 and smaller VAXes and one version for 780 and up. The remainder of this discussion will be split along the different ways in which these two UBAs work. All this is nicely documented in the books VAX/VMS Internals and Data Structures, the VAX Hardware Handbook and the VAX Architecture Handbook. Interrupt Vectors. For every known device there are one or more interrupt vector(s) which are established via AUTOCONFIGURE or the SYSGEN CONNECT command. This vector is used to direct each interrupt to the software which will service it. In the context of this article an unexpected interrupt will take on only one of two possible meanings. An interrupt can be unexpected either because it comes at an unexpected time, or it can be unexpected in the sense that there is no known device associated with it. The latter is what we will be discussing here. It should be noted that any device remains "unknown" if it has not been connected via AUTOCONFIGURE or the SYSGEN CONNECT command. When a UNIBUS interrupt is generated it is first picked up by the UBA. On the 750 and smaller VAXes the UBA passes the interrupt straight to the CPU with its associated vector. The vector is actually an offset into a table that is located in the System Control Block. The table entries are longwords and begin at the second page of the SCB. On the 730 and MicroVAX there is one page of these device specific vectors and there are two pages (one for each unibus) on the 750. When an interrupt is processed the system looks to the vector offset in the SCB. It interprets what it finds as the longword address of a Channel Request Block (CRB). When control is passed to the beginning of the CRB, action is taken to call an interrupt handling routine for this particular interrupt. On the 780 instead of vectoring straight through the SCB, the initial device interrupt is received by the 780 UBA. The adapter then interrupts the CPU. The CPU calculates an offset into the first page of the SCB from the priority of the interrupting device and the 'TR' slot number that the UBA occupies in the Synchronous Backplane Interconnect (SBI). The address found at this location in the SCB is used to call the correct adapter interrupt service routine . The UBA interrupt service routines reside in an Adapter Control Block (ADP). There is one routine for each of the four device IPLs. This code saves R0 through R5 and reads the original vector from a UBA register called BRRVR. Using this, the original vector, as an index into a vector table in the ADP the address of the VAX-4 PAGESWAPPER - October 1985 - Volume 7 Number 3 "It's in the Fiche" - Unexpected Interrupt Handling under VMS appropriate Channel Request Block (CRB) that should receive control is found. All this is very nice unless you happen to be the curious sort and wonder what happens if some random glitch occurs and an interrupt is generated with a vector having no "known" device associations. If this happens the system will look at this random address in the SCB or vector table. What will it find there ? VMS developers, being the conscientious sort, take this unlikely event to heart and provide an escape so the interrupt doesn't hang and/or blow everything up. A default interrupt handling routine is provided and its address (instead of the address of a CRB) is put into the SCB (or ADP) during system initialization. This routine is called UBA$UNEXINT. The code for the 750,730,725 and MicroVAX is the same due to the similarity of their structures and the code merely dismisses the interrupt with an REI, no error logging, no counts of errors or anything. For the 780,785 and perhaps the 8600 the code is slightly different due to the SBI interface et al. For these the registers that were saved must be restored before the REI is invoked. HUNTING FICHE. The trail to follow for this information seems to exist mostly in the microfiche which tends to provide the definitive, although not always the clearest, picture of what happens inside the black box called systems software. For the 730 the trail was as follows : The first step was to read some in the VAX/VMS Internals book and then ask advice of the nearest wizard. The address of the SCB is stored in the internal register PR$SCBB, so a short macro routine can extract it, but it is also stored at EXE$GLSCB when the SCB is initialized. (See page 582 Internals). From here one goes on to use the System Dump Analyzer (SDA) to look at the contents of EXE$GLSCB using the EXAMINE command. Then write the contents of the page that starts at EXE$GLSCB + 200 (hex) for the 730 (two pages if it's a 750 with two unibusses) to a data file. The command sequence on our 730 is : VAX-5 PAGESWAPPER - October 1985 - Volume 7 Number 3 "It's in the Fiche" - Unexpected Interrupt Handling under VMS $ ANALYZE/SYSTEM SDA > EXAMINE EXE$GL_SCB EXE$GL_SCB: 800EC800 SDA > SET OUTPUT SCBPAGE2.DAT SDA > EXAMINE 800ECA00:800ECBE0 ! 1 page starting at 800EC800+200 SDA > _^Z This yields a list (in the file SCBPAGE2.DAT) of the addresses of the directly vectored interrupt routines (their CRB's actually). The offset of 200 hex is because the direct device vectors all point to addresses in the second page of the SCB (see page 100 Internals). Once the contents of this page is printed out, one can use SYSGEN to write the list of vectors for devices that have been loaded after boot. The command sequence to send this to the file CONNVEC.DAT is : $ RUN SYS$SYSTEM:SYSGEN > SET/OUTPUT=CONNVEC.DAT > SHOW/CONFIGURE/CONNECT > _^Z Excluding the addresses at these vectors, the remaining unidentified addresses (in the second page of the SCB) should be few. Take note of these and do a search of SYS$SYSTEM:SYS.MAP from a terminal for the addresses noted. Remember to change the hex address so that the last two bits are zero before you do the search. For instance 80002EB9 would be changed to 80002EB8. This should yield a short list of routine names of which UBA$UNEXINT should be one. On the 730 I typed : $ search/output=searchout.dat SYS$SYSTEM:SYS.MAP 80002EB8 and got back UBA$UNEXINT 80002EB8-R SYSLOAVEC 80002EB8 R-UBA$UNEXINT in the file searchout.dat. Now one begins fiche hunting. Find the index fiche (the last one of the set) and get the fiche address of SYS.MAP (369-M12) under the SYS facility heading. At (370-M1) it says that UBA$UNEXINT is defined by SYSLOAVEC (386-E9) as would be suspected from the output of our search of SYS.MAP. At (386-J9) one finds that UBA$UNEXINT has the address of the label UBAUNEXINT::. A reference to this turns up in SYSLOA730.MAP (390-M8) at (390-H9) and says it's defined by ADPSUB730 and reference by LOAVEC. Looking through ADPSUB730.LIS (391-H13) we VAX-6 PAGESWAPPER - October 1985 - Volume 7 Number 3 "It's in the Fiche" - Unexpected Interrupt Handling under VMS find the code we want at (391-B14). Nothing but an REI !!! The same turns out to be the case for the MicroVAX and the 750 while for the 780 series stuff the registers are popped off the stack and then the REI is done. CONCLUSION. In conclusion, the interrupt routine we're interrested in does nothing but dismiss the interrupt. This is fast and appropriate but could conceivably be enhanced somewhat since having oodles of these unexpected interrupts could go unnoticed except for the time usurped to handle them all. Unexpected interrupts of this sort would probably indicate a bus problem or an improperly set up device. The material for this article was uncovered as we were trying to incorporate the ability to quantify the number of unexpected unibus device interrupts occurring over a period of time into a performance monitor. VAX-7 PAGESWAPPER - October 1985 - Volume 7 Number 3 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor Things you learn from cassette tapes - Listening to cassette tapes of symposium sessions you couldn't attend is a great way to catch up on what is coming. David Blickstein of DEC said at an APL session in New Orleans that for VAX APL version 2 they are hoping to offer an execute-only APL at a separate (presumably reduced) price. That is good news for anyone trying to port applications between VAXen; those with compiled languages have it easier now that the RTL for VAX C (the last holdout) will be shipped with VMS. In the case of an interpreted language, however, there is no RTL to ship with VMS; it is the guts of the interpreter which is needed. Blickstein also said they are hoping to provide a call interface (now that merged image activates are supported by LIB$FINDIMAGESYMBOL) from APL to compiled language subroutines. Now if we could just go the other way... VAX-8 PAGESWAPPER - October 1985 - Volume 7 Number 3 Patch to Fix an EDT Line Mode Problem Patch to Fix an EDT Line Mode Problem Dr. Tori Basford Pima Community College 2202 West Anklam Road Tucson, AZ 85709 Problem: When EDT is operating in line-mode and is printing line numbers, the first tab stop appears on the screen to be in column 5 rather than in column 9 where it really is. Explanation: Line numbers are printed in a 12-column field. Tabs are handled by advancing the cursor to the next multiple of 8. Thus the first tab is only 4 columns from the end of the line number instead of 8. Temporary solution: The following patch to EDTSHR forces EDT to treat every line number as a "large" number that needs 16 columns. I have not explored what happens if a file actually contains a large line number (GEQ 100,000). SYS$SHARE:EDTSHR.EXE ! ECO-99...Written by Dr. Tori Basford, Pima College ! Temporary fix until Digital provides a better one. ! Patch EDT to show tabs correctly during insert ! Note: Unknown results for line numbers over 100,000 SET ECO 99 ! ------------------------------------- ! Patch Module EDT$LFLNO (Fiche 136 E1) ! Expand dummy-number at B078 from 13 to 16 blanks VERIFY 0B084 = 00000020 DEPOSIT 0B084 = 20202020 ! Move the blanks and count to work areas VERIFY/INST 0B0F2 = 'MOVC3 #0C,B^0B078,(R8)' DEPOSIT/INST 0B0F2 = 'MOVC3 #10,B^0B078,(R8)' VERIFY/INST 0B0F7 = 'MOVL #0C,R3' DEPOSIT/INST 0B0F7 = 'MOVL #10,R3' ! Short line now has count=16, not 12. VERIFY/INST 0B127 = 'CMPL R3,#0C' DEPOSIT/INST 0B127 = 'CMPL R3,#10' ! ------------------------------------- ! Patch Module EDT$LINSERT (Fiche 136 H3) ! Change Big-prompt from 17 to 16 blanks VAX-9 PAGESWAPPER - October 1985 - Volume 7 Number 3 Patch to Fix an EDT Line Mode Problem VERIFY /INST 0C17F = 'ADDB3 #5,R0,(SP)' DEPOSIT/INST 0C17F = 'ADDB3 #4,R0,(SP)' VERIFY /INST 0C18B = 'MOVC3 R0,B^3(R7),B^8(SP)' DEPOSIT/INST 0C18B = 'MOVC3 R0,B^3(R7),B^7(SP)' VERIFY/INST 0C191 = 'MOVC5 #0,(SP),#20,#5,B^3(SP)' DEPOSIT/INST 0C191 = 'MOVC5 #0,(SP),#20,#4,B^3(SP)' ! Always use Big-prompt VERIFY/INST 0C1F6 = 'MOVAB (R7),R2' DEPOSIT/INST 0C1F6 = 'MOVAB (SP),R2' ! Save the resulting patched image UPDATE Pageswapper Editor's Note Be sure to save the unpatched versions of the EDT images and make sure they are the ones present for VMS maintenance updates so that any DEC changes get properly applied. VAX-10 PAGESWAPPER - October 1985 - Volume 7 Number 3 Cluster Notes Cluster Notes Mike Drabicky, Sohio Petroleum Two Lincoln Center 5420 LBJ Freeway Suite 900/LB03 Dallas, TX 75240 (originally published in the August 1985 DFWLUG Newsletter) The latest and greatest HSC50 microcode is V201. There is a patch to V200 that keeps the tapes from running off the end of the reel. There are rumors that V225 or V250 is due out shortly. The number seems to vary depending on who you talk to. the major benefit here is the elimination of the node lockout problem under the current version. The CI V4 microcode fixed that on the VMS side. The next version of the HSC50 microcode should fix it there. There is a problem with the MicroVAX II BASIC V2.3 distribution kit. It's really no big deal; there are two floppies labeled 1/2 and 2/2. Both are copies of the 1/2 floppy. I guess DEC just wanted to make sure we'd have a backup of that floppy in case there was a parity error on the first copy. Oh well, who wants to program in BASIC anyway? If you have used VMSKITBLD.COM to build yourself a VMS V4.1A pack for your VAX 8600, you will have a problem with the ANALYZE/ERROR (ERF) utility. It seems that the kit build procedure forgot to include ERFCTLSHR.EXE and ERFUVAX.EXE during the build process. Your kit is ok, VMS boots ok, all is well with the world except that these two files are missing. The fix is simply copying these two images from [syslib] on the source pack to [SYSLIB] on the destination pack. If you are booting from a CI780/CI750 and get the "Unable to initialize device" or "Unable to locate boot block" message from VMB, you may have a ROM/RAM mismatch. The current levels are Rev 3 for the hardware and Rev 4 for the software. To determine which you have, do the following: 780/785 processors: 750 processors: >>>H >>>U >>>I >>>D 2001C014 3FA >>>D F3E014 3FA >>>E 2001C018 >>>E F3E018 P 2001C018 xxA1D000 P F3E018 xxA1D000 >>>D 2001C014 BFF >>>D F3E014 BFF VAX-11 PAGESWAPPER - October 1985 - Volume 7 Number 3 Cluster Notes >>>E 2001C018 >>>E F3E018 P 2001C018 yyA1D000 P F3E018 yyA1D000 As given above, xx is the CI780.BIN/CI750.BIN microcode level (should be 3 or 4) and yy is the hardware rev level (should be 3). If yours are not, get in touch with your field service rep to get them updated. While on the subject of the CI Rev 4 microcode, you MUST be running rev 4/3 of the microcode/hardware if you have an 8600 in your cluster. Without it, you will most likely experience node lockout problems, particularly with the HSCs. When you do your copies, if you use FLX, make sure that you use the /IM switch since you want the binary image of the file, not the ASCII version thereof. You're okay if you're using EXCHANGE. And before you go running off to do this, rename the old CI780.BIN to something like CI780.OLD so that you'll still have it around in case your rev 4 image is bad. Note that VMS checks the rev level of the CI microcode at boot time. The current algorithm considers anything above rev 3 as experimental and continues so both the PADRIVER and VMS will be happy with the change. And while on the subject of node lockouts, let's talk a bit more about the problem. Under certain VAX failure conditions, the HSC will decide that it doesn't want to talk with the node after it has been rebooted. In a sense, it is perturbed that the node had the indignity to go away in the first place. To show its ire, it will allow a virtual connection to be made with the rebooting node but no software connection will be allowed. To get around this, on VMS V3.7 clusters only, change the node number on the CI780 to something non-existent on the cluster (make sure you change both DIP switches). The HSC will think this is a new node and allow it to play (trusting fellow, isn't he?). On a V4 cluster, NEVER CHANGE THE CI780 PORT NUMBER WITH THE CLUSTER UP. Instead, you'll have to reboot the HSC at which time, everything will be fine. V250 of the HSC software should fix this problem. If you are having a "host clear" forcing a crash dump on your HSCs, you may be able to get around this problem. The key to this problem is that, on reboot, the HSC console will print out: - SUBSYSTEM EXCEPTION -... Kernal PC: nnnnnn caused by (134) Kint followed by a console dump. Near the bottom of that dump will be the status of requestors 1-9: 000177 000377 000002 etc. VAX-12 PAGESWAPPER - October 1985 - Volume 7 Number 3 Cluster Notes The key is the 177 status for requestor 1 (K.CI). the register contents of the K.CI will be printed vertically as the last items of the dump. Count down to the 17th entry in the register area; it will contain the station address of the node that forced the host clear. While there is no real solution to this problem, you can get a little better hold of which node caused the reboot. To get the HSC to print the "Last soft init caused by host clear from node n" as with V100 and V110, get into SETSHO and do the SET NODUMP HOST/PERM command. This will then help out on all such future occurrences of this error. If the error is not happening to you, you should probably do this anyway since verbose error messages are preferable to numbers. And perhaps a bit in the way of explanation is in order. A "host clear" is part of the HSC design. Any time the HSC fails to respond to outstanding CPU commands within approximately 80 seconds, the VAX node will reboot the HSC. The reasons for this occurring are varied and complex, but basically VMS considers the HSC "insane" if it cannot complete a request within this period of time. The most likely reason is that there are multiple errors on multiple sectors, all occurring during a transfer. When VMS issues a GET STATUS command to the HSC, the HSC does not have enough time to respond to the request and thereby the timeout occurs. Future versions of the HSC50 microcode will do a little better job on the I/O cleanup to prevent this type of problem. VAX-13 PAGESWAPPER - October 1985 - Volume 7 Number 3 The Jury is Still Out The Jury is Still Out Phil Anzel, Banner Associates Post Office Box 550, Laramie, WY 82070 (originally published in the June 1985 LUG NOTES of the RMVLUG) The jury is still out on a number of issues... TU81, RA81/UDA50, DMZ32, DHU11-M, DFMxx, 11/780 to 11/785 upgrade, laser printer, MicroVAX II. We have been upgrading, and expanding, and would like to share some experiences with you. We recently (read finally) canned our TE16 in favor of a TU81 (tape drive, 25/75 ips, 1600/6250 bpi, start-stop/streamer) and sat back, waiting for sparks to fly. Even bought a new DW780, new UNIBUS, trying to pull out all the stops. Oh boy, BACKUP in (let me see, 75ips divided by 45 ips, 6250 bpi divided by 1600 bpi, uhmm that's 1.67 times 3.91 equals 6.53) one sixth the time with one third the tape. Wrongo. BACKUP on the 780 (or 785) just cannot keep up with 75 ips at 6250. It is not the tape drive, however. One can write a program to send 65 megabytes of data to the tape using large blocks, asynchronous QIOs, and the tape will definitely stream. So BACKUP is the culprit here. Still and all, we are seeing about one-third the TE16's time for BACKUP/IMAGE for RA81 to TU81. CPU performance seems to be the bottleneck. Smaller than the TE16, easier tape loading, great documentation (if you will settle for the TU80 manual; there is none for the 81). Was it worth it? We'll see. After months of trying to squeeze the remaining few percent out of our RM05s, we broke down and brought in an RA81 (just happened to have it in the same cabinet as the TU81). Hung it onto our system with a UDA50. Like small footprint. Like the high storage density. Like the low power consumption. Like the reasonable response times. DEC has a good product, not an exemplary one. But it integrates well, and so far has not caused any headaches. That is probably the best thing one could hope for. For some strange reason, more and more people want to talk to our VAX. Back at VMS 3.7, we were able to add a DMZ32 mux: single Unibus board, two twisted-pair wiring (using T-1 style time-division multiplexing) to a distribution box up to 2000 feet away. The distribution box has some mysterious expansion capabilities, but no hint as to what may come. It gives you 24 ports at a distance. It is mostly a good product: reasonable total bandwidth; port attributes are controllable from the host (like DMF32's asynch ports). It shows up as three separate controllers (ports numbered TXA0-TXA7, TXB0-TXB7, TXC0-TXC7). There is no end-to-end error correction and retransmission, so be careful with line length, line routing, line shielding. VAX-14 PAGESWAPPER - October 1985 - Volume 7 Number 3 The Jury is Still Out Unless you have VMS 4.X, you will need to configure manually through SYSGEN. A MAJOR PROBLEM with the product is its inability to recover from a transient power outage. The 780 or 785 is normally able to weather brief (fraction of a second to several minutes, given memory battery backup) power interruptions. If power is interrupted to either the DMZ32's distribution box or to the main module, VMS (3.7, 4.0, 4.1) refuses to talk to the DMZ's ports. The ports are shown as "busy" or "timed out". The only work-around right now is to shutdown oand reboot the system. This wins you plenty of friends. With VMS 4.0 we added the DHU11 terminal multiplexor. Again, this is a single Unibus board, with a 16-port distribution panel mounted on the Unibus cabinet. It looks like a 16-line DMF32 to the system (ports called TXA0-TXA15). other than breaking third-part software that presumes a four-character port name, the unit does what it is supposed to do. This one appears to be a true winner. Next on the list is the DFM statistical multiplexor. We bought a pair of the DFM08-AC units (8-line, integral 9600-baud private-line modem). It is expandable and upgradable to more lines and a higher speed modem. It has interesting port contention and control features. It is too bad you have to turn all the room lights out to see the LEDs behind the bezel. This has the poorest DEC product documentation we have seen in quite some time. The documentation on the error messages doesn't tell you much about how severe particular problems are, whether the errors are soft or hard, and whether the errors represent equipment problems or telephone line problems. Errors, however, appear to be few, and both DEC and AT&T Communications have been patient... not successful, just patient. We are still waiting for wine to flow beneath the willow trees, now that we have upgraded from a 780 to a 785. The installation was relatively painless (yes, DEC Field Service does appear to be getting better), none of our application software needed to be touched, and the machine booted first time. Perhaps I have a problem with sales literature, but the 1985 DEC ADD-ONS & UPGRADES catalog states that "Digital's new VAX-11/780 to VAX 11/785 upgrade gives you a full 50% to 70% improvement in overall CPU performance, plus a host of features to make your system run faster and more efficiently" (page 11). There are no caveats about job mix, instruction mix, peripheral mix, or what have you. So in my simple-minded way I figured that 50% more means that three units of CPU work on the 785 would take as many CPU seconds as two units of work on the 780. Or, expressed as a ratio of CPU seconds for a single unit of work, (780 CPU seconds) divided by (785 CPU seconds) should be 1.5. We have tried a number of different activities including EDT, RUNOFF, CADD (single-precision integer intensive processing), FORTRAN compiles, DATATRIEVE, BASIC and FORTRAN real-number intensive VAX-15 PAGESWAPPER - October 1985 - Volume 7 Number 3 The Jury is Still Out application programs and so on. The performance was not as advertised. We are giving DEC an opportunity to respond, and will report back to you. Yes, I admit it, we have non-DEC peripherals. Back when the LN01 was new it cost more than a similar product from another vendor with the same specs. Ours uses the Ricoh print engine; I'll leave it up to you to guess the vendor. Anyway, the vendor's literature promised a 20,000 copy lifetime for the image transfer belt, and operation to 8,000 feet above sea level (we are at 7,200 feet). As might be expected, altitude caused toner problems, and we are experiencing belt lifetime problems (2,000 to 4,000 copies per belt). I'm just curious, but do any of you use the LN01 at Denver's elevation or above? Any problems? Last, and best, the MicroVAX II: Dynamite hardware, unusually reasonable price for DEC (except for memory, and other vendors now have memory available for half the price, but that is nothing new). The price of the operating system is tied to the number of simultaneous users, controlled by software keys. Congrats to DEC- better late than never. It should compete very favorably for a short while with the Motorola 680x0-based systems. Of course, the clock speed on the 680x0 will go up radically in the near future, but by then the MicroVAX III will be available. The big disappointment is that clustering these is not in the offing, even if the VMS 4.x architecture supports it, even if it has been done internally at DEC, even if the experimental Ethernet cluster speed matches CI-780 cluster speed. Too bad! Regardless of the lack of clustering at present, the packages are excellent, and should sell like hotcakes. They should also hurt DEC's bottom line unless they can really move enough of them. We hope you did not invest in MicroVAX I futures. A replacement for the 5/10/31 meg Winchester controller is also available. The old controller was a dog. The jury certainly isn't in yet on micro systems. DEC has a short-term winner in the chip set for the MicroVAX II. I will leave it up to you to evaluate the improved chip sets from Motorola, from Intel, from National Semi, from Inmos. We'll take some of each, thank you. VAX-16 PAGESWAPPER - October 1985 - Volume 7 Number 3 VAX System SIG Committee List VAX System SIG Committee List As of July 18, 1985 Osman K. Ahmad - TOPS-VAX Association of American Railroads Technical Center, Research and Test Department 3140 South Federal Street Chicago, IL 60616 Joe Angelico - System Management US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA. 70130 June Baker - Planning Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660 Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 C. Doug Brown - Security Sandia Labs P.O. Box 2644 Albuquerque, NM 87185 Jack Cundiff - Assistant Symposium Coordinator Muskigum College New Concord, OH 43762 James R. Cutler - Hardware Software Results Corporation 2887 Silver Drive Columbus, OH 43211 Tom Danforth - Handout Editor Woods Hole Oceanographic Institute Woods Hole, MA 02543 Doug Dickey - Data Management SIG Interface CTEC, Inc. 6862 Elm Street McLean, VA 22101 VAX-17 PAGESWAPPER - October 1985 - Volume 7 Number 3 VAX System SIG Committee List Jim Downward - Migration and Host Development KMS Fusion Inc. 3621 South State Road, P.O. Box 1567 Ann Arbor MI 48106 Dan Fleury - Education University of Hartford West Hartford, CT 06117 Dennis Frayne - Real Time/Process Control McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals In House Systems 165 William Street New York, NY 10038 Bob Boyd - Commercial GE Microelectronics Center MS 2P-04 Post Office Box 13409 Research Triangle Park, NC 27709 Don Golden - Overseas Coordinator / Publications Coordinator c/o Shell Development Company, D-2132 Westhollow Research Center Post Office Box 1380 Houston, TX 77001 Gary Grebus - System Improvement Request Battelle Columbis Labs Room 11-6011 505 King Avenue Columbus, OH 43201-2693 B. Hancock - Network Sohio Petroleum Company Two Lincoln Center 5420 LBJ Freeway, Suite 900/LB 03 Dallas, TX 75240 R. Haydt - Foreign Devices, Hardware/Software Information Consultants International Incorporated P. O. Box 2014, E. V. STA Ormond Beach, FL 32074 Jeffrey S. Jalbert - Symposium Coordinator J C C Post Office Box 381 Granville, OH 43023 614-587-0157 VAX-18 PAGESWAPPER - October 1985 - Volume 7 Number 3 VAX System SIG Committee List Ken Johnson - VAXcluster Working Group Chair Meridian Technology Corporation Post Office Box 2006 St. Louis, MO 63011 Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Bob Robbins - VAXElan Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA P. Sandwell - Graphics Seismograph Service Corporation P. O. Box 1590 Tulsa, OK 74102 David Schmidt - LUG Coordinator Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 D. Slater - Artificial Intelligence Mantech International 2320 Mill Road Alexandria, VA 22314 Louise Wholey - Languages and Tools Measurex Corporation One Results Way Cupertino, CA 95014 VAX-19 PAGESWAPPER - October 1985 - Volume 7 Number 3 VAX System SIG Committee List Douglas J. Wilson - Office Automation MIT Joint Computer Facility Room 5-137, 22 Massachusetts Avenue Cambridge, MA 02139 VAX-20 PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 456 Caption: Disable/Enable CTRL/Y during sensitive processing -- Reply to I/O # 409 Message: Use LIB$DISABLE_CTRL and LIB$ENABLE_CTRL which are callable equivalents for the DCL command SET CONTROL. See RTL documentation for further explanations. Contact: Jean-Pierre PETIT E.S.M.E. 4 rue Blaise Desgoffe 75006 PARIS FRANCE Telephone (1) 548-03-70 Date: July 15, 1985 INPUT/OUTPUT 457 Caption: Looking for enhanced version of RUNOFF Message: I have seen (somewhere in the last 2 or 3 years) a reference to an enhanced version of RUNOFF. We would be very much interested to know where this is available. Contact: Kata Weber Banner Associates, Incorporated 620 Plaza Court Post office Box 550 Laramie, WY 82070 Telephone (307) 745-7366 Date: July 25, 1985 VAX-21 PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT Pageswapper Editor's Response You probably are referring to Allan Watson's article in Pageswapper Volume 5 Number 9 (March 1984). If the two alternate versions he discussed there are not on any of the VAX SIG tapes, try the RSX SIG tapes or the DECUS library. INPUT/OUTPUT 458 Caption: LN01 Font Conversion Utility Message: We are looking for a way to convert LN01 (Xerox 2700) fonts into the new common font format used for the LN03. Is there anything available to accomplish this? We would be equally interested in a way to convert LN01 fonts into Apple Laserwriter fonts. Contact: Tim Ryan SourceNet Box 6767 Santa Barbara, CA 93160 Telephone (805) 964-6066 Date: July 25, 1985 INPUT/OUTPUT 459 Caption: Remote Printing on a VAX Network -- Reply to I/O # 428 Message: We have written a command procedure we call PRINTRMT.COM to do this. It was used successfully during our interim period of connecting DECnet to becoming a cluster. PRINTRMT.COM: 1. Copies the file to the remote node's DECNET directory. 2. Creates a batch file on the remote node that contains the commands to print on the specified device queue, deletes the printed file (remote copy) when done, and tries to delete the batch file itself when done. 3. Submits the remote batch file to SYS$BATCH on the remote node. VAX-22 PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT Contact: Jon H. Krehbiel Marathon International Oil Company Post Office Box 3128 Houston, TX 77253 Telephone (713) 629-6600, Extension 3579 Date: July 29, 1985 INPUT/OUTPUT 460 Caption: Remote Printing on a VAX Network -- Reply to I/O # 428 Message: We use a command file to do the following: 1. Copy the print file to the remote node using "COPY". 2. Create a command file on the remote node and write the desired "PRINT" commands to it using "OPEN" and "WRITE". 3. Submit the new command file using "SUBMIT/REMOTE". A listing of our command file will be sent to Mr. C. Godly. Contact: James Van Hook HOK/CSC 100 North Broadway Saint Louis, MO 63102 Telephone (314) 421-2000 Date: July 29, 1985 INPUT/OUTPUT 461 Caption: Block Letter Printer -- Reply to I/O # 398 Message: We have two programs that produce large letters, sizes are 10 x 10 and 5 x 6 normal characters. Both programs are written in Pascal. We will submit them to DECUS if more people are interested. Contact: J. Vlems Sagantec b.v. Croy 5a 5653 LC Eindhoven The Netherlands 31-40-521175/Hx 59163 VAX-23 PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT Date: July 30, 1985 INPUT/OUTPUT 462 Caption: Creating Group Logical Names at Startup Message: Changes in the way VMS 4.1 stores logical names has required changes in site-specific startup procedures that create group logical names. SET UIC won't do the trick (OLD NEWS). Avoiding discussion of the new logical name table structure, the 4.1 release notes do a good job of explaining how to get your group logicals created on startup except for one very important point. If you desire to run the LOGINOUT image to create a detached process as described in section 4.1, you will find the RUN command will not work as specified. You must provide the /OUTPUT qualifier, preferably /OUTPUT=NL:. The LOGINOUT image translates SYS$INPUT and SYS$OUTPUT on execution. This necessitates /OUTPUT on the RUN command line. Note: This newly created process can do more for you than just DEFINE group logicals. Also note: This detached process runs under the UIC specified but still retains the username of the process that issued the RUN. Our site required the detached process DEFINE group logicals, then SUBMIT/USER a job for a particular username in the group. Contact: William S. Dishman, Jr Simons-Eastern Company Post Office Box 1286 Atlanta, GA 30301 Telephone (404) 377-0711 Date: August 6, 1985 VAX-24 PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT INPUT/OUTPUT 463 Caption: Remote Printing via DECnet -- Reply to I/O # 428 Message: We have a set of programs that allows a user to print files on remote nodes and include most qualifiers, including /QUEUE=, /COPIES=, etc. It was written for VMS V3 and has not been upgraded for V4 since we now have a cluster. The sending program is not privileged so it cannot bypass file protections. Contact: Joseph G. Slater N.I.E.H.S. MD A3-O3 Post Office Box 12233 RTP, NC 27709 Telephone (919) 541-4942 Date: August 8, 1985 INPUT/OUTPUT 464 Caption: VMS Control-C status Message: Is there a way for a program or DCL command procedure to check whether control-C is currently enabled or disabled? Contact: Eric J. Wang 6100 Hillcroft Houston, TX 77081 Telephone (713) 772-3700 Date: August 15, 1985 Pageswapper Editor's Note Remember that Control/C does not get "enabled" and "disabled" in the DCL sense. By default Control/C gets treated as Control/Y and is subject to the "enable" and "disable" constraints established for Control/Y (available through F$ENVIRONMENT() calls). Within an individual program, Control/C may be intercepted and used for other purposes (q.v. MONITOR). VAX-25 PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT INPUT/OUTPUT 465 Caption: Modula-2 for VAX/VMS Message: Due to an agreement for technical cooperation, the [Modula-2 compiler for the VAX/VMS] M2VMS-compiler is now being distributed through: Logitech, Inc. Logitech, SA 165 Unversity Ave. CH-1143 Apples Palo Alto, CA 94301 Switzerland 415/365-9852 021/77-31-36 One of the reasons for this cooperation is to promote the distribution of Modula-2 compilers and to improve the documentation and customer support. Please contact Logitech for additional information. Release 3.1.9 of the Univerity of Hamburg compiler is now being distributed by Logitech. Received from Prof. Dr. Joachim W. Schmidt, currently at Johann Wolfgang Goethe-Universitdtin Frankfurt. Contact: Vladimir Ivanovic Teradyne, Incorporated 179 Lincoln Street Boston, MA 02111 Date: August 23, 1985 VAX-26 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News LUG News LUG meeting agenda are published with the understanding that Pageswapper readers will receive it too late to attend the meetings. The purpose, rather, is to share meeting topic ideas among LUGS. o Seaboard PDP-11/VAX LUG - June 19, 1985 From the Seaboard LUG Newsletter The meeting will be held in the auditorium of the RCA David Sarnoff Research Center in Princeton New Jersey; our host is Rod Borchart. o MicroVAX II The recently announced MicroVAX II raises exciting prospects by placing the power of a VAX 11/780 into a desktop environment. Some applications discussed at the field test panel in New Orleans actually ran faster on the MocroVAX II than on a VAX 11/780! This session will discuss the technical aspects of the MicroVAX II. A MicroVAX II in a world box will be available for a hands-on demonstration of VMS. (What's a world box? Come and find out!) Our Digital speakers will be Frank Quinn who is in charge of low-end workstation marketing for New Jersey and Jeff Hamburger who is a Senior Sales Representative and the NY/NJ Regional DEC counterpart for DECUS. At press time, an effort was underway to arrange for an engineer from Maynard to speak, too. o Application Profile E.K. Sam, of RCA Global Communications will describe how he has used the Fermilab software from the VAX SIG tapes to manage multiple VAX systems. This software provides three main facilities: single terminal operator control of any number of VAX systems, general system maintenance and user authorization control, and system startup from an arbitrary disk drive. o New Orleans DECUS Symposium Summary A panel of members who attended the recent Symposium will provide summaries and impressions of the week. VAX-27 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News o "Ask DEC" DECs representative to our LUG, Jeff Hamburger, will hold a question and answer session. This is your chance to ask Digital your questions about any DEC product or policy. After the meeting, interested members are invited to meet at a local restaurant for dinner and information exchange. o Dallas Fort Worth LUG - August 13, 1985 From the DFWLUG Newsletter Mike Drabicky, Editor The next meeting of the DFWLUG will be on August 13th at 7:00 pm at the Institute for Summer Linguistics. There is a map included with this newsletter to help you find your way. It includes a general "freeway" map as well as a detailed section where we will have our meeting. And again, we are trying a variety of places for our meetings, trying to be centrally located between Dallas and Fort Worth as much as possible. If you have a meeting room that we can use, or if you know of a good location, by all means get in touch with us. The basic criteria are that it's free, can hold between 50 and 75 people and has at least some a/v gear. This months meeting will feature a talk by Mike Procotio of Xyplex Corporation and is entitled the "Design of a Terminal Front End Processor with an Integrated Local Area Network for VMS". This is the same talk that he gave at the New Orleans symposium. It describes their terminal server, the protocol they developed and some of the design issues in creating such a product. Notes From Dallas-Fort Worth Recently released software includes C V2.0, VAXsim V1.1, HSC Microcode V201, Rev20 of the online diagnostics and WCS V1B for 785s. You should have received these items if you have the proper licenses for them. If not, give DEC a call and see what's holding up the show. VAX-28 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News VAXsim V1.1 is free from field service if your hardware is currently under maintenance. If that's the case, then call your field service site rep and have them bring you out a copy. Note that you should also get the manual to go along with it. If you are not under a field service agreement, it comes just like any other software product from SDC. 8600s One user reports that, under certain test conditions, a 780 started to bog down around 24 users. That's not news. What is news is that the 8600, under a similar test, didn't start to show degradation until it hit around 256 users. Interestingly, the user also commented that the HSCs showed no signs of degradation under either situation. The perceived speed increase was from 5 to 7 times that of a 780. DEC benchmarks average around 4.2 times that of a 780. Their benchmarks also show that, under tight coding conditions, speeds up to 15 times that of a 780 are possible. This was due to the highly pipelined design and strictly linear code. Word is that compilers will take advantage of this as they work 8600 optimization into their code-gen phase. Rumor mill has it that there is a new clock for the 8600 that will up performance 20-80% over current performance levels. Since DEC tends to rate its gear conservatively, it does seem possible that they could get better performance out of it by pushing the clock a bit. We shall just have to wait and see. Some of the 8600s in the field seem to be experiencing a lot of CPU board failures. Mine has been running flawlessly as have others at Sohio. You get the normal "infant mortality" plus some bugs in a new manufacturing process, but other than that, as far as I can tell the 8600s are working well. The only problems with mine were that the CPU board was not fully seated when it arrived and there were a few other loose connections. Otherwise, it has been an ideal machine. VAX-29 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News MACRO I ran into what seems to be a documentation problem with the MACRO assembler manual. Page 6-9 of the V4 manual describes the ".ASCID" directive, which generates a string descriptor for a character string specified by the user. Well, the documentation implies that the first longword descriptor information is not used and therefore is zero. This is NOT the case. The assembler places a %010e in the descriptor information word but this is not documented. This can cause all kinds of problems if (1) you assume that the upper descriptor word is 0, or (2) you use these string descriptors when calling some of the DEC entry points which do not correctly process descriptor word information. BACKUP save set names and ANSI "a" characters I recently submitted an SPR in reference to two problems with saveset names on tape. Note that if you include the underscore character "_" in a saveset name, you will not be able to select that saveset specifically with a command like: $ BACKUP/LIST MUA0:SAMPLE_SAVESET_NAME.AND_TYPE BACKUP will scan the tape and then tell you it's not there. Yet, you can rewind the tape, do a series of /LISTs to skip over unwanted savesets then leave the saveset name off and it will work okay. While this work-around will get you there, it's a pain when there are many savesets on the tape. The second problem dealt with saveset name length. Right around 31 characters or so, BACKUP will no longer handle the filenames. You can put them in all right, BACKUP will log the file backups as successful alright, but you can't read the info back. When you try, for example, to list the saveset, backup will list some of the header info for the saveset and then croak. That makes the rest of the saveset unusable. Since I was only playing around at the time, it wasn't any big deal. But if you had a couple months worth of backups with long saveset filenames, you'd be in trouble if you wanted to retrieve any of the files on those savesets. VAX-30 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News DEC's response to the SPR was that saveset names must be 17 characters or less and consist only of the ANSI "a" character set along with a few special characters. However, the BACKUP section of the Utilities Reference Manual states that saveset names can be any valid VAX/VMS file name and type. from Kevin Klughart of Dallas Semiconductor SORT I ran into something nice today. I was converting an application over from running the VMS V3 callable SORT to the V4 callable SORT. One difference with the V4 SORT is that it is initialized via a call to a new routine (SOR$BEGIN_SORT) as opposed to the old SOR$INIT_SORT. This new routine allows multiple sort processes to occur simultaneously via the use of a sort context argument on all calls. In addition, this new entrypoint forces the remainder of the sort to be handled differently. Under the V3 SORT package, you had to pass to the sorter a buffer which cotained all keys to be used and then pass the record to be sorted, appended to the first buffer. This was really a royal pain, because you also had to provide a key buffer which described exactly where in the record your key data was located. This never made sense to me, and we are fortunate that the V4 interface has been changed. NOW, YOU MUST NOT PROVIDE A KEY BUFFER IN FRONT OF YOUR RECORD WHEN PASSING IT TO THE SORT INTERFACE. THE SORTER AUTOMATICALLY GENERATES THIS FOR YOU, USING THE KEY DESCRIPTOR PASSED WHEN SORTING BEGAN. It was only because I remembered this from a previous DECUS that I was able to get my program to work correctly under V4 SORT, as the documentation on the differences seems to be missing from the reference manual. VAX-31 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News KERMIT I stumbled into this while playing around with KERMIT. As you all know, KERMIT is a file transfer protocol used to transfer data to and from various types of computer systems. The implementation recently distributed on the last DECUS tape included version 2 of IBM PC support. Well, to make a long story short, this and all previous versions did not support 19200 baud operation. The generic KERMIT supports the concept of 19200 baud operation, but the specific implementation did not. Well, I have been making extensive use of KERMIT for large file transfers, and have successfully modified the IBM PC code to support 19200 baud operation. Since the VAX supports 19200 on DZ, DMF and DMZ interfaces, it works like a charm, and transfers data about twice as fast as before. TU80s This will be of interest to anyone who has a TU80 tape drive, and may also be applicable to the TU81: There is an FCO out (FCO TU80-M00009) for the TU80 which replaces the entire door hinge assembly and replaces the gas shocks with a more stable mechanical equivalent. This fixes the problem in which the door refuses to stay open due to weak shocks. I had complained to field service about my doors and they showed up 2 weeks later with a new hinge kit - it works great and is really better than the original equipment! If you have this problem, ask your field service person to order DEC field upgrade kit EQ-01341-01. CVTLQ The CVTLQ (convert longword to quadword) instruction which does not exist under the VAX architecture can be simulated with: EMUL #0,#0,src.rl,dst.wq VAX-32 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News Since the multiplier and the multiplicand are both zero, the EMUL instruction simply sign extends the longword source operand and fills the destination quadword. This instruction can be VERY useful when manipulating quadword time values, which must have a negative sign. Macro Libraries I was somewhat taken by surprise recently when I found out that the VMS Librarian "knows" what the format of a MACRO32 statement is supposed to be when it creates a MACRO library. By default, the LIBRARIAN has the /SQUEEZE qualifier enabled, which removes trailing blanks and tabs from each line of the macro source BEFORE inserting it in the library. In addition, it strips all trailing comments delimited by a ";" from the source. This DOES have some impact if you generate and use semicolons in any macro arguments within your program. When this is the case, then a macro defined within a source program would produce DIFFERENT results from the same macro defined in a macro library and referenced at assembly time. I have run into several cases where this causes problems, especially when macros are being debugged. Removing comments from macros and/or macro libraries drastically improves the memory efficiency of VAX MACRO32 assemblies and also improves CPU utilization. When the assembler performs pass 1, all macros appear to be expanded via virtual memory. Thus, comments or blank lines contained in repeat blocks of macro expansions tend to consume large quantities of virtual memory. Unfortunately, the librarian as described above, does not completely remove all comments and blank lines from the macro source as it states in the documentation. This can cause substantial delays in assembly due to VM allocation and macro expansion. Crazy but true. Despite the documentation to the contrary, there are more permanent symbols in the VAX-11 macro assembler than the MACRO reference manual states. Specifically, each two-operand instruction (BICL2, BISB2, MULL2, etc.) also has a short form (BICL, BISB, MULL) which is equivalent. Some instructions such as BR equate to BRW. I do not believe that this is documented, but it can be seen by reviewing the microfiche. VAX-33 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News o New Mexico VAX LUG From the Meeting Notice and Meeting Minutes Donald Robbins, VAX LUG Secretary The next VAX LUG Meeting will be held on Wednesday, August 28, 1985 at the Signetics plant near the Coronado airport exit on north I-25. Agenda: 1. Election of new officers 2. Report by DEC on Broadband DECnet 3. Jerry Hanks of Sandia on his use of DECtalk in serving his constituency 4. Report on Communications by Jules Levin of LANL 5. Open discussion There will be a tour of the Signetics plant following the meeting. Alvin Andrew will be our host. At the June 24th meeting, Dr. Tony Picardi of Cortex Corporation spoke about the Application Factory. He said that many business applications can be developed from specifications and the use of tools such as the Application Factory. The payoff is increased programmer productivity (8:1 according to one estimate by Dupont). Dr. Picardi ran through a Purchase Order application, using Vu-graphs and a video projector hooked into a PRO PC. o BayVAX LUG From the VOX VAX June 27, 1985 Meeting Held at USGS in Menlo Park from 9am to Noon. There was a MicroVAX working group meeting from the end of the LUG meeting until 2 pm. VAX-34 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News There were New Orleans Symposium reports (5-10 minutes each). Session Name ------- ---- VAX Update Randy Miller VAX System Update Randy Miller VMS V4 Problem Solving Vanya Matzek Batch/Print Subsystem Overview Vanya Matzek VAXeln Technical Overview Chris Moe MicroVAX II Field Test Panel Lyn Whalen MacIntosh-VAX Connection Lyn Whalen Mike Coker of Vitalink Communications Corporation of Mountain View, gave a technical presentation on how the physical layer of an ISO 7-layer network can be constructed of multiple Ethernets. This technique is used in his company's networking product called TRANSLAN. It is a hardware/software device which bridges multiple Ethernets together at the ISO Link level and allows users connected to any LAN to access any compatible station as if it were local. It is protocol insensitive and can interconnect DECnet nodes as well as XNS, TCP/IP, or other protocol stations. August 15, 1985 Meeting The main presentation is scheduled to be from Rugged Digital, Incorporated. They are a DEC OEM which packages DEC VAX products to survive hostile environments (vibration, shock, temperature). Some of the current Rugged Digital VAXes are on helicopters, submarines, fire engines, race cars, etc. They meet most MIL specs for computers and will be available in TEMPEST secure enclosures as well. If possible, a ruggedized MicroVAX II will be on display. We will also finish up the Spring DECUS session reports. Phil Kurjan/Consilium will give a 5-10 minute summary of the VAX 8600 Performance, VAX/VMS Performance on 8600, and VAX/VMS Volume Shadowing sessions. He will be followed by our host, Bob Kibrick/UCSC describing how they use VAXes in their operation. A tour of their facility has been arranged to follow our meeting. VAX-35 PAGESWAPPER - October 1985 - Volume 7 Number 3 LUG News Those who want to park at the meeting site must fill out the enclosed coupon to get a no-cost parking permit. Exchange the coupon for a permit from the parking attendant and put the permit on the inside of your windshield. VAX-36 PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA PAGESWAPPER - October 1985 - Volume 7 Number 3 INPUT/OUTPUT Submission Form Tear out to submit an I/O item Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA PAGESWAPPER - October 1985 - Volume 7 Number 3 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - October 1985 - Volume 7 Number 3 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA