PAGESWAPPER CONTENTS Editor's Workfile . . . . . . . . . . . . . . . . . 3 Newsletter Distribution Change . . . . . . . . . . . 3 Labeled Tape Shops Unite in New Orleans . . . . . . 4 Toward a Comprehensive Backup SIR . . . . . . . . . 5 Life with V4 . . . . . . . . . . . . . . . . . . . . 7 IT'S IN THE MICROFICHE... . . . . . . . . . . . . 17 VAX/VMS Version 4 Upgrade Notes . . . . . . . . . 18 (THE (LINKED LIST)) . . . . . . . . . . . . . . . 24 VAX System SIG Committee List . . . . . . . . . . 30 INPUT/OUTPUT Submission Form . . . . . . . . . . . 33 System Improvement Request Submission Form . . . . 35 PAGESWAPPER - June 1985 - Volume 6 Number 12 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. 2 PAGESWAPPER - June 1985 - Volume 6 Number 12 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor Again at the Spring 1985 Symposium which just ended in New Orleans we accepted electronic mail input to the Pageswapper. Unfortunately, two hours before then scheduled close of the display area on Friday there were system troubles which prevented retrieval of the input to magtape. At the scheduled time to pack the machines onto trucks, there is no reason to try any longer to repair the difficulty, so to the best of my knowledge the input people sent is on an RA81 on a DEC truck somewhere, and according to one telling of the tale that truck may not get unpacked until Fall DECUS in Anaheim. Suffice it to say that I am not certain if or when I will be able to retrieve the submissions sent at the symposium, so submitters may want to try again. In the case of Stanley Rose's article on labeled tape support, I have tried to paraphrase what I think he was going to say. Newsletter Distribution Change Effective with the issue which is mailed in August, the Pageswapper will be fastened together with all other US DECUS SIG newsletters and mailed to all those who subscribe to any newsletters. For renewals and future subscribers there will be a single price for all SIG newsletters, but that price will be quite close to the previous price for the Pageswapper alone, so for Pageswapper readers it should be no problem. The one trick is that the issue mailed in August will be labeled as the September issue. Thus there will be no Pageswapper labeled August, but you will continue to get one per month. By the way, I was approached by several people at the Symposium in New Orleans who said they did not receive one or more copies of the Pageswapper to which they were entitled. Anyone with such a subscription fullfillment problem should contact the DECUS office in Marlboro Massachusetts immediately. Waiting to discuss it at symposia only reduces the chances that a replacement for the issue you are missing can be located. 3 PAGESWAPPER - June 1985 - Volume 6 Number 12 Labeled Tape Shops Unite in New Orleans Labeled Tape Shops Unite in New Orleans by Larry Kilgallen Well, it wasn't exactly a throng to dwarf the Mardi Gras parades, but users from several sites which try to run VMS in a labeled tape shop environment were brought together by Stan Rose of Bankers Trust. The eventual goal is to produce a white paper for the VAX Systems SIG Commercial Working Group to present to DEC regarding user needs and present inadequacies of VMS in a labeled tape environment. (For those who don't use the same lingo, by "labeled tape shop" I mean one where the management goal is to enforce a policy that all tapes have ANSI standard tape labels and no two tapes have the same volume ID). Ultimately almost everyone with aspirations to run a labeled tape shop would like to have a computerized list of what all the tapes are (most likely stored on disk, rather than on one of the tapes). The requirements for such a list vary from site to site, however, and designing a mechanism which would satisfy everybody might take a long time, bordering on forever. One possibility which might lead to a quicker solution would be some minor VMS changes which include a hook so that user sites can design their own tape cataloging system. For instance: 1. Parameters passed to MTACCESS site-specific routine would be augmented to include ACL and ARB (This has already been requested by Doug Brown of the Security Working Group) 2. No volume id changes without privilege (This would require changes in INIT, ACP and drivers to cover both regular and foreign mounts) 3. Requests for particular tape volumes would be passed through a site-specific routine (This would require changes in INIT, ACP and BACKUP) Items 2 and 3 would only apply to sites choosing to declare themselves as labeled tape shops, perhaps through a system parameter or perhaps by providing the site-specific routine. At any rate, your own suggestions are encouraged; address them to: Stanley Rose Bankers Trust Company 130 Liberty Street New York, NY 10006 212-250-2320 4 PAGESWAPPER - June 1985 - Volume 6 Number 12 Toward a Comprehensive Backup SIR Toward a Comprehensive Backup SIR Andy Davenport Computing Services Harvey Mudd College Claremont, CA 91711 (714) 621-8006 This article is intended to be the first cut at providing a common forum for a consolidated SIR (System Improvement Request) for the VAX/VMS BACKUP utility. It is hoped that this letter will evoke additional input in the form of refinements and/or additional requirements. The ultimate goal is an SIR that defines the next round of major enhancements to BACKUP. General guidelines are that requests should not be too obtuse or unacheiveable in the 6 to 12 month time frame. Guidance about the general future direction of the product are not out of order. For example it is probably useless to ask that BACKUP be enhanced to serve as a full blown automated archiving system, but not unreasonable to reiterate the desire for this kind of facility in the future. Also, suggestions should not be too trivial. This should not be used as a forum for minor gripes like how the /REWIND qualifier should default etc. Listed below are the features that I would like to see. I have heard these same requests mentioned by others. If you have other suggestions to add (or want to take issue with mine) please write to the Pageswapper. o Command Orthogonality - We wish to be able to read files from one save-set, and write them directly into a second save-set. We can already move files from disk to disk, from disk to save-set, and from save-set to disk. A significant need exists to be able to copy from save-set to save-set. This would allow entire save-sets (or extracts thereof) to be copied while retaining the enhanced integrity features of backup save-sets. - Software distribution media could be copied to system without the need for mounting entire distribution kit or restoring save-set to files-11. - Software vendors could keep a standard distribution kit on disk as a single save-set file and produce distribution media (full or extract) as required. 5 PAGESWAPPER - June 1985 - Volume 6 Number 12 Toward a Comprehensive Backup SIR - This is of tremendous value to sites with a large (780) VAX and several microVAXes connected via ethernet. A 5.25 in. hard disk on the microVAX would easily be contained in a save-set on an RA81 on the 780. This part (disk to save-set across decnet) is possible now. What would add to this is the ability to write the save-sets now residing on the RA81 to tape in such a way as to make it appear that the original backup of the microVAX disk had been directly to the tape. Note that the COPY command is not the solution since it is not as robust as BACKUPs tape writing methods. A further enhancement of this is to teach BACKUP to directly read and write SYS$NET. (See comments below) o Infinite Inclusion and Exclusion - The /INCLUDE and /EXCLUDE functionality should be extended to allow specification of files containing specifications of included or excluded files so that the limitation imposed by DCL command line length is eliminated. o Callable BACKUP - BACKUP should be split into a sharable image and a "front-end" command reader image similar to the way EDT was broken up. The sharable image would allow (DEC written or user written) utilities to read and write backup save-sets. This is a first step towards an archiving system which uses BACKUP format for storage. A note about BACKUP over DECNET is in order. Many users (myself included) would like to see backup enhanced to allow backup of a remote disk over a DECNET network. There are two fundamental problems. The first is that tape drives are not supported by DECNET. This is a problem for the group responsible for the development of DECnet rather than for the VMS group and it should be noted that these groups are not necessarily the same. At present, only disks are accessible over DECnet, and then only if mounted /SYSTEM. The notion of ALLOCATing, MOUNTing, and performing I/O to a remote tape unit is for a future phase of DNA to embrace. The second problem with remote BACKUP is that BACKUP uses its intimate knowledge of the files-11 disk structure to achieve greater efficiencies. Backup in many cases bypasses the normal file access methods to achieve higher performance in operation. BACKUP reads the INDEXF.SYS and BITMAP.SYS files directly when performing an /IMAGE backup and must have the disk mounted /FOREIGN (when restoring /IMAGE). Its methods are not supported by DECNET and so backup and/or restore of a remote disk is not supported by BACKUP. A good work-around would be made possible by the save-set to save-set enhancement suggested above. A process running on the remote system (the one with the disk to be backed up) runs the BACKUP 6 PAGESWAPPER - June 1985 - Volume 6 Number 12 Toward a Comprehensive Backup SIR program reading from the disk and writing the save-set file to the SYS$NET device. On the system with the tape drive, BACKUP is used to read the save-set from the remote task and write the save-set to magnetic tape computing CRCs and writing XOR blocks as for any save-set written to tape. The disadvantages are of course increased complexity, the required involvement of two systems, and the somewhat higher resource cost of running two BACKUP images for each operation. Life with V4 Stephen Simm, Phoenix Data Systems 80 Wolf Road - Sixth Floor Albany, NY 12205 VAXVMSRL4 The VMS 4.0 release contains many useful features and some wonderfully devious new pitfalls. What follows is a short description of some of the useful features (even some DEC doesn't document) and several preventive measures to allow system managers to leave before 9pm. (maybe even in daylight) Tuning VMS 4 SYSGEN/SYSBOOT The system parameters have seen extensive changes. And some parameter setting modfications were even for the better. But a number of other changes run a close second to most better grades hair removal products. Hard page faults (faults to disk) are expensive on any operating system. Overall increases in the size of VMS version 4 have made hard faults more likely -- VMS now occupies roughly twice as much physical space as the previous version. Our site runs a mix of jobs ranging fromprocesses that never leave MAIL to interactive processes occupying ten megabytes of virtual address space to batch jobs requiring up to one megabyte 7 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 of physical memory. And our site encountered a memory limitation on several of the VAXen. Several indicators can tell you a curable memory limitation exists. SHOW SYSTEM indicates high fault rates and/or working set sizes exactly at the value of the process WSQUOTA. SHOW MEMORY indicates an unreasonably large number of pages on the free list. And the MONITOR PAGE will frequently show high overall fault rates. (Your job, Mr Phelps, is to find out whose "fault" it is...) The combination of high fault rates AND a large free list can be counteracted by decreasing the PFRATH value and increasing the WSQUOTA and WSEXTENT limits on the faulters. However if free list memory is being used and processes are still faulting you have: Too Much Going on at once: See if the numbers of simultaneous processes can be reduced. Often reducing (or consolidating) the number of active slots in a multi-queue batch system will actually increase overall performance. (Four one-hour jobs might take five hours to run -- when run multi-threaded) Total Physical Memory Insufficient: Logically this is an easy one. Add more. Pragmatically (or financially) it can be more difficult. Consider redistribution of jobs to background batch queues. Poorly Designed Applications: The application using the huge array that makes accessing every 1000th element so easy can also cause a page fault for every record access. The local variety of record/array faulting applications make very pretty faulting patterns on the "V" option of the SHOW PROCESS/CONTINUOUS command. Also slow response. Another common applications design problem involves multiple simultaneous active copies of the application. Consider sharing code whenever more than one copy of an application is active at any particular time. Global sections allow savings of space by sharing the physical memory between 8 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 processes. See the Linker reference manual. You Outgrew Your System: And who ever thought that day would come. Attempt to rearrainge the work load -- and file away the names of the users complaining of bad response -- for use in the "Let's get more horsepower" meeting. The following is a list of the most common factors that can be modified for performance gain (or loss) with a short explaination of each: o PFRATL (page fault rate per ten seconds -- low) Controls when VMS will remove pages from a process's working set. Under VMS version 3 this parameter provides a convenient way of redistributing pages between processes. Under version 4 it provides a convenient method of increasing the total number of painful pagefaults. o PFRATH (page fault rate per ten seconds -- high) adds WSINC pages into a process's working set. I've had reasonable luck setting this parameter to to 50 - 80 range (5 to 8 faults per second) This parameter is tied to the authorization per-process limits on working sets and to the GROWLIM, BORROWLIM and WSMAX parameters. o WSMAX (Working Set Maximum) Should be set to the largest (reasonable) number of pages any process will use. The key here is the word "use". o VIRTUALPAGECNT (the largest amount of per-process virtual address space) Minimum value should be 8192 or dumpfile size in pages plus 3000 if you use Analyze/System -- whichever is larger. Setting the value too high wastes non-paged memory. o MAXPROCESSCNT (The total number of process slots available) Should be set low -- but the NOSLOT messages mean you've gone too far. o BALSETCNT (The number of slots available in the balance set) Should be set low -- but not so low as to start swapping processes out unnecessarily. 9 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 Disk Throughput: A number of disk-related items can affect system performance -- and some of the problems are even easy to fix. The bottleneck can be the file system throughput. Several of the more common fixes for increasing performance follow: o RMSEXTENDSIZE (the number of blocks allocated to a disk extent) The default value of 0 tends to fragment the disk -- a FORTRAN compiler installation left the compiler in 45 pieces on a known (and formerly) contiguous disk. The version 3 default of 80 has worked nicely. This parameter is affected by the disk clustersize setting. o Disk Clustersize (The granularity of disk allocation) The default value of three seems to waste about one quarter of the disk space on our system -- since we operate with only a few files larger than a couple of blocks -- this is based on checks with the DIRECTORY/SELECT=SIZE=(MIN:x,MAX:y)/TOTAL command. o Disk Fragmentation (How many pieces your files are in) If files are fragmented (data files that are frequently extented and disks containing certain unnamed relational database packages) performance can be improved by making a stand-alone image backup and restore. For the curious the DUMP/HEADER command can be used to check individual files. For those sites with the VAX/RSX package the MCR PIP Dcu:/FR command is also useful. The local rule of thumb: If you can't remember the last time -- it's time to pack packs again. o Authorization Quotas on Working Sets: VMS 4 is also quite sensitive to the working set quotas in the user's authorization record. WSDEFAULT, WSQUOTA and WSEXTENT should be increased from the values used under version 3 -- 200, 400 and 1000 are in use locally. This step has improved individual and overall performance on our systems. Most processes with the older limits spent most of their time faulting. 10 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 Standalone Backup Kits on Disk: VMS Gurus Please Ignore: Neophyte System Managers beware -- the VMS gurus all know system disk backups must use /IMAGE or standalone backup to be able to be restored (using standalone backup) and bootstrapped. Those online backups are great for saving files -- but then they just don't bootstrap so well... The command procedure Sys$Update:StaBackit.Com is used to create a standalone backup kit. Consider the command: @Sys$Update:StaBackit Sys$SysDevice: [SysE.SysExe] The p1 parameter (Sys$SysDevice:) is the target device and the p2 parameter ([SysE.SysExe]) is the target directory. The example creates a stanalone kit on the system disk. A secondary root on the system disk (or any other disk) can be bootstrapped using a bootstrap file you've modified and saved on your console storage media. The change sets the value in processor register r5 to %xE0000000. The high byte is translated into the ascii representation of the hex character and tagged onto the string "SYS" to find the root directory. (Guess what that means the default root is...) ! ! V750 DM0 BOOT COMMAND FILE - DM0E.CMD ! Bootstraps from DMA0:[SysE.SysExe] ! D/G 0 1 ! cartridge disk D/G 1 FFE000 ! base of unibus i/o page D/G 2 3FF20 ! csr address offset D/G 3 0 ! controller unit = 0 D/G 4 0 ! boot block lbn (unused) --> D/G 5 E0000000 ! SOFTWARE BOOT FLAGS ... D/G E 200 ! address of working memory + ^x200 LOAD VMB.EXE/START:200 ! load primary bootstrap START 200 ! start primary bootstrap ! The command procedure Sys$Update:DXCopy.Com is one method used to copy files to and from the console storage. Exchange is another. (on a uVAX or V750 console no media is needed -- just follow the triple console carets with the command B/E0000000) 11 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 EXCHANGE This utility has replaced the old RSX11 FLX method of getting at a console storage device. Using the format of the TU58 cassette and the EXCHANGE /START qualifier the files needed for a bootstrap can be located (almost) under the read head after a directory scan is completed. And the console does not cache the directory data. A TU58 is viewed as a four track device with blocks numbered from 0 to 127 in track one, 128 to 255 in track two, 256 to 383 and 384 to 511 in tracks three and four. A file search brings the heads (slowly) past any blocks between the start of the track plus 10 and the begining of the requested file. Up to a maximum of 117 blocks (and a coffee break) may pass before the requested file is located. This behaviour is caused by the combination of a lack of directory caching (during the bootstrap), high speed track-to-track access, VERY LOW speed in-track access and the location of the directory data in blocks 6 thru 9. The following short command procedure sets up a VERY FAST WARMSTART bootstrap for a TU58 cassette: $! Connect the console storage device $ Run Sys$System:SysGen Connect Console Exit $! $! CSA1: is the front driver on V725, V730, V750. $! CSA2: is the side drive on V725, V730. $ Mount/Foreign Csa?: $! $! /Cache is undocumented, but speeds up directory access time. $ Exchange/Cache ! ! create a file to hold the contents of the cassette... Initialize/Create/Allocation=512/Segments=2 CONSOLE.TU58 Mount/Virtual TU: CONSOLE.TU58 Mount Csa?: Copy Csa?:*.* TU:/Log Dismount Csa?: ! Initialize/Segment=2/Volume=RT11 Csa?: Mount Csa?: ! ! the following assumes DEFBOO.CMD is 1 block long and that ! two segments have been allocated to the cassette directory. ! Find the current size with DIRECTORY TU: Copy TU:DEFBOO.CMD CSA?:Start=10/Log Copy TU:VMB.EXE CSA?:Start=11/Log Copy TU:BOOT.EXE CSA?:/Start=138/Log ! 12 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 ! and copy the rest over - Expect three NOCOPNODEL warnings ... Copy TU:*.* CSA?:/Log/NoDelete ! Copy/Boot CSA?:/all BOOT.EXE ! V725/V730 ONLY ! Dismount CSA?:/all/conf Dismount TU: Exit $! $! On a V750 >ONLY< execute the following: $ Run Sys$System:WriteBoot Csa1:Boot58.Exe 1 C000 $! $! After a bootstrap using this cassette make SysStartup.Com $! submit a batch job that Executes the DCL command: $! Mount/System/Foreign/NoWrite/NoAssist Csa?: $! Use CSA1: on a V750 and CSA2: on a V725/V730. The Two results $! of this mount are that the cassette is rewound and that $! non-privileged users cannot "accidently" write on the console $! media. $! $ Dismount Csa?: $ Mount/System/Foreign/NoWrite/NoAssist Csa?: $! Use of the beginings of other tracks for a full COLDSTART bootstrap can be made by extrapolating on the placements shown here -- or if there is enough interest I'll return your magtape, RX01 floppy or RX50 (that was sent with a stamped, addressed, return envelope) with a copy of a (trivial) routine that creates a speed-optimized bootstrap. The routine supports a specific combination of IDC, UDA, AZTEC and FPA peripherals -- though any combination can still be slow-booted. But please -- SEND NO TU58's (they're too slow). I'll also drop some other types of software and trivia weirdness (as is) on the media. Fixing F$GETSYI() This function returns all sorts of useful trivia. Unfortunately where it finds some of the information is not documented. The DECnet Nodename, Node Number and Area number are retrieved from SYSGEN parameters (obviously the first place everyone looks for this sort of thing) o SCSSYSTEMID (System Communications Services System ID) The DCL F$GETSYI lexical function pulls the DECnet AREA and NODENUMBER rabbits out of this hat. Should be set to AREA * 1024 + NODE -- since most networks are in 13 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 area one you don't even need to multiply. (you remember multiplication -- what was done before bitshifts were invented...) o SCSNODE (SCS Nodename) Is the polite name you refer to your system by. The DECnet (if you have it) node name should use the same name -- since F$GETSYI thinks SCSNODE is the same as the DECnet name. Setting Default Terminal Characteristics: VMS assumes certain characteristics for terminals. Most sites have a large terminal startup file that resets the defaults at bootstrap. If you've settled on a standard configuration setting for the terminals the SYSGEN (what else?) parameters TTYDEFCHAR and TTYDEFCHAR2 can be modified to hold the default values for the local site. The following two examples are for illistration only. They are intended only for use on our site. Consult Volume 4c/SYSGEN for a description of the bit masks. TTYDEFCHAR set to %x180012B0 translates to the following: Set Terminal TXcu:/TTSYNC/HOSTSYNC/LOWERCASE/WRAP/SCOPE/LINE=24 TTYDEFCHAR set to %x2980712 translates to the following: Set Terminal TXcu:/AUTOBAUD/SETSPEED/LINEEDIT/INSERT - /FALLBACK/DISCONNECT/APPLICATION/ANSICRT/ADVANCED/DECCRT Image Accounting Made Small: A sneaky method of monitoring image usage can be found in the INSTALL processor -- if you want to keep tabs on specific images -- install using the /Accounting qualifier. (VMS 4.1+) This saves on accounting file disk space usage while maintaining a profile on specific images. 14 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 Lost In Space: The VMS 4 upgrade procedure left contents of two system directories lost in the file structure on several of our systems. The new directories work perfectly -- but like a ghost -- the older versions of Sys$Message and Sys$Library appear in the directory Sys$SysDevice:[SysLost] when the command: ANALYZE/DISK/REPAIR Sys$SysDevice: is requested from a username with BYPASS privilege enabled. We deleted the outdated contents of [SYSLOST] after sorting through the contents. Logical Name Tables: Digital manuals show wonderful methods of loading logicals into the tables of other groups. But one of the easiest uses the /Table= qualifier. Define/Table=LNM$Group000002 SHORT LONG This define command equates the string SHORT to be the same as the string LONG in the logical name table of group [2,*]. Two comments: First a word of warning -- the first member of the group to log in creates the group table if it does not already exist. Don't expect the table to be in place prior to the first login (read: during startup) -- unless you've created it. And second: You can access the logical names of other groups or the job tables of any processes -- which can be both interesting and annoying. (Depending on whose table gets accessed.) If you're not sure about the table names -- SHOW LOGICAL/TABLE=* tells all. DMF32 (XGDRIVER) Synchronous DECnet DECnet via the DMF32 synchronous port can actually be made speedy with the combination of a high clock rate modem eliminator and additional NCP-allocated buffers on the DECnet to DMF32 connection. $ Run Sys$System:NCP ! (from an appropriately privileged username) ! Use DMF-0 for the first DMF32 port, DMF-1 for the second ... ! SHOW KNOWN CIRCUIT CHARACTERISTIC if you're not sure ... 15 PAGESWAPPER - June 1985 - Volume 6 Number 12 Life with V4 ! SET CIRCUIT DMF-x STATE OFF SET LINE DMF-x STATE OFF ! DEFINE LINE DMF-x RECEIVE BUFFER 8 SET LINE DMF-x RECEIVE BUFFER 8 ! SET LINE DMF-x STATE ON SET CIRCUIT DMF-x STATE ON ! EXIT $! You've just raised the buffer count from the default 4 to 8. $! We've run counts as high as 12 with limited additional speed. Be careful on VMS version 3.5 -- it contained some bugged code in the driver that caused problems linking DMF32's via modems. And VMS 3.6 caused a system-wide hang (a mutex wait on most of the VMS system) when the DMF32 circuit stayed in the "state -starting" mode a little too long. But the VMS 4.0 and 4.1 XGDRIVERs work fine. Correction: Nobody commented on this one -- was everybody sleeping? In the December 1984 article I mistakedly refered to using the WRITEBOOT utility on a V730 to correct a bad bootblock problem. WRITEBOOT only works for the V750 -- EXCHANGE (VMS 3 used RTB.EXE) is the correct bootblock "writer" utility for the V730 (and V725 and V78x). 16 PAGESWAPPER - June 1985 - Volume 6 Number 12 IT'S IN THE MICROFICHE... IT'S IN THE MICROFICHE... VAX Systems SIG Internals Working Group Barbara Dow-Pleines Calma 525 Sycamore Drive MS C51N Milpitas, CA 95035 This is a new column of articles sponsored by the Internals Working Group. The purpose of the column is to inform the reader of hints, kinks, and curious items in the current version of VMS. The articles are intended to be informative and helpful, providing information obtained from experience. Submissions from readers are welcomed and encouraged. This article provides an introduction to the microfiche. For version 4.0, the microfiche set contains 439 pieces. Whether or not you get the microfiche with your system depends on what type of license you bought. There is an index to the fiche, which is always on the last piece in the set, for V 4.0, this piece is number 439. The microfiche contains the listing files and the map files for the "supported" operating system code. The word supported means that VMS documents the program or utility and that it is intended for general use. There are some utilities on VMS that are not supported, hence not listed in the fiche. For example, HEXZAP. The routines and programs are listed alphabetically and grouped by functionality. This means for instance, that most of the code needed to boot the machine is grouped under on heading. INDENT 4;Besides an index on the last piece of microfiche, there is a small index located in the bottom right hand corner on each piece of the microfiche. The index is a letter and number map. For each frame of the microfiche there is a corresponding letter and a number, i.e. F5. Columns are designated by numbers, and rows are designated by letters. If the listing xblob.mar started at location F5, then the listing starts in column 5, and row F. To find a listing, start with the index on the last piece of microfiche. Then find the number of the piece of microfiche were the listing begins, for instance 200. Also copy down the column and row locations. Next place piece 200 in the microfiche reader, move to the correct column and row location and start your task. TRIVIA QUESTION: Excluding FORTRAN and DCL, name three languages that the VMS 4.0 source code is written in. 17 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX/VMS Version 4 Upgrade Notes VAX/VMS Version 4 Upgrade Notes James M. Bishop Physics Department University of Notre Dame Notre Dame, IN 46556 22-May-1985 These notes have been accumulated thru the process of upgrading our VAX 11/780 operating on an RM80 system disk, with an RK07 test and backup system disk. This covers VMS V4.0 and 4.1. These notes are the outgrowth of a presentation to the DECUS Michiana LUG. Be sure to read thru the Release Notes in Volume 1 of the large manuals, the small Guide to Software Installation, and the small Guide to System Management and Daily Operations. The VAX/VMS Systems Dispatch and the VMS V4 Update Seminar Notes are also useful. The SYSTEM account must have some increases in the UAF quotas before you can do the upgrade. See the Software Installation Guide, page 5-2. You also need 9000 free blocks to do the upgrade. This can be a problem on small disk systems. I did it on an RK07, without going to a "tailored" system, which means one where some system files are on one disk and some on another. If your system is not now tailored, you may not be able to go to a tailored system during the upgrade, depending on your distribution media. You may want to do it after the upgrade. See the Guide to System Management and Daily Operations. It will be most helpful if you can bring up a test system on an alternate disk. This way you may test your command files without having your users complaining that things do not work. You can bring the alternate system up briefly to test the system and command files, then shut it down and reboot your V3.x system and make the corrections to the command files, etc., on your V3 system. An alternate test system will be especially important if you have special device drivers or drivers that need patches from the manufacturer. I. Possible problems during the upgrade The system gets INT-STK INVLD error during the final boot and goes to console prompt. The SYSGEN parameter LRPCOUNT may be too small. 4 is the minimum that will boot. You may get some later system degradation and eventual crashing if it is too small, especially if you have DECnet. 8 or 10 may be a good 18 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX/VMS Version 4 Upgrade Notes value to use for LRPCOUNT. If your system crashes on the final boot from the upgrade, use a conversational boot and look at LRPCOUNT and change it upward before continuing the boot. See the Jan. 1985 VAX/VMS Systems Dispatch. It seems that no matter what it was set to, the upgrade reduced it to 2, and thus crashed. It did it for me on both upgrades, but not for the other 11/780 at Notre Dame. This may depend on the values in the files that are used by AUTOGEN, as opposed to what is in the parameter files used in the boot. It is supposed to be fixed with V4.1, but unless DEC repackages the upgrade with V4.1, it won't fix 4.0. The system boots but gets errors because it cannot open or extend the ERRLOG.SYS file. It tells you that you must specifically start error logging later. This may occur if you have disk quotas active. Disk quotas are turned off for the upgrade and then turned back on. VMS V4 uses more disk space. Also, there appears to be double counting since at least 2 system directories are rooted directories out of SYS$SYSROOT: as well as direct entries into the Master File Directory. With Version 4, the sum of both entries is apparently added to the quota. As a result, you can get (as I did) 62,000 blocks owned by the system on an RK07 which has 54,000 blocks space on it. Fix this by increasing the quota for [1,4]. By the time I upgraded the RK07 disk to VMS V4.1, the quota was showing correctly at about 49,000 blocks, as it did when the disk was mounted as a user disk under our RM80 system. II. Changes that may affect how your system comes up SYSTARTUP.COM is replaced by a dummy. You will have to put your site specific startup commands back in. The reason is that several of the normal functions in SYSTARTUP.COM are now done differently. The Queue Manager must be started. Install has a new command format. Images linked with the default /TRACEBACK will no longer install with privilege. These images must be relinked /NOTRACEBACK. If you have images that cannot be relinked that need privilege, see the Jan. 1985 Systems Dispatch for a patching command file. If Batch and Print queues do not start, go look at your SYSTARTUP.COM. You must now start the Queue Manager before you can start the queues: $ START/QUEUE/MANAGER. You must now say INIT/QUEUE/DEFAULT=FLAG, not INIT/QUEUE/FLAG as in V3. Also, you can no longer give defaults on generic print queues. In V3 you could specify /FLAG on a generic queue, but it did not do anything; now it is illegal. You may now initialize and start the queues in one command, which works whether the queue was pre-existing or not: INIT/QUEUE/START. STARTUP.COM now calls a site specific configuration command file SYCONFIG.COM. If you want something other than AUTOCONFIGURE ALL for SYSGEN, you must put the (e.g.) AUTOCONFIGURE 19 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX/VMS Version 4 Upgrade Notes ALL/EXCLUDE=(MS) or whatever into SYCONFIG.COM along with setting the symbol STARTUP$AUTOCONFIGURE_ALL == 0. Otherwise, STARTUP.COM will redo the AUTOCONFIGURE ALL. This way you do not have to modify STARTUP.COM when you want to not configure all devices. SYS$SYLOGIN must be defined as an executive mode logical name: $ DEFINE/EXEC/SYSTEM SYS$SYLOGIN SYS$MANAGER:SYLOGIN.COM. You may want to change the SYSGEN parameter PFRATL if your system has been using 0 for the value. Otherwise your system may bog down with processes that do not decrement the size of the working set. There are several new Sysgen parameters. As far as I have seen, most can just be left at the DEC defaults. There is a known bug in the V4.0 disk XQP code that replaces the V3 ACP, which can cause processes or the file system to go into a loop. It is supposed to be fixed in VMS V4.1. There is a post-4.1 replacement available as an SPR fix, that does fix the problem. This XQP fix also apparently corrects a sometimes problem of disk corruption on 750's which have been upgraded without upgrading the TU58 boot tape. Non-DEC device drivers must be recompiled and relinked. Several symbols have been redefined or must be explicitly defined. Check the Release Notes, section 4.5, and the VMS V4 Update Seminar Notes. Old versions will not only not work, you cannot even connect the old drivers. If you need patches to the drivers for non-DEC devices, they will need updated by the manufacturer. Note that our local DEC Field Service says that the Emulex controller for the Fujitsu Eagle disk has some PROM problems under V4. The manufacturer should eventually have fixes available. If you have a non-DEC DMF-like terminal board, you may experience hung terminals that will not let you log on. It is related to the treatment of XON-XOFF by the YCDriver and the DMF boards. There is a patch in the March 1985 issue of HARDCOPY magazine. Also note that DMF lines (at least with our Emulex DMF board) do not autoconfigure to be DMA lines, unlike V3. You must add /DMA to your terminal definitions in SYSTARTUP.COM. Since /DMA is ignored on DZ lines, it is not clear if VMS is using the forced /DMA or ignoring it. Also our local DEC Field Service says that the Able DMF-like terminal board has some PROM problems. The system libraries now come compressed. This saves space, but incurs a significant processing overhead whenever a library is accessed. You should be sure to decompress the libraries if you have enough disk space to do it. You cannot do the decom- pression while users are accessing the libraries. A full help for all the language elements is now optionally available with V4 for most of the DEC languages. 20 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX/VMS Version 4 Upgrade Notes III. Changes that may affect the way some utilities or command files work UIC's may now be alphanumeric, and DIRECTORY/OWNER returns alphanumeric UIC's, as do the lexical functions and system services. Thus if you have a command file or program that looks at UIC's, you will have to change it. The alphanumeric labels used in the UIC's are the login account for the group and the username for the member. System UIC is [SYSTEM] and users are like [HEP,BISHOP]. DISKQUOTA accepts either the new form or the old numeric form when setting or modifying quotas. There seems to be no way to force the system to return numeric UIC's. EDTINI.EDT files may no longer work. If you have an EDTINI file like that described in the DEC Professional about 2 years ago, you may find that EDT leaves you in one of the macro buffers, without ever loading the file to be edited. Somehow, DEC changed the way EDT handles the SET ENTITY WORD command in an EDTINI file, such that the old way aborts the processing of the EDTINI file. You must now define the end of word delimiters by using the SPECINS function to enter the actual character into the SET ENTITY WORD command in the EDTINI file. A DEC SPR response claims that the C; must be replaced by INSERT on a separate line, to make the command work. (I think we tried this and found it to fail, but have not tried it again.) Also in EDT, the GOLD <- and GOLD -> are no longer defined for a VT100. They were defined but not documented in V3 to move the whole image left or right by 8 characters. If you want these, you must specifically define them in your EDTINI. If you have DEC GIGI's, you will no longer need to have the special setup and download, which no longer work correctly anyway, since Version 4 VMS and EDT recogize the VK100 (GIGI) as a supported device, although it is not documented as such in either the SET TERMINAL command or in the I/O Users Guide. The GIGI defined as a VK100 works very nicely in EDT and in command line editing. However, MAIL (and who knows what all else) does not recognize the GIGI by default. One option is to create command files to switch between VT100 for MAIL and VK100 modes for EDT. The other option is to define VK100 support in the new Screen Managment Facility to be the same as VT100 support. If you want to use the keypad in application mode from DCL, you must have the GIGI defined as a VT100, since DCL does not force a VK100 into application mode when you enter SET TERMINAL/APPLICATION_KEYPAD. These options may also work for certain Televideo terminals that do not work correctly as VT100's under V4. When you change terminal type, VMS sometimes sets the terminal to /NOLINE_EDITING. If you switch between VT52 and VT100 modes or between VT100 and GIGI modes, you may need to redo the SET TERM/LINE_EDIT. This may also apply to the keypad mode. 21 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX/VMS Version 4 Upgrade Notes If your SYLOGIN.COM sets up certain terminals, and you have enabled virtual terminals, you must use 'F$GETDVI("term_name","TT_PHYDEVNAM") to translate to physical device name. Enabling of virtual terminals is described only in the Release Notes, section 4.6.2, and in the I/O Users Guide. The virtual terminal number VTAxxx counts upward continuously from each system boot and thus can get quite large. The Accounting utility gets only the virtual terminal name, making accounting by terminal useless in V4. If you used the command file to get MAIL to use EDT with an initializer file in V3, be sure to change both lines calling EDT in the V4 MAILEDIT command file. The logical name MAIL$EDIT must be defined to use the MAILEDIT command file. There are now 2 uses of EDT in Mail, which conflict on the use of the MAIL$EDIT logical name. Define MAIL$EDIT to use the V3 equivalent invocations of EDT in Mail; this disables the new V4 direct calling of EDT. MAIL does not work for terminals it does not recognize. All you get is the $ prompt after a second or 2 wait. FTx terminals and the GIGI (VK100) are not recognized. You must either redefine your terminal types to something MAIL recognizes or define the terminals for the Screen Management Facility (SMG) which Mail uses. You will need a special version of MAILEDIT.COM for GIGI's, to switch between VT100 for MAIL and VK100 for EDT, if you do not use the SMG approach. SMG is incomplete in VMS V4.0, but seems complete in V4.1. If you send files to your VAX from a micro or another computer using the CREATE command to enter the text, you may have problems. Control characters, in particular and , are no longer passed to the file on the VAX unless you set the terminal line to /PASSTHRU before sending the file. You must reset the line /NOPASSTHRU when done for proper interactive behavior. RUNOFF has several changes in the way it operates. If you want chapter paging, you must now explicitly give the .CHAPTER command, even if you may not want the chapter heading, which you cannot then suppress. There seem to be some interactions between the Test Page function and the Paragraph function, not all of which are understood. A change that affects any post-processing of the .MEM files is that the over-print line comes out first, followed by the main text line. Also, the explicit carriage control in the .MEM file is all at the end of the line, instead of some at the end and some at the beginning as in V3. Indexing and Contents are now much simpler and easier to use, but the commands are completely different from V3. The new privilege GRPPRV gives access to files via the SYSTEM protection field to users with this privilege in the same group as the file owner. This allows certain SET FILE operations to work on group-owned files. But as a result, giving a file 22 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX/VMS Version 4 Upgrade Notes protection G: may not be enough to protect the file; give it S: protection also. The system manager must remember to get BYPASS privilege before all Backups, if this was not done before. If you have V3 images linked with DEBUG, they may not work in batch in V4, failing with a SECTION TABLE FULL error. Images linked under V4 with DEBUG do work in batch. The failing images still work interactively in V4.0. These images work sometimes under VMS 4.1 in batch, but we have not determined what the conditions are that make them work. If you have the option, it is best to relink with V4. The SYE utility to read the error log has been replaced with ANALYZE/ERROR_LOG. Note that ANALYZE/ERROR_LOG defaults to a FULL listing of the errors. If you want the old Roll-up summary, you must request ANALYZE/ERROR_LOG/NOFULL/SUMMARY. 23 PAGESWAPPER - June 1985 - Volume 6 Number 12 (THE (LINKED LIST)) (THE (LINKED LIST)) The Newsletter of the DECUS AI Working Group ...it's the real thing FROM THE EDITOR Welcome to the second issue of (THE (LINKED LIST)). This issue is admittedly much less extensive than the last offering, but the demands of my job and the time I've devoted to preparing presentations for DECUS New Orleans have precluded me from presenting an exhaustive newsletter this month. Like the premier issue, this iteration of the AIWG newsletter contains material that I have written and published in THE DEC* PROFESSIONAL Magazine. As I just received an advance copy of the April PAGESWAPPER today (29 April), the lack of reader input to (THE (LINKED LIST)) is understandable. Hopefully, this situation will change as DECUS members become aware of our fledgling newsletter and begin to contribute their ideas, suggestions, articles and reviews for publication. I had planned to write a preview of the AI-related sessions scheduled for presentation at the upcoming New Orleans DECUS US Symposium, but arrived at the conclusion that the symposium would be history by the time this PAGESWAPPER reached its reading audience. However, it appears that AI will be well represented in New Orleans - a record number of sessions with an AI slant are being sponsored by VAX, DMS and MUMPS people. Because of the timing of the symposium conflicts with the deadline for the June issue of THE PAGESWAPPER, you can expect to see an after-action report on AI in N.O. in the July issue. In the meantime, I hope you enjoy the article and book review in this month's issue. QUOTE OF THE MONTH This month's example of parser insanity was gleaned from a common road sign and submitted to (THE (LINKED LIST)) by Matt Matthews of the AI Working Group. SLOW CHILDREN PLAYING The information provided by this statement is good as far as it goes, but it poses an obvious question: "Where do the fast kids play?" 24 PAGESWAPPER - June 1985 - Volume 6 Number 12 (THE (LINKED LIST)) FEATURE ARTICLE The following article owes its origin to a news brief I read some time ago about AI doings in Japan. Knowing a little bit about cognition, thinking processes and the structure of the mind, I decided to investigate Japan's latest proposal for new computer architectures in greater detail. I'll let you make up your own minds as to whether or not this scheme has any potential for success. And Now, The SIXTH Generation? As discussed in last month's (LINKED LIST), it seems as if AI, expert systems and the Fifth Generation have replaced "user-friendly" as the computer buzzword(s) of choice. Suddenly, everyone knows that AI is becoming a reality, expert systems are commercially viable and the Fifth Generation is just around the corner. Articles touting AI and the Fifth Generation are now appearing in such mainstream publications as Barrons, Business Week, Newsweek and Working Woman. Books on AI, grist from the mills of luminaries and unknowns alike, are proliferating, and some of the titles even appear to be selling. As a result, just about everyone who reads contemporary literature or frequents the local newsstand has at least a vague knowledge of artificial intelligence and the coming generation of supercomputers. So here we are, poised on the verge of the Fifth Generation - a computer generation characterized by new architectures, new programming languages and techniques, and processing speeds that are several orders of magnitude beyond the capabilities of today's so-called supercomputers. Yet, even as the technocracy in Silicon Valley and abroad labors to forge silicon into this new generation of computers, serious efforts are reportedly underway to create a Sixth Generation of information processors based on a neurological architecture. About a year ago, a group of Japanese computer scientists announced a research and development effort aimed at creating a follow-on to the much-ballyhoed ICOT Fifth Generation project. For lack of a better name, this competitive undertaking was dubbed the Sixth Generation. The main goal of this project is to develop a computer architecture patterned after the neural networks of the brain. It's ironic that the criterion that will distinguish the computers of this so-called Sixth Generation from their Fifth Generation forebears takes us back to the Dartmouth Conference and the dawn of modern artificial intelligence. It was at Dartmouth that AI pioneers first proposed building computers modeled on the human brain. Needless to say, their efforts in 25 PAGESWAPPER - June 1985 - Volume 6 Number 12 (THE (LINKED LIST)) this regard were abortive - then as now, our tenuous knowledge of the intricacies of the brain, cognition and thought processes preclude the development of a machine which truly emulates human gray matter. However, proponents contend, we now know enough about neurology to realize that the speed, power and efficiency of the brain is a function of its massively parallel, highly connective architecture. We also know that parallelism and connectivity are crucial to the success of new-generation non-Von Neuman processors. While we cannot build a working replica of the brain, it's entirely possible that we can develop computer circuitry based on the smallest discrete component of the brain: the neuron. Any biology major can tell you how a neuron works - an electrical impulse originates at one end (axon) of a neuron, travels down a dendrite or conduit through the soma (the cell's physical plant, so to speak) to another axon which serves as a transmitter. The impulse is then transmitted across the synapse to another receptor axon. This procedure is repeated throughout a myriad of neurons until the impulse reaches its ultimate destination. On an elementary level, there's very little difference between this process and the electricity that flows through gates and circuits on a microprocessor chip. What differentiates a neural network from the circuitry etched on a silicon chip is the fact that an impulse fired from a transmitter axon may be received by any of a number of receptor axons on the other side of the synapse. Thus, a nerve ending is akin to a rotary switch while a computer circuit is more like a knife switch that's either on or off. Furthermore, more than one dendrite can be associated with a single neuron. Clearly, the neuron offers far more flexibility than the rigid structure inherent in a silicon chip. It is the ability of a single neuron to selectively address any of perhaps a hundred adjacent neurons that makes the brain the ultimate parallel processor and relational database machine. Now, if we could only implement the same architecture in our computers... Would this not constitute a Sixth Generation of information processors? Maybe yes, maybe no, and definitely not right away. The unique ability of a neuron to selectively address other neurons is a function of the shape of its dendrites. The shape of a dendrite has a direct effect on the speed and electrical potential of the impulses it transmits, thus it serves the same purpose as a capacitor or resistor. When an impulse is transmitted across a synapse, the electrical potential of the impulse determines which receptor axon will be addressed by the electrical charge. It should be within our technological capability to etch simulated neural networks into silicon wafers, substituting "dendrites" of varying shapes for the linear circuitry used in today's microprocessor chips, and placing gates at the points 26 PAGESWAPPER - June 1985 - Volume 6 Number 12 (THE (LINKED LIST)) where synapses would be located on a real neuron. The result might be a reasonable emulation of a biological network, one through which electrical impulses could travel much more rapidly and directly than through the linear conduits of a silicon chip. However, proponents of such technology fail to mention the most significant "implementation issue" associated with modeling the mind, the fact that any such network would be hardwired and incapable of change. Unlike a silicon simulation, the biological circuitry of the mind can modify or program itself. In fact, it is through this self- programming that learning and memory take place. A silicon model of the neurological processes inherent to the functioning of the mind might yield incredible processing speeds and true parallelism, but a silicon structure is rigid and inflexible. Until we can develop a biological alternative to silicon, our imitation neural networks will be capable only of executing predetermined programs. As such, they won't be representative of yet another generation of computing technology. A true manifestation of the Sixth Generation is likely to be a biologically-based information processor that's capable of programming itself by dynamically modifying its internal structure. As far as I'm concerned, it will be quite some time before we see a computer that can legitimately claim to hail from the Sixth Generation. BOOK REVIEW So much for the alleged sixth generation. This month's book review discusses the ongoing efforts to develop the hardware, software, tools and techniques of what promises to be the fifth generation in the evolution of computer technology. THE FIFTH GENERATION Artificial Intelligence And Japan's Computer Challenge To The World By Edward A. Feigenbaum and Pamela McCorduck Addison-Wesley Publishing Company 275 Pages, $15.95 (Softcover Also Available) In The Fifth Generation, AI researcher Ed Feigenbaum and science writer Pam McCorduck have pooled their knowledge and talents to present a compelling and sometimes alarming overview of the current state of AI, placing special emphasis on Japanese efforts to advance the state of the art. The book begins with an overview of fifth generation computers and the nation that has established the firmest commitment to produce them - Japan. Japan is not blessed with a surfeit of 27 PAGESWAPPER - June 1985 - Volume 6 Number 12 (THE (LINKED LIST)) natural resources, and thus has chosen to achieve leadership in what will probably be the most valuable commodity of postindustrial society, knowledge information processing. The authors next launch into a discussion of machine intelligence. This debate can be summarized by the statement "AI works, whether you believe in it or not." Interspersed among descriptions of the Japanese Fifth Generation plan, questions about the feasibility of machine intelligence and the manifest destiny of computing is an interesting essay titled "A Machine As Smart As A Person." This essay contends that a machine will never be as smart as a human - on the contrary, it will surpass human ability to produce and process knowledge. The next section of the book, "Experts In Silicon," addresses the issue of expert systems and explains knowledge-based or expert systems through case studies and examples. We are introduced to expert systems like DENDRAL, CADUCEUS and HEARSAY and the concepts that make them perform at the level of human experts. The anatomy of an expert system is explained in an understandable manner through the use of analogies to situations we are familiar with. Backward chaining, for example, is made analogous to planning an automobile trip starting with the intended destination. The authors also shed light on the newest occupation in the field of computer science: knowledge engineering. Finally, some of the problems that expert systems cannot solve (yet) are discussed, and the section concludes with some speculations about the expert systems of the future. Part 4, "The Japanese Fifth Generation", subjects the Japanese game plan for producing a new generation of intelligent computer hardware and software to a critical examination. The discrete elements of a Fifth Generation computer are detailed, and the Japanese Ministry of International Trade and Industry (MITI), the driving force behind the Japanese Fifth Generation project, is discussed. The section also delves into the feasible as well as the supposedly unattainable goals of the Fifth Generation project, and concludes by debunking Japan's image as a "copycat" nation and explaining Japan's rationale for embarking upon an effort to produce a new generation of computers. The fifth section of the book takes a look at some of the other players in the AI game, notably France and Great Britain, and how these nations have fared up until now. Part 6, "The American Response," discusses IBM and AI, anti-intellectualism as the new American way and the allegation that computer science is "a discipline in crisis." Also explored are the Department of Defense's interests in AI, manifested through DARPA, the Defense Advanced Research Projects Agency, and interindustry research and development efforts by such conglomerates as the Microelectronics and Computer Technology Corporation, known as the MCC. The authors also propose some alternatives for America, notably the formation of a National Center For Knowledge Technology to counter the Japanese Fifth Generation project. 28 PAGESWAPPER - June 1985 - Volume 6 Number 12 (THE (LINKED LIST)) In the concluding section of the book, the authors take a brief look back and a longer look forward. Many of their predictions are speculative, but Feigenbaum and McCorduck are on safe ground when they maintain that the Fifth Generation is for real, and that it will have a profound impact on the fortunes of the human race. In conclusion, I recommend "The Fifth Generation" to anyone interested in computer science, AI, or the course that the world will take during the next few decades. Although the book is remiss in its failure to publicize the accomplishments and contributions of Digital Equipment Corporation in the field of AI and while it paints a bleak picture of America's posture vis-a-vis the Japanese Fifth Generation project, it is still a worthwhile book to read. If Feigenbaum and McCorduck seem to take an alarmist stance in regard to Japan's ambitious goals for the next generation of computer hardware and software, perhaps this sense of concern and urgency is not entirely unwarranted. When you read this book, consider the following analogy: Our country failed to take the Japanese automobile industry seriously twenty years ago. Is our computer industry destined to share the fate of Detroit automakers? COMING IN FUTURE ISSUES By the time you read this issue of (THE (LINKED LIST)), I should have an evaluation copy of Golden Common LISP on my DEC Rainbow. The Rainbow implementation of this software product was developed by Gold Hill Computers and is marketed exclusively through Digital. I hope to provide a product review on DEC's latest AI software offering in an upcoming issue of this newsletter. I'm also waiting for a copy of Insight II, a software package for building rule-based expert systems. I've already experimented with an existing version of Insight, but I thought it best to wait for the arrival of the enhanced product before I put a review together. Finally, I have a number of recently published books on AI which I plan to review in subsequent issues of (THE (LINKED LIST)). As previously stated, I look forward to receiving your contributions to the newsletter. Given the frequency with which new AI titles are released, there's no way I can keep up with all of them myself. So, if you come across an interesting book that merits a review, jot down your findings and mail them in to me at the address on the cover of this newsletter. 29 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX System SIG Committee List VAX System SIG Committee List As of May 21, 1985 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 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 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 30 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX System SIG Committee List 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 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 - 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 31 PAGESWAPPER - June 1985 - Volume 6 Number 12 VAX System SIG Committee List 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 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 32 PAGESWAPPER - June 1985 - Volume 6 Number 12 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 - June 1985 - Volume 6 Number 12 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 - June 1985 - Volume 6 Number 12 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 - June 1985 - Volume 6 Number 12 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