PAGESWAPPER Editor's Workfile . . . . . . . . . . . . . . . . . 2 Using MMS for Day-to-day Development . . . . . . . . 3 Letters to the Pageswapper . . . . . . . . . . . . 11 Updating Drivers For VMS 4.0 . . . . . . . . . . . 13 VAX System SIG Committee List . . . . . . . . . . 20 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . 23 LUG Agenda . . . . . . . . . . . . . . . . . . . . 30 LUG Meeting Reports . . . . . . . . . . . . . . . 31 INPUT/OUTPUT Submission Form . . . . . . . . . . . 33 System Improvement Request Submission Form . . . . 35 PAGESWAPPER - March 1985 - Volume 6 Number 9 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 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. Editor's Workfile by Larry Kilgallen, Pageswapper Editor Observant readers will note that this month's Pageswapper is a bit on the thin side. With the time saved by not having to read a thicker issue, YOU can write us an article for the next issue. 2 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development Using MMS for Day-to-day Development Charles Connell Strategic Information 80 Blanchard Road Burlington, Ma. 01803 Introduction This article will describe some of the advanced features of the DEC Module Management System (MMS). In particular I will look at two of its features that allow MMS to be used for fast development-and-test links. I will assume that the reader is familiar with MMS in general and has used it to describe the linkage of executable images. I will also assume that MMS is being used in conjunction with CMS (DEC's Code Management System). This combined usage is a good idea because links that are complex enough to warrant building under MMS probably represent systems that are complex enough to warrant control by CMS. I should point out however that the two MMS features I discuss can also be used without CMS. MMS is a tool for the automatic linking of program images. After a build routine has been described to MMS in a description file, MMS can then intelligently perform image builds using the description file. MMS is smart enough to compile only those source files that have been updated since the last compile, to library only those object modules that have changed, and finally to perform a link only if it is necessitated by new library modules. MMS works very well for creating "official" release images. It never fails to compile a source for which an include file has changed, or to make sure every library has the latest copy of everything. MMS has a drawback however in that it can be very tedious to use for day-to-day links. If a programmer is linking an image 20 times in an afternoon to test an attempted bug fix, MMS is prohibitively slow except with the smallest builds. The usual solution to this problem is to link programs the "old way" during development (i.e. by using command procedures), then to perform the final release build using MMS. Two features of MMS make it very useable for development links however. The features are the /SKIP_INTERMEDIATE qualifier, and the /OUTPUT=command_file qualifier. I will discuss them in that 3 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development order. /SKIP_INTERMEDIATE The /SKIP_INTERMEDIATE qualifier on MMS directs MMS to remove from consideration files that are not present. MMS will base its action decisions only on the dependency relationships among the files that are there. It will not fetch or create a file just because it does not find it. For this reason /SKIP_INTERMEDIATE is not generally used because it turns off some of MMS's intelligence about what is required to build a target. As will be seen however /SKIP_INTERMEDIATE can be used (with some care) to speed up the testing build cycle. An example is the following MMS description file: This shows that ACCT.EXE depends on 2 object files and a library entry. One of the object files, ACCT2, is built from a source that uses 2 include files. ---------------------------------------------------------------- ACCT.EXE : ACCT1.OBJ, - ACCT2.OBJ, - ACCTLIB.OLB(ACCT4_A=ACCT4) LINK/EXE=ACCT ACCT1, - ACCT2, - ACCTLIB.OLB/LIB ACCT1.OBJ : ACCT1.PLI ACCT2.OBJ : ACCT2.PLI, ACCT2_INC.PLI, ACCT2_INC_2.PLI ACCT4.OBJ : ACCT4.PLI ---------------------------------------------------------------- Assume we call this MMS description file with the /CMS qualifier. NO/SKIP_INTERMEDIATE (the default) will make sure that the sources in the working directory are up to date with the sources in CMS, that the working directory's objects are up to date with the working sources, that the library modules are as new as the object files, and finally that the working directory's executable is as new as all the objects and library references. /SKIP_INTERMEDIATE works very differently. 4 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development - If there are no sources in the working directory, MMS will compare the sources in CMS with the working objects. If an object is older, MMS will fetch that CMS source, and compile it. Otherwise MMS will not fetch a source from CMS. (Without /SKIP_INTERMEDIATE MMS will fetch all missing sources.) - If there are no working sources or objects, MMS will compare the CMS sources with the executable. If it finds a CMS source that is newer than the executable it fetchs that CMS source, compiles it and links the executable. (As above, MMS normally requires the working directory to have all sources and objects. With the /SKIP_INTERMEDIATE qualifier however, the sources and objects can be absent.) In short, MMS "skips" consideration of files that are not present. This ignoring of non-existent files is exactly what can be used to speed up routine links, but can also cause some problems if the user is not careful. - Suppose that there are no .PLI files in the working directory when you run the MMS file above. Assume there is a new version of ACCT2.PLI in the CMS library. MMS will compare that source with its object file, and see that the object is old. It will fetch ACCT2.PLI from CMS, and try to compile it. The compile will fail however because the include files are not present. - Suppose that there are no .OBJ files in the working directory. Assume that you have updated ACCT1.PLI recently. MMS will see that the ACCT1 source is newer than the executable (it "skips" the object), and compile ACCT1. This will call for a link of ACCT.EXE because there is a newer object. But the link will fail because the other object files don't exist. Obviously one must exercise some caution in the use of /SKIP_INTERMEDIATE. It will prove useful however for improving MMS build times. 5 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development General MMS Guidelines Before looking at how to link with /SKIP_INTERMEDIATE, there are some general guidelines that will help when developing under MMS. The suggestions below about how to use /SKIP_INTERMEDIATE will be based on this structure. - Put all the object files into one or more libraries. The dependency rule for the executable image should be a list of object module references in some libraries, rather than a list of object files themselves. The link line for the program then becomes a list of object libraries with one /INCLUDE statement for the main module. - Put all include files into one or more text libraries. The dependency rule for an object file then lists the source file, and optionally a series of modules in text libraries. You must then specify that the compile for this source references those libraries. You can do this either with an explicit compile action for that source, or by redefining the compile action so that all compiles use those libraries. This is shown in the example below. - Keep a directory where production builds of the software are done. That directory retains all the libraries, object and text, and all the MMS description files for developers to reference. You may delete source and object files from here after a build. - Use the command CMS MODIFY LIBRARY /REFERENCE_COPY=[dir] to establish a source reference directory. CMS will automatically keep a copy of the latest source version of every element in that directory. This makes it very easy to inspect or "fetch" a source file during development. Do not make this directory the same as the build directory described above. This might seem tempting, but it then becomes impossible to build older versions (CMS CLASSes) of a system. We consider a modified (and more realistic) version of the example description that implements these ideas. ------------------------------------------------------------------ # # Set the suffix precedence list. # .SUFFIXES 6 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development .SUFFIXES .EXE .OLB .OBJ .TLB .PLI .PLI~ # # How to put a .PLI file into a text library. # .PLI.TLB IF "''F$SEARCH("$(MMS$TARGET)")'" .EQS. "" THEN - $(LIBR)/CREATE/TEXT $(MMS$TARGET) $(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE) # # How to compile a PLI program using the include library. # .PLI.OBJ PLI $(PLIFLAGS) $(MMS$SOURCE) +ACCT_INC.TLB/LIB # # Dependency and action for the executable. # ACCT.EXE : ACCTLIB.OLB(ACCT1), - ACCTLIB.OLB(ACCT2), - ACCTLIB.OLB(ACCT4_A=ACCT4) LINK/EXE=ACCT ACCTLIB.OLB/LIB/INCL=ACCT1 # # Dependency for each of the parts of the executable. # ACCT1.OBJ : ACCT1.PLI ACCT2.OBJ : ACCT2.PLI, - ACCT_INC.TLB(ACCT2_INC=ACCT2_INC.PLI), - ACCT_INC.TLB(ACCT2_INC_2=ACCT2_INC_2.PLI) ACCT4.OBJ : ACCT4.PLI ----------------------------------------------------------------- Looking at the dependencies for ACCT.EXE we see that it is built from 3 object modules, one of which has a different entry name than its source file name. The dependencies for ACCT2.OBJ show that it comes from a source file of the same name, and two include files in a text library. Since .PLI is not the MMS default extension for text modules (TXT is), we have to tell MMS how to go from a .PLI source to a .TLB (text library) target. This is the second section of the description file. 7 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development The third section redefines the built-in PLI compile rule to use the include text library. Using /SKIP_INTERMEDIATE During Development The following steps will allow you to perform a reasonably quick development cycle build using an MMS description file like the one above. 1) Go to the directory where you will be doing the development. It should not be either the production build or the source reference directories described above. 2) Set your CMS library to the desired one. 3) From the build directory, copy in the object and text libraries that you will be using. Also copy in the MMS description file for the image you will be modifying. You do not need any individual source or object files. 4) If you are changing the description file to use an additional (new) source file, make that change in the MMS file. 5) If you are changing an existing source file, no change is needed to the MMS description file; just fetch the source file from the reference directory (or from CMS). 6) Make the needed source file changes in the development directory. 7) Call MMS with a command line like this: $ MMS/CMS/DESC=ACCT.MMS/VERIFY/SKIP_INTERMEDIATE ACCT.EXE 8) Test your program. 9) Repeat steps 6 thru 8 as needed. With the /SKIP_INTERMEDIATE qualifier MMS will not fetch source files from CMS just because they are missing from the working directory. Instead, MMS will look only for source files that are newer than the target. The new sources (in this case the one you have modified in the development directory) will be compiled, put in the object library, and the program will be linked. 8 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development Refering to the example above, suppose that you want to change ACCT4.PLI. You copy into a development directory ACCTLIB.OLB, ACCT_INC.TLB, ACCT4.PLI, and the MMS file itself. After changing ACCT4.PLI you call MMS with a command line like the one shown. MMS will compile ACCT4.PLI, insert it in ACCTLIB.OLB, and link ACCT.EXE using the updated library. It will not complain about the fact that most of the sources and objects are missing. This technique works very well if you are making normal source file changes. If you are changing something that is "underneath" a source file - like an include file - you have to do a little more. /SKIP_INTERMEDIATE turns off MMS's intelligence to some extent. If you want to modify an include file and have MMS make all the changes that follow from it, you must manually fetch the source files that will need to be compiled. MMS will detect the new include file and will update the text library, compile the proper sources, and link the image. It will not know to fetch the sources that depend on the include file however. You must do this manually - but it only has to be done once. Doing a /SKIP_INTERMEDIATE build as described above can make development under MMS quite easy. You only need to copy into your development directory the (hopefully) small number of libraries that the image uses, modify the source under development, and call MMS to do the build. MMS pays attention only to the source you have changed. The next MMS feature can speed up the building cycle even more. /OUTPUT=command_file If you are making more than a few cycles of the above steps, MMS is performing the same decision making and actions every time. You can speed things up considerably if you allow MMS to make a command file of those actions. First get MMS to work for a development build as described above. Then on one of the MMS runs, add the /OUTPUT qualifier to the MMS command line: $ MMS/CMS/DESC=ACCT.MMS/VERIFY/SKIP_INTERM/OUT=DO.COM ACCT.EXE MMS will write a DCL command file into DO.COM (or any other name). The command file will contain all the steps MMS took to perform the build. This can include compilations, update of libraries, and the final link. 9 PAGESWAPPER - March 1985 - Volume 6 Number 9 Using MMS for Day-to-day Development You can now run just the command file instead of MMS each time you want a build. This command file will run a great deal faster than MMS because it contains only actions and no "MMS thinking". NOTE: Make sure that you have exactly the build situation you want when you use the /OUT feature. The command file you get will only be valid for that situation. If you want to make changes to a different source file, DO.COM will not work correctly for that new build. You can get further speed improvement by editing the command file MMS produces. It tends to add a few extra lines that are not required, such as checking for the existence of libraries. By removing these lines, you will have the fastest possible build. 10 PAGESWAPPER - March 1985 - Volume 6 Number 9 Letters to the Pageswapper Letters to the Pageswapper February 15, 1985 Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 We are interested in the CERBERUS package featured in the January issue of the PAGESWAPPER -- in the article titled 'Privileged and Execute-Only Command Procedures'. Has this software been released, is it on the DECUS tape to be released from the Anaheim symposium, or in other words, what am I missing?? June Templin Computing Services Goshen College Goshen, IN 46526 Pageswapper Editor's Response I do not know what mechanisms are involved in submitting something to the European contest or whether the software is already on the SIG tape. The author offered the whole source for publication in the Pageswapper, but that is contrary to our policy. 11 PAGESWAPPER - March 1985 - Volume 6 Number 9 Letters to the Pageswapper February 7, 1985 Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 Please try to include an index page in each Pageswapper. We copy these for wide distribution at TRIUMF so people can know what is available of interest to them. David Preston Gurd University of British Columbia TRIUMF 4004 Wesbrook Mall Vancouver, B.C. V6T 2A3 1. Editor's Snappy Response Assuming you mean the table of contents, we ALWAYS do (TRY to include one). 2. Editor's Polite Response For anyone who similarly keeps separate files of tables of contents, and who does not wish to wait for the next SIG tape, here is the table of contents we missed: Editor's Workfile . . . . . . . . . . . . . . . . . 3 VAX Interrupt Response Time and Other Myths . . . . 4 Bug Fix for the FERMILIB library . . . . . . . . . . 6 Micro VAX Disk Controller Problem . . . . . . . . . 8 Fast Boot 730 with RA81 and FPA . . . . . . . . . . 9 Commercial Working Group Update . . . . . . . . . 11 Privileged and Execute-only Command Procedures . . 13 VMB Register Inputs . . . . . . . . . . . . . . . 16 VAX/VMS Optional Software Cross Reference Table . 20 MicroVMS Optional Software Cross Reference Table . 30 Letters to the Pageswapper . . . . . . . . . . . . 33 The S and M in System Manager . . . . . . . . . . 34 Calling Pascal from FORTRAN and Vice Versa . . . . 38 VAX System SIG Committee List . . . . . . . . . . 44 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . . 47 LUG Agenda . . . . . . . . . . . . . . . . . . . . 55 LUG Meeting Reports . . . . . . . . . . . . . . . 56 INPUT/OUTPUT Submission Form . . . . . . . . . . . 58 System Improvement Request Submission Form . . . . 60 12 PAGESWAPPER - March 1985 - Volume 6 Number 9 Updating Drivers For VMS 4.0 Updating Drivers For VMS 4.0 B.C. Dow-Pleines Calma 1565 Barber Lane MS BL2C Milpitas, CA 95035 A BOF - Birds of a feather - session was held at the fall DECUS on the topic of "Updating Device Drivers for Version 4". The session format was a talk by a DEC speaker followed by a question and answer period. My notes from the session appear below. Some symbols that were in SYS.STB, e.g. $BADEF, $PCBDEF, etc, have been moved out of SYS.STB inorder to make the map and STB files shorter. If you want to use the definitions in PCBDEF, BADEF, etc, you will now have to include the definitions in your program. The speakers preference is to have the definitions in the driver anyway, otherwise the macro assembler will leave extra space in generated instructions that you don't really need. Disk Drivers In V.3 disk drivers base their device dependent UCB at UCB$W_BCR+2. In V.4 the local or device dependent UCB is located at UCB$K_LCL_DISKLENGTH. If you are working with the MSCP server, or writing code the MSCP can use, you will have to have the following functions: IO$_PACKACK IO$_UNLOAD IO$_AVAILABLE All of these functions must have EXE$LCLDSKVALID as the last FDT routine. This means it is an executive FDT routine. All this deals with a new UCB field called on_line_count. (UCB$W_ONLCNT) This new field sets things up so that the first entity to packack the drive really does it. And all the rest of the entities, the 2nd, 3rd, and the 4th all succeed immediately without doing anything, without even going to the start IO routine. The last entity to either unload or available a disk drive is the one that actually does it, all the rest don't. Fundamentally, if you have the MSCP server running on a given post, you have both the local driver, which is a local mount, and wants to do a packack on the drive, and you have the MSCP 13 PAGESWAPPER - March 1985 - Volume 6 Number 9 Updating Drivers For VMS 4.0 server which wants to do one too. And all of this is designed so that they don't overrun each other. Tapes There is a new symbol to tell you where the base of your device dependent UCB is. It is UCB$K_LCL_TAPE_LENGTH. The other thing is if you have written a tape driver to unload then there is this device dependent field usually called UCB$L_devname_RECORD, that is supposed to be a count of the number of entities that you have traversed since the beginning of the tape. It is the sum of the number of records or filemarks traversed. If you want to play with the magtape ACP, you will have to have this field. In version 3 it had to be at a specific offset from the base of the UCB. As there was some "Black Magic" read hooks to allow the magtape ACP access to this field. Now the field is in a device independent area. Not totally independent of everything, but independent of all other kinds of tapes. It is called UCB$L_RECORD. So you have to change your tape driver. You won't have to change it again, you'll just have to reassemble and relink. Terminals The internal interface between terminal port driver and the terminal class driver was changed. Warning, this is not documented in V.4. Speaker also conveyed the observation that the differences between the V3 and V4 Guide to Writing I/O Driver manuals were very little. Question and Answer Period Q: Why did IPL$_SYNCH change? A: IPL$_SYNCH changed because the lock managher became distributed and had to do fork like things at IPL 8, indirectly through the port driver. Also, we did not want to fight the overhead through the distributed lock manager having to fork down to come back up to synch. 14 PAGESWAPPER - March 1985 - Volume 6 Number 9 Updating Drivers For VMS 4.0 Q: Has anything changed for the general type device driver? A: All you should have to do is reassemble and relink to pick up the new definition structures. Q: What about the rumor of an availability bit problem? A: There is a DEV$M_AVL bit in UCB$L_DEVCHAR. This bit has to be turned on ahd this can be done in a dpt store macro. If the bit is not on you might not be able to get to your device. But it is a fairly simple condition to get the driver to turn it on. There is an implicit belief, at least during field test two (FT2), that if you had failed to turn the bit on in the driver, you could use the set device available command. Unfortunately, that command really only works for disks. The amusing part of it was that if you tried using it in FT2 you got something about device is not a mailbox. Speaker believes the "device is not a mailbox" part has been fixed. Q: If I'm writing a driver, should I set this bit. A: Yes Q: What looks at the bit? A: The assign channel system service looks at the bit, if the bit isn't set it won't assign the channel. (There was a question from the audience whether allocate looked at it, answer was the speaker doesn't think so.) Q: New structures in V.4, what about object control? A: The ORB, Object Rights Block,(or something of that nature), it has to do with hanging access control lists on devices. Basically, some of the accessibility information that used to be in the UCB, e.g. the owner and the protection masks, have been moved to the ORB. (Comment from the audience: The ORB is documented in the driver book, but it doesn't describe it there.) (Comment from speaker: The ORB is related to hanging access control lists on devices; it assumes that what you do in your driver is to put together a very basic one and then in your startup.com, or wherever you do a set device/available and that handles it correctly.) Q: What about the TODR privileged register changes? 15 PAGESWAPPER - March 1985 - Volume 6 Number 9 Updating Drivers For VMS 4.0 A: Any privileged register that doesn't exist on all VAX processors has probably gotten its symbol changed. TODR does not exist on a Micro VAX. That was the motivation for the change. Basically, TODR is a processor specific register now, and dependence on it makes you processor specific. We changed the name to remind you of that fact. The new name probably has a processor attached to it. That also means that there are individual PRDEF'S, ($PRDEF macros), for the various processor types. Q: Will a driver break because of the change in IPL$_SYNCH A: No. Q: What about contention and timing? A: The timing will be slightly different. You've got a little more contention for that single IPL, the contention that used to be at IPL 7. The critical thing to remember is that access to IPL 7 always occurred because someone raised from the lower IPL. It was not possible to fork directly to it. Except the timer routine forked directly to it, and still does. As a practical matter, you can't have new fork threads that are in your way on the queue, but you may stay in the queue a bit longer because some process based activity got in your way. Q: Is there a presentation on the timing studies like the ones Steve Forgey used to do at the symposiums? A: No. After the IPL was changed in the base VMS system the interest in possible effects died out quickly. It is not a big deal. There was a lot of panic when the idea was first suggested. A lot of effort was put into coming up with other ways to solve the lock manager problem. The idea was not to move drivers to 8, but rather to make IPL 7 a true fork IPL, and simply to make the CI port driver run at that. That idea ended up being rejected because the CI port driver and the UDA port driver have to coexist. But the UDA driver has to run at whatever IPL locks the Unibus IO database. After worrying for a month and a half, that the system would come to a grinding halt, the system was booted and no one was the wiser. IPL 7 and 8 are close to each other. And all you've done is added the possibility that what would have run at 7, and 7 is usually gotten to by coming up from below often in a process context because you want to do something scheduling like, all that this has done is to increase the probability that some process scheduling activity is going to temporarily block a fork thread that might otherwise have executed immediately. And temporarily is probably temporarily because the thing doing the scheduling probably changed some process state, and was never very significant. 16 PAGESWAPPER - March 1985 - Volume 6 Number 9 Updating Drivers For VMS 4.0 The other thing is maybe they don't collide that often. Q: What about new PID's, what type is accessed by the driver? A: There are two kinds of PID's. You're getting the internal PID which looks like the PID you've always known. Q: What about the other type of PID and the driver? A: The most it could possibly be bothered with is if it wants the other one, or something, then it probably has to be in an FDT routine. The field definition didn't change, PCB$L_PID is still the internal PID. The external PID is in another field called PCB$L_EPID. The PID changes are intended to make it possible to do some of the process creation and manipulation services cluster wide. So they function at a somewhat higher layer. Obviously, if you are doing an IO request, you are on a node, you are doing the IO request for that node, and it doesn't really matter about the clustered aspects of the process. Q: A routine for Micro VMS grabs physical contiguous memory, does it grab it off of the free page list? A: Speaker does not know precisely what implementation is being used today. He knows what the original implementation was. The original implementation was to grab that much nonpaged pool that was physically contiguous and use it, otherwise, set it aside in a litte internal buffer and the go try it again. And to do it until you got enough contiguous pages. I suspect that another mechanism has been implemented. The implementation I'm familiar with is late FT1, early FT2 time frame. Q: I want to double map a user buffer into system space. What is the best way to get system page tables. A: Possible approach - look at code in sysgen and see how they do it. Q: Why aren't RXO2's supported. A: Because the MSCP protocol does not support the density of the drive. There is no way to support the notion of doing an initialize/density = single. The best we can do is give an illegal IO function error, which doesn't really set it. Q: What about something similar to the MSCP for tapes? 17 PAGESWAPPER - March 1985 - Volume 6 Number 9 Updating Drivers For VMS 4.0 A: There is something similar to MSCP for tapes, and it is called TMSCP. It is done by the tape class driver, the TU81 AND TA78 speak it. In fact, all tape drives that you see in the future will be based on the TMSCP. The TU81 is available now. Q: What about the software? A: What about a tape server? That's on the "boy wouldn't it be nice if we could do that" list. There are a few thing in front of it, like being able to dual port a UDA disk between two processors. Q: Will some of the IRP and UCB fields be shuffled around? A: Yes Q: So if you depended on two fields being contiguous you could experience trouble. A: Some fields have been moved to the ORB. We generally haven't removed. The fields related to device protection have been removed and moved into a new structure called the ORB. General Comments Version 4.0 is a build from source, the patches for VMS version 3 have been incorporated into the source. One of the things that is on the top of the list to do for version 5 development is to increase the IRP$W_STS field. It has sixteen bits in it that are all used. We anticipate needing some more bits. We may shuffle the IRP around to get some more room. Another difference between version 3 and 4 is that we shuffled the UCB so that DEVCHAR and DEVCHAR2 are now contiguous. Q: We have a driver that uses the techinque of inserting timer queue entries. We drop to IPL 6, then raise to synch and insert or remove timer queue entries. Is there a problem with the IPL change? A: What IPL do you drop to 6 from? 18 PAGESWAPPER - March 1985 - Volume 6 Number 9 Updating Drivers For VMS 4.0 Q: 8 A: The critical thing is that IPL$_SYNCH has moved from 7 to 8, if you want you no longer have to drop to 6 and then raise back up to 8 to do that. (Questioner. Timer queues are manipulated at 8 therefore forking is unnecessary) Q: Are class-port interfaces going to be documented? A: The intent was to document the terminal class driver - port driver interface in V.4. It did not get done. In the terminal world, the breakage between V.3 and V.4 is related to the handling of DMA type operations, in that most of the rest of the interface is the same. What happened in V.3 was that the DMA was on the class driver side and should have been on the port side. It is now on the port side in. Q: Booting with XDELTA works on the Micro VAX, but no documentation can be found. A: Same as for 750, 730. 19 PAGESWAPPER - March 1985 - Volume 6 Number 9 VAX System SIG Committee List VAX System SIG Committee List As of December 12, 1984 Joe Angelico - Volunteer Coordinator and System Management US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA. 70130 June Baker - Planning Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 C. Doug Brown - Security Sandia Labs P.O. Box 2644 Albuquerque, NM 87185 Jack Cundiff - Assistant Symposium Coordinator Muskigum College New Concord, OH 43762 James R. Cutler - Hardware Software Results Corporation 2887 Silver Drive Columbus, OH 43211 Doug Dickey - Data Management SIG Interface CTEC, Inc. 6862 Elm Street McLean, VA 22101 Jim Downward - Migration and Host Development 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 20 PAGESWAPPER - March 1985 - Volume 6 Number 9 VAX System SIG Committee List 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 Mark Graff - TOPS-VAX M/A-COM Linkabit, Incorporated 3033 Science Park Road San Diego, CA 92121 Gary Grebus - System Improvement Request Battelle Columbis Labs 505 King Avenue Columbus, OH 43201 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 21 PAGESWAPPER - March 1985 - Volume 6 Number 9 VAX System SIG Committee List 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 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 22 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 375 Caption: Software Documentation System Message: I am interested in an software documentation system which allows the intermixing of graphics and text (flowcharts, block diagrams, state charts, text) for VAX/VMS. It would be used for documentation and update of all life cycle products, and the output file should be compatible with the CMS tool. Contact: M. Reshef M.B.T. Post Office Box 105 Iehud, Israel Telephone 3-357111 x 520 Date: January 27, 1985 INPUT/OUTPUT 376 Caption: Switching between Single and Distributed System Disks Message: After I make my decisions for configuring my cluster, am I committed to staying with my system disk set-up (single or distributed) or can I switch between the two? Contact: Anita R. Girton Dataram Corporation Princeton Road Cranbury, NJ 08512 Telephone (609) 799-0071 Date: January 30, 1985 23 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT INPUT/OUTPUT 377 Caption: Arbitration of Unibus Devices Message: Does the lock manager in VMS V4.0 only perform arbitration on Massbus devices or can a Unibus device also be set up as a multi-ported disk and have its arbitration performed by the Lock Manager? Contact: Anita R. Girton Dataram Corporation Princeton Road Cranbury, NJ 08512 Telephone (609) 799-0071 Date: January 30, 1985 INPUT/OUTPUT 378 Caption: Modula-2 Compiler for VAX/VMS -- Reply to I/O # 364 Message: A Modula-2 compiler for use on VAX/VMS systems may be licensed and purchased from: Dr. Jaochim W. Schmidt Fachbereich Informatik Universitat Hamburg Schluterstrasse 70 D-2000 Hamburg 13 Federal Republic of Germany The cost is nominal and installation is relatively easy. The distribution includes a command definition file which allows the compiler to be invoked in a manner consistent with standard VMS compilers. Contact: Alan Hargrave Baylor University Computation Center Post Office Box 6187 Waco, TX 76706 Telephone (817) 755-2711 Date: January 31, 1985 24 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT INPUT/OUTPUT 379 Caption: Reading IBM 3470 Exchange Floppies Message: We are looking for a program to run under VMS which reads IBM 3470 Exchange format floppies (8 inch, single density, 128 byte sectors). Contact: Bob Huckins Nuclear Data Golf & Meacham Roads Schaumburg, IL 60196 Telephone (312) 884-3659 Date: February 4, 1985 INPUT/OUTPUT 380 Caption: Archival and Retrieval System -- Reply to I/O # 363 Message: Univault is a "user-friendly" archival and retrieval system running on VAX/VMS. It was developed by Otago University in New Zealand. Contct Enzed Systems, 336A Village Lane, Los Gatos, CA 95030. Contact: Ron Lane TYC Services 19000 Bear Creek Road Boulder Creek, CA 95006 Telephone (408) 395-0532 Date: February 4, 1985 INPUT/OUTPUT 381 Caption: Archive System for VAX/VMS -- Reply to I/O # 363 Message: Archiver is an easy-to-use archive and retrieval package available from us. Storing seldom accessed files on tape can be initiated by both users and the system manager. The software maintains an on-line directory of all files archived for each user, and provides the ability to retrieve and/or remove files from archive storage. Archiver is distributed with an automatic archival option which allows disk files to be moved to tape by system managers based on an algorithm of their own choosing. 25 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT Contact: William J. Nally Commercial Technology Services Strategic Information 80 Blanchard Road Burlington, MA 01803 Telephone (617) 273-5500 Date: February 5, 1985 INPUT/OUTPUT 382 Caption: Size of a Process Message: I am looking for a program that will tell me the size (P0 space) that another process occupies. Contact: Charles Schrey Moore Business Forms 300 Lang Boulevard Grand Island, NY 14072 Telephone (716) 773-0611 Date: February 5, 1985 INPUT/OUTPUT 383 Caption: Multiple Block Reads Message: I am looking for a Fortran or Macro program that will read in n 128 work blocks in a single system call. Contact: Charles Schrey Moore Business Forms 300 Lang Boulevard Grand Island, NY 14072 Telephone (716) 773-0611 Date: February 5, 1985 26 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT INPUT/OUTPUT 384 Caption: Computer Algebra -- Reply to I/O # 280 Message: REDUCE is now available for VMS from: Anthony Hearn Rand Corporation 1700 Main Street Post Office Box 2138 Santa Monica, CA 90406-2138 (213) 393-0411 The package includes enough of the LISP to run it on VMS. There are more powerful packages available for VMS as well. There are two forms of MACSYMA (the grandaddy of computer algebra systems) available: 1) Symbolics Corporation in Cambridge, MA, sells the MIT-endorsed version. 2) "DOE-Macsyma" can be obtained from the Argonne National Lab National Software Distribution Center in Argonne, Illinois. 3) SMP is available from Inference Corporation in Los Angeles, California. Contact: Jake Moskowitz CBS Technology Center CBS Incorporated 227 High Ridge Road Stamford, CT 06905 Telephone (203) 327-2000 Date: February 5, 1985 INPUT/OUTPUT 385 Caption: VAX to IBM File Transfer Message: I need to talk to anyone using an IBM Device Attachment Control Unit (DACU) for VAX to IBM file transfer. Contact: James Preciado Composition Systems, Incorporated 570 Taxter Road Elmsford, NY 10523 27 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT Date: February 8, 1985 INPUT/OUTPUT 386 Caption: Generating Breaks from Communication Devices Message: We have an 11/750 with a DZ-11, a DMF32 and a DMZ32. We use the VAXNEt modem program to communicate through the communication ports. We would like to generate break as part of this process. Does anyone have any experience with this? Contact: Paul Wilfong VERAC, Incoporated 9605 Scranton Road, STE500 San Diego, CA 02121 Telephone (619) 457-5550 Date: February 9, 1985 INPUT/OUTPUT 387 Caption: Disk Usage by Directory Tree Message: Does anyone have an efficient and fast way to get totals of blocks allocated per disk directory tree for each UFD? I am currently using: "$ DIR/TOTAL/OUTPUT=filespec DISK:[*...]". Contact: Tom Irwin Schlumberger Well Service 1801 California Street, Ste 4700 Denver, CO 80202 Telephone (303) 297-7519 Date: February 11, 1985 INPUT/OUTPUT 388 Caption: Massbus Load Evaluation -- Reply to I/O # 348 Message: The program BUSUSE will provide a Monitor-like display of Massbus utilization. It is described in papers written by the undersigned published in the Spring 1983 and 1984 DECUS Symposia Proceedings. The program is available on the Spring 1984 Decus US VAX SIG tape. 28 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT Contact: Richard Wrenn Washington University 660 South Euclid, MS 8094 St Louis, MO 63110 Telephone (314) 362-3354 Date: February 28, 1985 29 PAGESWAPPER - March 1985 - Volume 6 Number 9 LUG Agenda LUG Agenda The following LUG meeting information is 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 Dallas Fort Worth LUG - April 8, 1985 From the DFWLUG Newsletter The presentation will be given by Mary Fuller of DEC's Storage Architecture Group in Colorado Springs. We have made arrangements for her and some of her group to come to Dallas and talk about what DEC is doing with their disk products, where they are going and the kind of performance we can expect in the not too distant future. She also said that she would talk about their optical disk products at least in general. 30 PAGESWAPPER - March 1985 - Volume 6 Number 9 LUG Meeting Reports LUG Meeting Reports o New Mexico VAX LUG - February 11, 1984 From meeting minutes in newsletter Donald Robbins, VAX LUG Secretary The meeting was called to order by the chairman, Paula Capps at 12:05. II. Application Development Project The first speaker was Dan Ebersen of Touch Technologies of Escondido, California (near San Diego). He related his company's experiences with development of an incremental compiler for applications development of a query language using Level I ANSI Basic. One of the initial goals was modularity. VMS allows sub-directories to a great depth. The programmers had their modules placed in a number of sub-directories. The overhead to gather what was needed for linking was very time-consuming. By changing to a single directory, much time was saved. If speed is of interest, one needs to place timers in the code to find where the time is going. One then examines these parts to perhaps find a more efficient strategy. VMS permits many ways of doing things. The programmer needs to be aware there may be better ways of doing something. III. A Cluster Jerry Hanks of Sandia's Plant Engineering told of his experiences lashing together a system to serve the Plant Engineering enterprise. This organization is populated by managers, secretaries, engineers and support technicians. Is it possible for all to find happiness with computers? The answer is a definite maybe. 31 PAGESWAPPER - March 1985 - Volume 6 Number 9 LUG Meeting Reports The machine hardware chosen was the Cluster and the traffic director chosen was All-In-1. Menus were developed under this umbrella for all the special interest groups within the plant engineering community. For instance, Mass-11 was selected as the word processing package, though others are allowed. There are many different terminals available and supported. Jerry was very high on the LAT-11 running on the PDP11/34. These machines are quite available at Sandia as organizations have up-graded. LAT is the Local Area Transport software and gives one lots of options, and is reliable (a prime consideration to plant engineering). LAT-11 on the PDP11/34 will support 64 lines. Jerry mentioned LAT boxes, which are coming out, that will support 8 lines. Jerry was also enthusiastic about DECtalk. For instance, if someone doesn't "ready" the printer after stopping it, a program, using DECtalk, can notify someone - perhaps even the last person who printed, via telephone, that the printer needs help. Thus DECtalk can function as a surrogate operator. It is a pleasure to hear of an activity like Jerry's. He is striving to bring people into the computer ark, if not two by two, at least one by one. 32 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: PAGESWAPPER Editor, DECUS, 249 Northboro Road (BPO2), Marlborough, MA 01752, USA 33 PAGESWAPPER - March 1985 - Volume 6 Number 9 INPUT/OUTPUT Submission Form Tear out to submit an I/O item PAGESWAPPER Editor DECUS 249 Northboro Road (BPO2) Marlborough, MA 01752 USA 34 PAGESWAPPER - March 1985 - Volume 6 Number 9 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) 35 PAGESWAPPER - March 1985 - Volume 6 Number 9 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 USA 36