Report on Spring 1983 DECUS Symposium St. Louis, Missouri May 23 to May 27, 1983 Jointly submitted by Marty Adkins, John Beasley, Michael Carullo, Gary Mauler, Arthur Moorshead, Almon Sorrell, Elizabeth Wilson Westinghouse Electric Corporation Baltimore, Maryland Edited by Almon Sorrell and Marty Adkins 23-June-1983 Page 2 CHAPTER 1 INTRODUCTION 1.1 PURPOSE . . . . . . . . . . . . . . . . . . . . . 1-1 1.2 SCOPE . . . . . . . . . . . . . . . . . . . . . . 1-1 1.3 ORGANIZATION . . . . . . . . . . . . . . . . . . . 1-1 1.4 OTHER MATERIAL . . . . . . . . . . . . . . . . . . 1-2 1.5 FUTURE SYMPOSIA . . . . . . . . . . . . . . . . . 1-2 1.6 DISCLAIMER . . . . . . . . . . . . . . . . . . . . 1-2 CHAPTER 2 VMS FUTURE DIRECTIONS CHAPTER 3 VAX CLUSTER CONCEPT 3.1 FEATURES . . . . . . . . . . . . . . . . . . . . . 3-1 3.2 DEVICES . . . . . . . . . . . . . . . . . . . . . 3-2 3.3 SOFTWARE SUPPORT FOR CLUSTERS . . . . . . . . . . 3-3 3.3.1 VMS V3.1 . . . . . . . . . . . . . . . . . . . . 3-4 3.3.2 VMS V3.3 . . . . . . . . . . . . . . . . . . . . 3-4 3.3.3 VMS V3.4 . . . . . . . . . . . . . . . . . . . . 3-4 3.3.4 VMS V4.0 . . . . . . . . . . . . . . . . . . . . 3-4 3.3.4.1 Cluster Based Features . . . . . . . . . . . . . 3-5 3.3.4.2 Features Of Cluster Or Single CPU . . . . . . . 3-5 3.3.4.3 Other Features . . . . . . . . . . . . . . . . . 3-7 CHAPTER 4 VMS COMPONENTS 4.1 BACKUP . . . . . . . . . . . . . . . . . . . . . . 4-1 4.1.1 Changes To BACKUP In VMS V3.3 . . . . . . . . . 4-2 4.2 DEBUGGER . . . . . . . . . . . . . . . . . . . . . 4-4 4.3 RMS . . . . . . . . . . . . . . . . . . . . . . . 4-5 CHAPTER 5 VMS PERFORMANCE 5.1 APPLICATION DESIGN FOR PERFORMANCE . . . . . . . . 5-1 5.2 DISK PERFORMANCE . . . . . . . . . . . . . . . . . 5-5 CHAPTER 6 VMS PROBLEMS & SOLUTIONS CHAPTER 7 VMS MISCELLANY 7.1 SPRS, SOURCES AND MICROFICHE . . . . . . . . . . . 7-1 7.2 NEW VMS DOCUMENTATION . . . . . . . . . . . . . . 7-2 7.3 ODDS AND ENDS . . . . . . . . . . . . . . . . . . 7-2 CHAPTER 8 VAX/VMS LAYERED PRODUCT LANGUAGES 8.1 FORTRAN . . . . . . . . . . . . . . . . . . . . . 8-3 Page 3 8.2 LISP . . . . . . . . . . . . . . . . . . . . . . . 8-4 CHAPTER 9 VAX INFORMATION ARCHITECTURE (VIA) 9.1 DATATRIEVE V2.0 . . . . . . . . . . . . . . . . . 9-1 9.1.1 Application Hints . . . . . . . . . . . . . . . 9-2 9.2 FMS . . . . . . . . . . . . . . . . . . . . . . . 9-3 9.3 TDMS . . . . . . . . . . . . . . . . . . . . . . . 9-3 9.3.1 Record Definitions . . . . . . . . . . . . . . . 9-4 9.3.2 Form Definitions . . . . . . . . . . . . . . . . 9-4 9.3.3 Requests . . . . . . . . . . . . . . . . . . . . 9-4 9.3.4 Documentation . . . . . . . . . . . . . . . . . 9-4 CHAPTER 10 TOOLS (VNX) 10.1 UNIX . . . . . . . . . . . . . . . . . . . . . . 10-1 10.2 DEC/MMS - MODULE MANAGEMENT SYSTEM . . . . . . . 10-4 10.3 FUTURE TOOLS WE MAY SEE SOMEDAY . . . . . . . . 10-5 CHAPTER 11 NETWORKING AND COMMUNICATIONS 11.1 DECNET PHASE IV . . . . . . . . . . . . . . . . 11-1 11.2 ETHERNET INSTALLATION . . . . . . . . . . . . . 11-2 11.3 COMMUNICATION SERVERS . . . . . . . . . . . . . 11-3 CHAPTER 12 COMPUTER SECURITY 12.1 VMS ACCESS CONTROL . . . . . . . . . . . . . . . 12-1 12.2 NETWORK SECURITY - PROXY LOGINS . . . . . . . . 12-2 12.3 MISCELLANEOUS TIDBITS ON VMS SECURITY . . . . . 12-5 CHAPTER 13 GRAPHICS 13.1 CURRENT GRAPHICS PRODUCTS . . . . . . . . . . . 13-1 13.2 DECSLIDE . . . . . . . . . . . . . . . . . . . . 13-2 13.2.1 Menus . . . . . . . . . . . . . . . . . . . . 13-2 13.2.2 Design Options . . . . . . . . . . . . . . . . 13-2 13.3 DECGRAPH . . . . . . . . . . . . . . . . . . . . 13-3 13.3.1 Hardware Requirements . . . . . . . . . . . . 13-3 13.3.2 Menu System . . . . . . . . . . . . . . . . . 13-3 13.3.3 Chart Types . . . . . . . . . . . . . . . . . 13-3 CHAPTER 14 PRO-SERIES PERSONAL COMPUTERS 14.1 APPLICATION DESIGN . . . . . . . . . . . . . . . 14-1 14.1.1 The User Interface . . . . . . . . . . . . . . 14-1 14.1.2 Development Tips . . . . . . . . . . . . . . . 14-2 14.1.3 P/OS V1.5 . . . . . . . . . . . . . . . . . . 14-2 Page 4 14.1.4 Diskette-based P/OS . . . . . . . . . . . . . 14-3 14.1.5 Developer's Toolkit On Host . . . . . . . . . 14-3 14.1.6 Native Toolkit . . . . . . . . . . . . . . . . 14-4 14.1.7 Hardware/Firmware . . . . . . . . . . . . . . 14-4 14.1.7.1 Terminal Emulation . . . . . . . . . . . . . . 14-4 14.1.7.2 Miscellaneous . . . . . . . . . . . . . . . . 14-5 14.1.8 Graphics . . . . . . . . . . . . . . . . . . . 14-5 14.2 FUTURES AND OTHER QUESTIONS . . . . . . . . . . 14-6 14.3 MIGRATION ISSUES . . . . . . . . . . . . . . . . 14-7 CHAPTER 15 HARDWARE 15.1 VAX CPUS . . . . . . . . . . . . . . . . . . . . 15-1 15.1.1 VAX 11/730 . . . . . . . . . . . . . . . . . . 15-1 15.1.2 VAX 11/750 . . . . . . . . . . . . . . . . . . 15-1 15.1.3 VAX 11/780 . . . . . . . . . . . . . . . . . . 15-2 15.1.4 VAX 11/782 . . . . . . . . . . . . . . . . . . 15-2 15.2 MASS STORAGE . . . . . . . . . . . . . . . . . . 15-2 15.2.1 UDA50 Problems . . . . . . . . . . . . . . . . 15-2 15.2.2 Foreign Disk And Tape . . . . . . . . . . . . 15-3 15.3 TERMINALS . . . . . . . . . . . . . . . . . . . 15-3 15.3.1 Terminal Maintenance . . . . . . . . . . . . . 15-6 15.4 FRONT END PROCESSORS . . . . . . . . . . . . . . 15-7 15.5 UNIBUS . . . . . . . . . . . . . . . . . . . . . 15-7 15.5.1 UNIBUS Tricks . . . . . . . . . . . . . . . . 15-7 15.5.2 UNIBUS Hints . . . . . . . . . . . . . . . . . 15-8 CHAPTER 16 DOD ISSUES 16.1 TEMPEST . . . . . . . . . . . . . . . . . . . . 16-1 16.2 MILITARIZED EQUIPMENT . . . . . . . . . . . . . 16-1 16.3 DOD-PECULIAR HARDWARE . . . . . . . . . . . . . 16-2 16.3.1 Instruction Set Architecture Requirements . . 16-2 16.3.2 Military Software Requirements . . . . . . . . 16-3 APPENDIX A VAX/VMS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS APPENDIX B DATATRIEVE SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS APPENDIX C GRAPHICS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS APPENDIX D RSX/IAS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS CHAPTER 1 INTRODUCTION 1.1 PURPOSE This report covers the Spring 1983 DECUS (Digital Equipment Computer Users Society) Symposium held in St. Louis, Missouri from May 23 through May 27,1983. It also includes a report on a pre-symposium seminar held May 22,1983. The report was prepared from input supplied by Marty Adkins, John Beasley, Michael Carullo, Gary Mauler, Art Moorshead, Almon Sorrell and Elizabeth Wilson, and was edited by Almon Sorrell and Marty Adkins. The report is not organized chronologically, but rather by topic, since this seemed to be the most useful means of conveying information to the reader. 1.2 SCOPE This report addresses the sessions that are of greatest interest to VAX users. There were literally hundreds of formal sessions which were scheduled in 16 different rooms concurrently. Those sessions included presentations on RSX (PDP-11 operating system), RSTS (PDP-11 time sharing), and TOPS (DEC-10/20 operating system) as well as sessions oriented toward the business user, site preparation, etc. Additional informal sessions were held continually in "camp grounds" where users and VMS developers could meet for one-on-one discussions. 1.3 ORGANIZATION The top level organization of the report consists of 16 major categories: Introduction, VMS Future Directions, VAX Cluster Concept, VMS Components, VMS Performance, VMS Problems and Solutions, VMS Miscellany, VAX Layered Product Languages, VAX Information Architecture, Tools (VNX), Networking and Communications, Computer Security, Graphics, PRO-Series Personal Computers, Hardware, and DoD Issues. INTRODUCTION Page 1-2 OTHER MATERIAL 1.4 OTHER MATERIAL There were two volumes of handouts for the VAX/VMS sessions which contained hard copies of the presenters' slides or viewgraphs. Where reference to these are appropriate the symbol "VSIG" will refer to the VAX Systems SIG Handout. Similar handouts were prepared by the RSX SIG (RSIG), Network SIG (NSIG), Datatrieve SIG (DSIG), and Graphics SIG (GSIG). This was the first symposium at which commercial audio taping was available. The VAX SIG had all of its presentations (whose speakers signed a release) taped. These cassettes were available shortly after each session and are also available from: DECUS Cassettes Eastern Audio Oakland Center 8980 Route 108 Columbia, Md. 21045 1.5 FUTURE SYMPOSIA The Fall '83 DECUS symposium will be held at the MGM Grand Hotel in Las Vegas, Nevada from October 24 through 28, 1983. The Spring '84 symposium will be in Cincinnati, Ohio. 1.6 DISCLAIMER All information reported here is believed to be correct and is based upon information related in good faith to the attendees. Every attempt has been made to check this report for accuracy and correctness, and any additional information gathered since the symposium which bears on topics presented there is also presented. Neither the attendees nor Westinghouse accept any other responsibility for the contents of this report. CHAPTER 2 VMS FUTURE DIRECTIONS VMS developers at this symposium seemed to be more willing to talk freely about features of the "next major release." Speculation is that VMS V4.0 will probably ship around April, 1984. Some tidbits picked up included: o The Command Line Editor (CLE) interface will be considerably broadened in V4. This will include support of presently undocumented features such as "$infile", etc. o VMS V4 uses an "upward compatible" version of ODS-2. File names may have a maximum length of 39 characters. o The terminal driver in VMS V4 will be able to reconnect after DTR (Data Terminal Ready) drops on a dialup line. o In VMS V4 the Professional Computer will be supported as its own terminal type; it currently emulates a VT102 or VT125. o TECO will be supported in V4 (by Andy Goldstein). o The developers are using EDT V3 and say it is considerably faster. o There will be a new native mode utility (EXCHANGE) which will replace FLX. o The VMS V4 Run Time Library will have a utility allowing the user to bind character sequences to a given key on the keypad. This will allow easier and more flexible use of the keypad for application programs. o In V4, all DCL messages will be "real" messages. An ASSIGN will acknowledge with "Logical name XXXXXX replaced". o In VMS V4.0, clusters will make use of the alternate rooted directories [SYS1.] through [SYSE.] for local processor storage. Beware if you are currently using these for your own purposes! VMS FUTURE DIRECTIONS Page 2-2 o DEC is looking at extensions for rooted directories, possibly to subdirectories. o DEC is very seriously considering support of SDL (Spitbrook Definition Language). o Escape sequence handling in TTDRIVER has been completely rewritten for V4. A QIO with the IO$M_ESCAPE modifier will return an escape as the termination character in the IOSB, with an offset to the sequence location in the buffer. o See the chapter entitled "VAX CLUSTER CONCEPT" for a discussion of journals and checkpoint/restart. This will be applicable to clusters, and to a lesser extent, single machines. o See the sections on RMS, and the Debugger under "VMS Components" for information on the future of these products. CHAPTER 3 VAX CLUSTER CONCEPT VAX clusters are computer systems that consist of multiple, cooperating, loosely coupled, VAX/VMS CPUs operating with a globally shared, intelligent, mass storage subsystem. There were at least eight sessions dealing with some form of the VAX cluster hardware and software. These ranged from sessions on the new mass storage architecture, which were primarily repeats of previous symposium sessions, to new sessions dealing specifically with the hardware and software necessary to utilize the mass storage architecture for VAX clustering (VSIG pp. 28-38). 3.1 FEATURES o Allows incremental growth of a computing facility o Higher total system availability o Processors fail independently, not together o Increased data availibility through data protection/recovery capabilities o Transparent data sharing across systems o Broader cost/performance range o Benefits from economies of scale VAX CLUSTER CONCEPT Page 3-2 DEVICES 3.2 DEVICES The following devices are required to make the VAX cluster concept work: o Computer Interconnect (CI) - A 70 Mbit per second, fault-tolerant, dual-path bus which connects VAX processor nodes and intelligent I/O subsystem nodes, like the HSC50, via a star coupler. Any VAX processor node can talk to any other VAX processor node over the multiaccess bus topology utilizing a packet-oriented scheme. Fault tolerance is achieved by having two transmit and two receive paths for redundancy. The VAX CI interface consists of four hex high modules: * SBI Interface Module - interfaces the CI to the SBI. Initiates SBI transfers and responds to SBI requests. * Data Path Module - main computing element of the CI. It consists of eight microcode controlled 2901 bit slice micro-processors. The data path module maintains the Virtual Circuit Descriptor table for the system. It also maintains the microcode local store. * Packet Buffer Module - buffers both the transmit and the receive data. Maintains separate buffers for both the A and B paths. Controls the microsequencers and branch multiplexers. * Link Module - provides the interface to the CI bus. Calculates and verifies the 32-bit CRC code. Handles packet header and trailer information and provides immediate ACK/NACK header response. The CI cables tie the CI interface to the star coupler. There are separate cables for transmit and receive for both the A and B paths and they may be up to 45 meters in length. Cables may be added or removed at any time without affecting the rest of the cluster. When both paths are operational, both are utilized to achieve higher throughput. VMS automatically detects a failed path, continues to periodically test it, and will reuse it once it has "healed". o Star Coupler - A passive common connection point for all nodes connected to the CI. Each IN path is connected to all OUT paths. A star coupler can handle up to 16 nodes. It passes data at the 70 Mbit per second rate of the CI. o HSC50 - Intelligent disk/tape server which connects the new mass storage architecture disks and tapes to one or more VAX processors in a cluster. Communicates with VAX processors in the cluster via the CI and uses the Mass VAX CLUSTER CONCEPT Page 3-3 DEVICES Storage Control Protocol (MSCP) for host communications. Presently the HSC50 can provide storage access for up to four processors. (Note: This four-processor restriction is not a hardware limitation, but has been imposed by DEC as a guide line until they have more experience with clusters.) Each HSC50 can handle a combination of up to six disk and tape interfaces. Each disk interface can support up to four RA-series disk drives, while each tape interface can support up to four master TA78 tape drives, with each master drive supporting up to three slave TA78 tape drives. For more information, see the Fall '82 DECUS trip report. NOTE In discussions with product management, it was discovered that there is no battery backup for the local memory in the HSC50. This means that a power failure forces a reboot of the local (HSC50) processor. The console medium for the HSC50 is a TU58 cartridge! A software bootstrap from the TU58 will require almost four minutes. This seems an unfortunate series of choices for hardware which is supposed to be integrated into high reliability, high availability systems. o RA-series disks - mass storage architecture disk drives required for cluster operation. These consist of the RA60, RA80, and RA81 disk drives detailed in the Fall '82 DECUS trip report. o TA78 Tape Drive - New mass storage architecture tape drive required for tape sharing on the cluster. This is a 1600/6250 BPI tape drive. It was reported on in the Fall '82 DECUS trip report. 3.3 SOFTWARE SUPPORT FOR CLUSTERS Software support for the cluster is being phased in over several minor releases and the "next major release." VAX CLUSTER CONCEPT Page 3-4 SOFTWARE SUPPORT FOR CLUSTERS 3.3.1 VMS V3.1 With the release of VMS V3.1 came DECnet-VAX support for the CI on the 780 and the 782. The only hardware configuration allowed was two or more VAXs connected to a star coupler via CI interfaces. In this instance, the CI replaced the normal DMR11 interfaces used with DECnet. 3.3.2 VMS V3.3 Coming with the release of VMS V3.3 (presently being shipped to customers) will be support for the HSC50 disk interface for 780s and 782s only. This version of VMS will support the seek and rotational position optimization as well as static dual porting of the RA-series disks. Also under VMS V3.3, each CPU will be required to have its own system disk, whether it be local or on the HSC50. User disks can be either local or on the HSC50. No local disk is required for any CPU. Disks on the HSC50 can only be mounted read/write to one CPU, but can be mounted read-only to all other CPUs. The requirement that a specific CPU control a specific disk will be lifted in a "future major release" of VMS. Support for the HSC50 tape interface is not expected until then. Supposedly, the pacing item is not VMS, but the HSC50 software. 3.3.3 VMS V3.4 Coming with the release of VMS V3.4 (expected to ship to customers in July or August) will be DECnet-VAX support for the VAX 750 over the CI interface. This release will also allow the 750 to become part of a cluster with the provision that it have a local system disk from which to boot. User disks for the 750 can reside on the HSC50. The requirement for a local system disk on the CI is due to the 750 boot ROM. This will be fixed along with VMS V4.0. 3.3.4 VMS V4.0 A "future major release" of VMS (expected to be VMS V4.0 estimated to ship to customers in April '84) will provide most of the necessary software needed to effectively utilize the cluster approach. However, many of the benefits from the future release will also be usable on non-clustered machines. Following is a brief description of the software associated with clustering. VAX CLUSTER CONCEPT Page 3-5 SOFTWARE SUPPORT FOR CLUSTERS 3.3.4.1 Cluster Based Features - o Distributed Lock Manager * Enables sharing/interlocking of resources in clusters * Present on each processor * Communicates with each node * Cluster disk storage kept safe on processor failure o Shared File System * Uses distributed lock manager * Handles access/allocation of disk storage * Present on each processor * Provides cluster-wide file access * Communicates with other nodes o Mass Storage Control Protocol (MSCP) Server * Makes disks local to a given processor look as if on HSC50 for cluster wide access * Understands MSCP * Transfers data across the CI * All devices appear as local o Distributed Job Controller * Cluster-wide batch and print queues * Load balancing of batch processes based on available queue space only * Single UAF for cluster. Single copy of VMS in [SYS0.], per-CPU storage in [SYS1.] through [SYSE.]. 3.3.4.2 Features Of Cluster Or Single CPU - o Common Journaling Facility * Provides capability to write and read journals * Provides four types of journals - After Image (AI) - Allows previous state to be rolled forward to the present despite corruption of files or disk - Before Image (BI) - Allows present state to be rolled back to a previous state - Audit Trail (AT) - Allows recording of changes or activities for audit purposes - Recovery Unit (RU) - Provides support for atomic operations VAX CLUSTER CONCEPT Page 3-6 SOFTWARE SUPPORT FOR CLUSTERS * Provides support for user-written recoverable facilities o Recovery Unit Facility * Guarantees that a specified sequence of operations within an image of a single process will be atomic * Operations within a recovery unit either complete successfully or are entirely undone (rolled back) * Roll back is automatic when a CPU fails o Checkpoint/Restart Facility * Only within a single process * Saves state of application at user-defined points * Application can be restarted after system failure automatically on the same CPU or with manual intervention on another identical CPU (same options _________ and ECO level). * Preserves investment in computation * Based on recovery unit facility * Must be invoked by the process (although there was strong audience sentiment for a utility to "force" a process to take a checkpoint, such as before a system shutdown). Also, a checkpoint cannot be declared from within an AST (you can do it from inner access modes). For now, they are being very conservative. o RMS Journaling * Provides a simple-to-use system for journaling RMS operations * Automatic for marked files * Transparent to the user * Supports all journal types VAX CLUSTER CONCEPT Page 3-7 SOFTWARE SUPPORT FOR CLUSTERS 3.3.4.3 Other Features - o Volume Shadowing - Supported for all RA-series disk on the HSC50 or a local UDA50, but not for local Massbus disks. (Volume shadowing requires a logically perfect disk.) o HSC50 Tape Support - Allows any TA78 tape drive on the HSC50 to be accessed by any CPU in the cluster o Host Diagnostic Capability - Presently, HSC50 diagnostics can only be run from the HSC50. In the future, any of the cluster CPUs will be able to run diagnostics on the HSC50. CHAPTER 4 VMS COMPONENTS 4.1 BACKUP Andy Goldstein of DEC gave a presentation on the inner workings of BACKUP. BACKUP uses a fixed block size with variable length records. It was designed for an unreliable medium. The save set medium can be: o ANSI magtape o Files-11 file o Sequential disk o Network file The format of a save set record is illustrated below. The record is filled with null blocks to get to the fixed block size. ---------------------------- -------------------------- | | | | | | | | | | |BLOCK |DATA |DATA |DATA | |DATA |DATA |NULL |NULL | |HEADER|HEADER| |HEADER|.....|HEADER| |BLOCK|BLOCK| | | | | | | | | | | ---------------------------- -------------------------- The block header includes the following information: o Identification field o Sequence Number - used to detect missing blocks o Header CRC - uses CRC-16 polynomial o Block CRC - uses VIN-2 polynomial o Save set name o Current file name The 16 byte header record includes the following information: o Record length o Record type - BACKUP summary record, volume summary record, or file attribute record o Data address o Flags VMS COMPONENTS Page 4-2 BACKUP The BACKUP summary record includes things like the time of day, the CPU serial number and BACKUP medium such as tape or disk. The volume summary record is used in an image save set and includes things such as the volume label, cluster factor and volume protection. A file attribute record includes the file name, file protection and file owner. BACKUP has many data reliability features. Save set volumes and the blocks inside are self-identifying allowing reconstruction of files even if part of the media is destroyed. When write errors occur, BACKUP does not rewind the tape and write over the bad block. Instead, it rewrites the block farther along on the tape. Thus when a read error occurs, BACKUP continues to read until it finds a rewrite of that block. The length of this search is written in the volume header block. With this implementation a BACKUP tape will contain "bad blocks". The /INTERCHANGE qualifier (see below) modifies this behavior to force "good blocks" which can be read by other utilities. The /FAST qualifier causes BACKUP to perform a prescan of header files creating its own file selection bitmap for more efficient use. This is desirable when most files on a volume are selected by the input qualifier. An example of such usage would be an incremental backup of DEV:[*...] with the /SINCE=BACKUP qualifier. 4.1.1 Changes To BACKUP In VMS V3.3 The following changes to BACKUP, incorporated into VMS V3.3, were discussed: o The default will be /NOREWIND o It will be able to handle execute-only directories o When saving a lower-level directory, the parent directories are not automatically copied. o The /INCREMENTAL qualifier wil be able to handle renamed files NOTE This is not true for renamed directories. In the ___________ case of a restore, the complete old directory will be restored without knowledge of the renamed directory. VMS COMPONENTS Page 4-3 BACKUP o The date recording problem in stand-alone BACKUP is fixed. o Stand-alone BACKUP now outputs a message showing the date and time when it is booted. The message is repeated when BACKUP is completed. This will allow users to determine the length of time BACKUP used. o The undocumented qualifier /INTERCHANGE has been documented in VMS V3.3. Its primary reason for existence is to create tapes which may be duplicated for software distribution. It possesses the following qualities: - Physical blocksize is 8192 bytes - Permits rewrite error recovery mechanism normally inhibited by BACKUP. This will produce a tape with only good blocks allowing future use of the COPY utility to retrieve data from the tape. - Suppresses saving of directories not specified - In V4, it will suppress Access Control List (ACL) information Some of the requests for future enhancements which DEC is taking under consideration include: o Labeled tape support. o Bypass bad tape labels. BACKUP is designed to save and recover data on an unreliable medium and it incorporates several powerful techniques for recovering from unreadable data. The one single point failure is the tape label. If that is unreadable, the tape won't MOUNT for BACKUP to run. There were some hilarious workarounds described in the session by users, but in general it can be a real problem. o Unload the tape during the Record pass for a BACKUP/RECORD. This frees the tape drive sooner. o Ability to BACKUP from one save set to another. At present, only one of the parameters can be a save set. A workaround is to simply use a COPY command since a save set is a file. This sometimes doesn't work due to idiosyncracies in the internal record format BACKUP uses for redundancy. Also, to copy a save set to a tape, you must first mount the tape with the correct block size. A BACKUP/LIST of the save set will display this information. Since the people responsible for maintaining BACKUP are also deeply involved in the improvements to VMS to make it work in the Cluster, no major improvements are slated for BACKUP in VMS COMPONENTS Page 4-4 BACKUP the near future. A few facts about BACKUP performance: o BACKUP cannot keep up with a 6250 BPI, 125 IPS tape drive (TU78/TA78) due to the computation of the CRCs for error checking. With a CPU overhead of ~5 uS/byte, the maximum throughput is 200 KBytes/sec, at which point BACKUP gets CPU-bound. o Remember to specify "/BUFFERS=5" when backing up to a TU80 to improve the likelyhood that it will keep streaming. 4.2 DEBUGGER There is much work going on for the Debugger. The developers have lots of ideas and improvements which will probably appear in VMS 4.0. Some of the proposed improvements are: ________ o Aggregate Examine - EXAMINE A - Displays an entire structure such as a Pascal record structure or an array. o A SHOW SYMBOL command which shows all modules in which a symbol is defined. It may have wildcards. You will be able to get all the data the debugger has on a symbol such as its size, type, address. o The ability to define commands in a manner like the DCL symbol facility. DEFINE/COMMAND SL = "SHOW LANGUAGE". o An UNDEFINE command to remove a symbol from the symbol table. o Control structures such as FOR, WHILE, IF THEN. o A STEP/RETURN which goes to the next return statement and stops. o A SET BREAK/CALL command like the SET TRACE/CALL. o A SET BREAK WHEN (X .EQL. 10) to capture states. o A SPAWN command to spawn a DCL command from within DEBUG. o An ALLOCATE command to expand memory permitting a larger symbol table. o The Debugger is being made to work with more of the languages DEC supports on the VAX, such as C. Improvements are being made to its current interface to existing languages (such as needing only one SET SCOPE in VMS COMPONENTS Page 4-5 DEBUGGER Fortran). Some the the languages, such as APL have their own debug facilities and will not be incorporated in the Debugger. o The keypad on a VT100 may be defined with commands (like EDT). o The screen of the terminal may be divided into windows which display the source and data simultaneously. o The performance and startup time of DEBUG is being improved. 4.3 RMS There was much interest in RMS tuning and future improvements. At one of the performance seminars, someone who had done extensive benchmarking said that an 11/750 can never be I/O-bound and an 11/780 can only be I/O bound with difficultly. They become CPU-bound doing the I/O processing, but the actual I/O channel is not the bottleneck. Some suggestions for improved performance: o It is better not to page than to page (especially on an 11/782 where a page fault in the attached processor causes an expensive context switch). o It is better to page to the page-caches than to the disk. "cheap fault" (a function of the cache sizes) o It is better to page to disk than to swap. o Make the cluster size an even divisior of the number of sectors per track. o Make large files (both data and executables) contiguous: Use COPY/CONTIGUOUS, LINK/CONTIGUOUS. o Use a large extension size for files which will grow. o Use a large initial size for data files which will eventually fill up. o Make your buffer sizes and bucket sizes a multiple of the cluster size. o For ISAM files, use global buffers if several users will simultaneously access the file. Even if using global buffers, you still need local buffers. VMS COMPONENTS Page 4-6 RMS o For ISAM files, allocate (5 + 3*(Number of keys)) buffers for each file. o Reorganize ISAM files after a significant number of updates - especially after deletes to reclaim the space. Use the CONVERT/RECLAIM utility for Prolog 3 files and the CONVERT utility for Prolog 1 & 2 files. When VMS 4.0 appears, RMS will have many small improvements added. o Multiple key ISAM files can be Prolog 3 and enjoy the benefits of data compression and CONVERT/RECLAIM. o The FDL editor algorithms for optimizing file attributes such as bucket size, etc. are being reworked as a result of field experience and further analysis and will be improved. o Priorities will probably be added to QIO's in the future so that higher priority processes are not I/O-bound waiting for a lower priority process to complete its I/O requests. o RMS will support many of the improvements in VMS such as checkpointing, journaling, atomic commit, auto-recover, distributed lock manager. o RMS will support quad-word (64-bit) keys in RMS indexed files. This will allow system time format to be used as a key. CHAPTER 5 VMS PERFORMANCE 5.1 APPLICATION DESIGN FOR PERFORMANCE Stan Amway of DEC gave an excellent presentation covering one of the most neglected aspects of performance - the initial design of an application. Since his presentation was not taped, this section will be as detailed as possible to highlight the points made. o Define Overall Performance Goals * What is the performance metric; what goal must be met? * Perform task "x" in "y" seconds o Source of Performance Data for Goal * Previously measured utility routines * Special measurements for critical routines * Vendor-supplied performance data. Stan believes that DEC Sales should freely show (but not copy) DEC's measured timing data in their sales guide. * Best-guess estimates o Iterative Design * Iterate to meet performance goals * Where to stop? - Goal is met - Results have reached a plateau o Redesign vs. tune * Tuning assumes a sound design, but a faulty implementation. o Memory Considerations * Temporal Locality - recent past usage predicts future usage VMS PERFORMANCE Page 5-2 APPLICATION DESIGN FOR PERFORMANCE * Spatial Locality - data items stored and referenced together o Examine algorithms in a virtual memory environment. * Initialize data just prior to usage (temporal locality) to avoid unnecessary out-faulting of data after initialization, but before use. * Avoid complex search techniques such as binary tree. * Use complex data structures (such as multi-dimensional arrays) with care. * Store commonly used data together. * Remove error routines from mainline code. This removes them from your working set. o Language specific: * Watch out for array mapping when "translating" from one language to another - PL/I and FORTRAN store arrays in different order. * Initialize large arrays procedurally (i.e., with DO). This is especially true when initializing to zero, since large arrays will be zeroed via Demand Zero Pages when faulted. o Use dynamic storage allocation with care - it's usually slow o Linker - focal point for all virtual memory allocations * Demand zero pages are created only for non-initialized data. * Default values for LINK are usually adequate, not optimal. o Processing in linker is based on * File or module input order determines the physical "proximity" of modules in memory. * PSECT attributes * Option file can be used to specify order. o Create clusters of code in linker * Put user code in the default cluster. * Run time library, shareable images assigned to additional clusters * Keep common utility routines close to each other. o Each cluster is assigned a page fault cluster factor. This determines how many pages are read in when a page fault occurs. VMS PERFORMANCE Page 5-3 APPLICATION DESIGN FOR PERFORMANCE * Default value is 0 - resolved at run time (SYSGEN parameter PFCDEFAULT) * If referencing locations at random, consider setting a smaller cluster factor for that cluster to avoid faulting in unnecessary pages. o File definitions * Choose the appropriate file organization. * ISAM is not always best for keyed access - is best if you need to perform sequential accesses after a key lookup. - Hashed index can be accessed faster. - Inverted files are better for queries. * Must trade implementation vs. usage costs * Use FDL * Beware of files created by languages (FORTRAN) or products (DATATRIEVE ADT) - Default values supplied are usually sub-optimal. - ISAM files require close attention. o I/O Considerations * Avoid costly file operations such as OPEN, CLOSE, CREATE, DELETE, EXTEND. * Use appropriate level of I/O buffering. Random file processing requires smaller buffer/bucket sizes, 2 or more buffers. Language defaults vary. * One helpful metric is to run MONITOR IO. If the window turn rate is much greater than the file open rate, this is an indication that the disk is badly fragmented (or that the default window size is too small). o Global Buffers * Performance gains due to cacheing * Count must be large enough for all users simultaneously accessing file. * Local buffers are still required, especially for deferred write (most languages default to deferred write). This can conflict with global buffers. o File Sharing * Allows greater concurrency UP TO A POINT * High-contention applications require special considerations. * Limit concurrency for high-volume applications - transaction processing. VMS PERFORMANCE Page 5-4 APPLICATION DESIGN FOR PERFORMANCE o CPU Considerations * System level tuning cannot significantly offset application CPU utilization. * Data structures have major impact. * Minimize process creation and image activation (BASIC CHAIN command, $CREPRC, etc.). * Consider use of the Lock Manager for short messages (24 bytes or less). o Interpreted Languages * Use DCL for prototyping ONLY - many commands execute images and incur heavy image activation overhead. * Compatibility Mode - slower, more instructions are needed, all floating point calculations emulated o Data Usage * Avoid unnecessary data conversions (DATATRIEVErs take note!) * Use least expensive data type (INTEGER -> SP/DP -> PACKED DECIMAL) * Avoid display data types in DATATRIEVE (use COMP, COMP3, etc. for up to 32:1 difference) o Align data on "natural" boundaries * Use of COMMON or MAP statements - avoid putting odd bytes at beginning of list. Using the allocation shown below, the operation I=A(2) will execute ~ 2.5 times slower than with X following the A array. INTEGER*4 A(200) BYTE X COMMON/DUMMY/X,A !INCORRECT Order o Design applications that are tunable * Parameterize for easy tuning - buffer size, counts * Isolate performance-sensitive functions. * Build in performance measurement routines - see Run Time Library LIB$STAT_TIMER, LIB$SHOW_TIMER. (You can call LIB$STAT_TIMER from the Debugger.) Additional tips for improving application performance were shared in a panel session titled "Increasing Performance of Applications on VMS": o Reduce duplicate buffers. Where possible, eliminate movement of data in memory by moving data directly to work areas. VMS PERFORMANCE Page 5-5 APPLICATION DESIGN FOR PERFORMANCE o Curves were shown illustrating the use of MOVC vs. the MOVL/SOBGEQ instructions. The break-even point is at ~80 bytes. However, for transfers of 1000 bytes or so, MOVC is almost twice as fast. o By changing from Fortran formatted I/O to unformatted I/O, the time to transfer 10,000 80-byte records was reduced from 8 seconds to 1 second. o Sort records before entering them into an ISAM file. Use CONVERT to maintain the sorted order. In one example, inserting 500 unsorted records caused 230 RRVs in the structure. o The use of a single key makes a big difference in ISAM files. 5.2 DISK PERFORMANCE Dr. Richard Wrenn of Washington University presented the results of his study on "Disk System Performance in VAX/VMS". His approach is threefold: 1. An I/O system sampler called BUSUSE (on the SIG tape) 2. A simulation of the UDA50 3. A single-user controlled I/O mix program to measure latency and throughput. (DEC company-confidential data is available for VMS 2.x, but DEC has not yet repeated those tests for VMS 3.x.) The devices tested include the RM80, UDA50/RA81, RK07, and the SI-9751 with the Fujitsu Eagle drive. To understand which device specs are important to your system, Dr. Wrenn recommends that you characterize the I/O by plotting the probability density of the number of sectors transfered in a given I/O request. On a typical system, 40% will be single-sector QIOs, and 25% will be modified page writer (MPW) QIOs (size = MPW_WRTCLUSTER). A highly fragmented disk makes a huge difference in the number of single-sector QIOs. Some observations: o For 96-sector (MPW) transfers, the UDA50/RA81 matches the RM80, but the Eagle is still faster. o For single-sector transfers the Eagle is fastest at low rates, and the UDA is fastest at high rates (40-50 QIOs/sec). This is where the UDA50's seek order optimization starts to shine. VMS PERFORMANCE Page 5-6 DISK PERFORMANCE o For an I/O mix with an exponential distribution and a mean of 4 sectors, the UDA50/RA81 was faster than the RM80, but the SI-9751 with the Eagle was 25-30% faster than the RA81. o The UDA50 transfer rate was measured at 669 KBytes/sec with the burst rate set to zero. He changed the burst rate and got strange errors. (The documentation states this is not supported.) o The RM80 transfer rate was measured at 885 KB/S. The Digital spec is 1.2 MB/S but this is the raw bit rate including format information. o The RK07 transfer rate was 377 KB/S. Its curve has discontinuities due to a head switch delay. o All DEC drives were within published spec for mean seek time. The Eagle was measured at 21 MS vs. its spec of 18 MS. o VMS disk QIO overhead is ~9 MS. o The UDA50's seek order optimization is very important in a time-sharing environment, but causes problems in real-time uses. There is no priority on QIOs to the UDA50 (nor the CI). There is currently no VMS support for the UDA50 express queue, and that queue also has no priority. For very high speed or time-critical transfers, he recommends using an RP07 or SI-9751 on the MASSBUS, or possibly the RA81 on the HSC50. o It is very seldom that a VAX is I/O bound. You can put three busy RM80s on one MASSBUS with no degradation - four is a judgement call. o To determine when a second ACP is justified, run BUSUSE and check ACP queue lengths. Expect them to be longer on the UDA50 than on an MBA. This question will go away in VMS V4.0 when multi-streaming ACPs will run in process context. CHAPTER 6 VMS PROBLEMS & SOLUTIONS o When using the SUBMIT command with multiple files, only the first procedure gets the parameters passed with the /PARAMETERS= qualifier. o If a user performs a LINK/MAP/NOEXE, user libraries are not searched. Therefore, the map will not reflect the true usage of a program. Instead, use LINK/MAP/EXE=NL: (this is how it is fixed in V4.0). o Performing a STOP/QUEUE/NEXT with multiple active generic queues may stop queues other than the one intended. This will be fixed in V4. o If an image installed with privileges spawns a subprocess, the sub must issue a $SETPRV or "SET PROCESS/PRIV=xxx" to use them. o The V3 Versatec driver outputs a character at a time in plot mode. Because of the device speed, the print symbiont stays solidly compute-bound at priority 8. o The terminal broadcast MWAIT problem is fixed in V4.0. o The hardware group plans to fix a problem with the RP07 which disguises bad blocks as "operation incomplete" errors. o If EDI is invoked with a filespec > 9 characters, it doesn't complain, but makes no file on exit. o The MMG$UNLOCK routine is accidentally undocumented. o Standalone BACKUP can still run out of memory and hang if you specify /RECORD and a large number of files are processed. o A certain third-party vendor has a 560 MB drive that emulates two RM05s. One user reported that warm restart will not work. Another stated that standalone "anything" VMS PROBLEMS & SOLUTIONS Page 6-2 won't work. o The BASIC distribution kit protects BASIC.EXE from world read access, necessary for an INSTALLed image. INSTALL doesn't complain, nor does the image activator, so the image is not shared, and you get multiple copies. o It is not necessary to cycle power on the LSI-11 to reload WCS. Instead, issue the command "LOAD /WCS". o If a power fail is timed just right, it can cause the belt on the LSI floppy to jump off its pulley. An FCO replaces the pulley with one having higher flanges. o Console floppy V7.0 is the first version to make use of the second 4KW bank of LSI-11 RAM. Previous memory defects may have gone unnoticed. CHAPTER 7 VMS MISCELLANY 7.1 SPRS, SOURCES AND MICROFICHE In a session titled "VMS Organization", VMS Development personnel gave tips on reading the microfiche and on submitting SPRs: o SPRs are answered by VMS Development. They have four time-sharing VAXs - one running the current VMS release, and three running the latest internal version. In addition they have 10 standalone or clustered VAXs for development work. Certain SPRs have been so memorable that they were posted on the "SPR of the Week" bulletin board. A response to one far-out suggestion read, "Thank you for your suggestion. It will be considered for a future major architecture." o New policy - SPRs without sufficient supporting evidence will either be refused or given a very low priority. They can no longer afford to waste an inordinate amount of time trying to duplicate poorly-documented problems. o Send long or complicated examples on media as it saves them from having to type it in. Send pictures if you want. When sending crash dumps, remember to BACKUP SYSDUMP.DMP with "/IGNORE=NOBACKUP"! The "system coroner" receives a number of SPRs with empty dump files. o Source kits are a BACKUP of their master pack at the time of that major release. o A number of unsupported routines have names of LIB$xxxx, yet are not in the RTL. These will be changed to a different prefix (the RTL group has jumped all over them). o By a show of hands, the audience overwhelmingly requested machine-readable microfiche indexes. Andy Goldstein replied that they will be added to the distribution. VMS MISCELLANY Page 7-2 NEW VMS DOCUMENTATION 7.2 NEW VMS DOCUMENTATION DEC is going to rearrange VAX/VMS documentation for VMS V4.0. There will be new material covering: o Clusters o Security o Data integrity o Process Integrity o Queue Management The new documentation set will be split into two different sections, a reference shelf and a set of procedure-oriented manuals. The reference shelf will include: o Intro - SPD, Glossary, Master Index o DCL o Text Processing - DSR, EDT o I/O o Utilities - 35 different programs, showing such things as - Formatting - Description - DCL Interface - Commands - Usage - Privileges required o Routines - System, RMS, RTL, Callable utilities - Sort - Journaling - CLI - EDT (YEP - you read it right - callable EDT!) 7.3 ODDS AND ENDS o The VAX/VMS Internals and Data Structures manual has been updated for VMS Version 3.0 and should be available in August 1983. It will be available from Digital Press. The new book includes new chapters on the internals of Lock Management and the multiprocessing (782) system, but does not document the ODS-2 file system. o The Accessories & Supplies Group (A&SG) is now controlling the licensing of diagnostics. CHAPTER 8 VAX/VMS LAYERED PRODUCT LANGUAGES In a session on VAX Languages & Tools, DEC product management gave a status summary of the present language products. The speaker also described a DEC publication which gives feature-by-feature comparisons of all the languages. Although this is technically a company confidential manual, they are pushing internally for its release. To test the waters, a limited number of copies were handed out at this DECUS (they disappeared in a matter of minutes!). DEC would greatly appreciate written feedback from any readers of this document. o APL ___ * Based on proposed standard * Large workspace (using virtual memory) with interchange * Can execute any VMS command * V1.0 shipped Jan 83 * V1.1 will ship Summer 83 - includes support for RMS sequential and relative files, and formatting. o BASIC _____ * ANSI minimum Basic validated Dec 82 * V2.0 shipped Feb 83 - record data type for CDD interface; other compiler options * V2.1 shipped April 83 * Future - data manipulation language, graphics, improved performance o BLISS _____ * V3.0 in March 82 - no other updates planned * Source line display in Debugger * G & H floating point * Bliss-16 compatibility mode * Next release - extended addressing, better documentation (examples), 10% performance increase VAX/VMS LAYERED PRODUCT LANGUAGES Page 8-2 o C _ * Follows Kernigan and Ritchie standard * Run-time library simulates UNIX environment * V1.0 shipped June 82 * V1.2 shipped Feb 83 * V1.3 in June 83 * Next release - CDD interface, Debugger support o COBOL _____ * ANSI 1974 standard plus features from proposed 198x draft * V2.0 shipped June 82 * V2.2 in May 83 * Next release - screen extensions, standards flagger o DIBOL _____ * V1.0 shipped in Feb 82 * V1.2 in Oct 82 * V2.0 expected July 83 * New DIBOL-83 standard - single compiler across all O/S, optimizer, structure data type, CDD interface o DSM ___ * V2.0 shipped in March 83 - faster interpreter, Debugger * ANSI MUMPS-83 * Next release - will be timed with VMS 4.0 o FORTRAN _______ * V3.0 shipped in June 82 * V3.2 in Feb 83 * V3.3 expected in June 83 * Validated in May 83 per ANSI X3.9 full 1978 standard * Next release - record structure, CDD interface, possibly global optimizer. In this release an invalid __ ____ _______ __ _______ substring will once again be treated as OK. (Yea!) _________ ____ ____ _____ __ _______ __ ___ o PASCAL ______ * V2.0 shipped in Dec 82 * V2.1 in April 83 * V2.2 expected in Aug 83 * Meets ISO ANSI/IEEE standard * Full RMS and string support * Next release - CDD interface, performance increase o PL/I ____ VAX/VMS LAYERED PRODUCT LANGUAGES Page 8-3 * V1.0 shipped in Jan 81 * V1.4 in Nov 82 * ANSI X3.74 subset * Extensions - G & H floating, RMS, strings * Next release - IBM and full language features, selective list, CDD interface, cross reference o DEBUG _____ * Next release - support for C, PL/I; new symbol manipulation o CMS ___ * V1.0 shipped in June 82 * V1.1 in March 83 * Next release - will be callable, network support, will utilize VMS 4.0 security features o MMS ___ * V1.0 shipped in April 83 - no updates planned yet 8.1 FORTRAN Only one major change to Fortran was talked about and that is the addition of Record structures (like Pascal) to make Fortran compatible with the CDD. No specifics about syntax or capabilities was given. This will be out next summer along with or shortly after VMS 4.0. Some other possible improvements for Fortran include: o A global optimizer may be added. o A LEN= modifier for unformatted Reads. READ (1, LEN=Q) BUFFER o Substring checking will allow null strings. If the upper bound is less than the lower bound, no OUT-OF-BOUNDS error will result. o A .PSECT for initialized variables may be added so all uninitialized variables can be in demand-zero pages. o There are no plans to make Fortran recursive or reentrant. VAX/VMS LAYERED PRODUCT LANGUAGES Page 8-4 LISP 8.2 LISP Digital presented a session on a "language definition" currently unavailable, called Common Lisp. Common Lisp borrows from Interlisp, Maclisp, Spice Lisp and Nil. Its goals include: o Commonality between implementations of Lisp o Portability to machines other than VAX o Consistency between the compiled and interpreted versions o Power for building new systems and languages o Expressiveness through ease of reading and writing o Compatibility with Maclisp and Interlisp o Efficiency to allow compilers to produce good code o Stability once the language has been defined Some non-goals are: o Graphics o Object-oriented programming o Rigidity. Common Lisp is a fully interactive language with full lexical scoping, dynamic linking, dynamic storage, macro facility, minimal syntax, typeless variables, and a rich set of data types. It also has a built in hash facility and many built in functions and features to enable the writing of maintainable programs. Some of these features are described in more detail below. o Common Lisp uses Lambda lists as its basic definition of functions. These lists have optional arguments which can have default values, arbitrary arguments and keyword arguments. o Lexical scoping allows the compiled and interpreted code to execute identically. o A macro facility allows shorthand macro definitions but does not allow user-defined special forms because the compiler would have to be taught about each one in order to get good optimized code. VAX/VMS LAYERED PRODUCT LANGUAGES Page 8-5 LISP o Declarations are totally optional. While this may lead to improved efficiency in the code, it does run slower if no declarations are used. o Common Lisp's datatypes include: * numeric, including integer, ratio, floating point, and complex * character, including symbols, lists, string arrays, and vector arrays * structures, including functions, streams, hashtables, read tables, and powerful string manipulation * user defined record types and generalized variables A powerful set of I/O facilities includes streams (character or binary), read macros and read tables, format, and pathnames which take VMS file specifications and translate them independently of the operating system. CHAPTER 9 VAX INFORMATION ARCHITECTURE (VIA) The VAX Information Architecture (VIA) comprises a group of software products which are designed to "play together" to satisfy the user's needs for data management, manipulation, and display. Two new members have been added to VIA, DECgraph and DECslide, and one has been replaced: FMS has been replaced by TDMS. Thus, DATATRIEVE can reference DBMS and TDMS, DECgraph can reference DATATRIEVE, etc. Normally all data definitions are stored in the Common Data Dictionary (CDD). DECgraph and DECslide are covered in this report in the GRAPHICS chapter. 9.1 DATATRIEVE V2.0 VAX-11 Datatrieve V2.0 is expected to ship in the June-July '83 timeframe. As expected, it includes almost all of the features presented during the Fall DECUS "VAX-11 DATATRIEVE Future Directions" session. Since last Fall's session was covered in detail in the last trip report, only significant changes will be mentioned here. Refer to the DATATRIEVE Handouts (DSIG pp. 1-8) for details. NOTE As mentioned in other sections of this report, Digital has decided not to totally abandon FMS support in the ___ next major release after V2.0. However, don't expect to see any new features added! There is also an interesting note in the TDMS manual which says that you must select either FMS or TDMS support when __ DATATRIEVE is installed. No happy coexistence! VAX INFORMATION ARCHITECTURE (VIA) Page 9-2 DATATRIEVE V2.0 o Documentation has been "significantly revised and expanded". It is to include more and better examples, and a new volume entitled "Guide to Customizing/Programming" which specifically addresses the callable features of DATATRIEVE. o DBMS ready and access has been improved by about a factor of 2. o Improved control over record locking using SET [NO] LOCK-WAIT. This allows a "wait forever" condition or the option of giving up after 15 seconds. o User now has field level access to forms so that you can update a specific field using syntax such as PUT-FORM TYPE = BUILDER|||MODEL o Distributed access can include PDP-11 nodes as long as they're running DATATRIEVE-11 V3.0. o Now able to eliminate duplicates in CROSS clauses by use of the REDUCED syntax such as PRINT YACHTS REDUCED TO BUILDERS o Printout can be directed to multiple destinations (terminals, files, queues, etc.) using the ON command: ON TT: ON PRINTFILE.LIS BEGIN ..reports ..printing END o New boolean expression "STARTING WITH" and the older NE and CONTAINING now take lists FIND BUILDERS STARTING WITH "A","B","C" o EDIT can now access any CDD dictionary object. ___ 9.1.1 Application Hints Dan Dietterich of DEC (DSIG pp. 65-74) provided the following tips: o If you want to display and then modify a record in a READY MODIFY SHARED domain, PRINT, then MODIFY witin the same loop to ensure that what you see is what you modify. VAX INFORMATION ARCHITECTURE (VIA) Page 9-3 DATATRIEVE V2.0 o If you set LOCK-WAIT, there is no way of aborting - ^C does no good! 9.2 FMS The major news about FMS is that DEC has recanted their previous position that DATATRIEVE would no longer support FMS after the next major release (DATATRIEVE V2.0). Although FMS has lost its place in the VAX Information Architecture to TDMS, DATATRIEVE will continue to support FMS. In a separate ____ session, one of the DATATRIEVE developers acknowledged the continued support but implied that it would only be at the current level. Features such as date fields, scrolled windows, etc. will be implemented with the TDMS interface, but probably never with FMS. In a VIA overview session, the following guidelines were given relative to FMS/TDMS: o FMS is the product of choice where * Compatibility with RSX is required (TDMS will never run under RSX) * No requirements to interface with any other VIA product o TDMS is the product of choice where * New applications are being written * Close interaction with other VIA products is required 9.3 TDMS TDMS is a relatively new product which, like FMS, allows the use of forms to collect and display information on a terminal. TDMS also preserves modularity since all of the forms and record and request definitions are external to the user's application programs. TDMS is now recommended by DEC for all new applications, for any application where interaction with other VIA products is required or anticipated, and where cross-system (RSX) compatibility is not required. An upgrade license is available which allows a site which is currently licensed for FMS to change to TDMS for a modest sum. VAX INFORMATION ARCHITECTURE (VIA) Page 9-4 TDMS 9.3.1 Record Definitions Record definitions define the type, structure, and length of the data in the records and are stored in the CDD. Data records may be created using the CDD Data Definition Language (CDDL), VAX-11 DATATRIEVE or VAX-11 DBMS. If the user's application is written in a language which supports access to the CDD (currently BASIC and COBOL, soon to be virtually all languages including FORTRAN), the CDD definitions may be referenced directly. Otherwise, they must be redefined in the user's program. 9.3.2 Form Definitions The form definition describes what is displayed on the terminal at run time. It includes cursor control, scrolled areas, help messages and video characteristics. Forms are created interactively using the Form Definition Utility (FDU) and are placed in the CDD. You can use the FDU to convert an FMS (V1 or V2) form file (.FRM) for use by TDMS. 9.3.3 Requests The heart of TDMS is the request, for it controls what information is displayed/collected on the terminal. This eliminates a major portion of code from the user's program. A request can: * Display a form * Allow data to be entered on the form and transfered to the record * Allow data to be transfered from the record and displayed on the form * Perform above operations conditionally depending upon information previously entered by the operator or returned by the program 9.3.4 Documentation TDMS seems to be much better documented than other similar products and includes six separate manuals and a reference card. There is a sample program coded in three different languages (BASIC, COBOL, and FORTRAN). The TDMS Sample Application Manual goes through this sample program in great detail and includes the source of each version of the program VAX INFORMATION ARCHITECTURE (VIA) Page 9-5 TDMS and of the form and request definitions. CHAPTER 10 TOOLS (VNX) 10.1 UNIX Digital's commitment to "continue to be the leading supplier of UNIX* based systems worldwide" is made in conjuction with their announcement of a Digital supplied native mode UNIX in late August or September for the VAX 11/730, 750, 780 and 782 and continued expansion of VNX, a UNIX-like programming environment designed to give users the broadest possible operating system functionality in conjunction with VMS. Currently VNX is made up of DEC's C compiler; CMS, a code management system similar to the UNIX SCCS; MMS, similar to the UNIX MAKE utility; and VMS with all the layered products currently available. Digital plans to add the Shell, the UNIX command language, and several other utilities offered with the standard UNIX. What will the DEC version of UNIX be? Basically, DEC will be distributing a binary version of all the standard features that are on the Berkeley distribution tape which includes several enhancements over AT&T UNIX. This includes the support of virtual memory, command and mail processing, screen editing, programming languages, improved job control, and file system extensions. To this DEC will add improved error logging ability, the DEC bad block revectoring, and improved documentation. In addition Field Service, including telephone consultation, and Education and Training support for Digital-supplied UNIX operating systems will be available. DECnet between UNIX and VMS systems, cross compilers, file transfer and mail utilities are strong considerations for future software releases. The decision as to which version of the Berkeley distribution (4.1 or 4.2) will be supported will be made sometime in the early summer. For those of you who know little or nothing about UNIX, here is a brief introduction to it. UNIX, the operating system developed at Bell Labs, is a multi-user time-sharing operating _______________ * UNIX is a registered trademark of Bell Labs TOOLS (VNX) Page 10-2 UNIX system. Its strong points include a friendly environment for the systems programmer, program cooperation made up of pipes, powerful command languages selectable on a per-user basis, symbolic debugger tools, and the support of many high level languages. UNIX is not, however, designed for real-time support. Generalized inter-process communication is limited strictly to pipes, with a common ancestor required. Asynchronous I/O is also unsupported. In UNIX, the theory that no news is good news is upheld. Status information is generally not given unless there is a problem, sometimes leaving the user wondering what is going on. Because there is no file protection, anyone can modify the operating system -- __ ____ __________ considered to be an advantage to the system programmer -- or wipe out an entire directory with no questions or complaints from the system. Another philosophy UNIX holds to is that a program should do one thing and do it well. In other words, its commands are meant to act in conjunction with one another and basically don't do much on their own. There are several utilities that are quite powerful however. o MAKE which defines dependencies between files based on modification dates. o LINT, a C language style checker which looks for such things as incompatible types, procedure calls with the wrong number of arguments and non-portability issues that the C compiler does not look for. o LEX and YACC, a scanner and parser used to get a user-defined language compiler up and running quickly. o ROFF and NROFF, text processors analogous to Digital's Runoff. UNIX is written in its main language, C. C is a high-level, low-level language almost as powerful as assembly language. The UNIX kernel includes 7,000-10,000 lines of C and 1,000-2,000 lines of assembly language. Its file system is similar to Digital's with a hierarchical directory structure. The root directory is defined as "/" and all directory levels are seperated by "/"s. Relative path names are indicated by the presence or absence of a leading "/". A "." indicates the current default directory, and a ".." indicates the parent directory. "CD" means change the default directory, "CD junk" means go the subdirectory junk, and "CD ../.." means go up two levels in the directory tree. I/O under UNIX is relative to a file descriptor. There is no internal file structure imposed on a file as in RMS. In reading and writing, UNIX tries to anticipate what you are going to do next using delayed writes and advanced reads. For example, if you are reading each element in an array, UNIX will read ahead of you and keep the next element in memory in TOOLS (VNX) Page 10-3 UNIX anticipation that you will read it next. Reads and writes are done as a sequential stream of bytes or a flow of data thus making device independence possible. File descriptors decide to which device the input and output will go. Standard input, standard output and error messages are sent to the terminal by default. These can be redirected so that any of the three can go to a file or another device. This is the idea behind pipes, which will be discussed in more detail later. I/O functions include: o open, creat, read, write, close, pipe o lseek - random access read or write o fd2dup - duplicates an already existing file descriptor o dup2 - attaches one file to another Other functions include: o fork - creates an exact copy of the process executing it o exec - replaces the existing process with another o exit - passes status to the parent process o wait - waits until the child process has finished execution Fork and exec used together has the same effect as the DCL command SPAWN. The UNIX Shell has a basic command structure of "file arg1 arg2" UNIX then searches for the file given and executes it. Some examples of the general usage are as follows: o shcmd > file - redirects output to file or device o shcmd >> file - appends output to existing file o shcmd < file - redirects input to file or device o shcmd < infile > outfile - both input and output are redirected o shcmd $ - creates a background process so that one can edit, etc. while running a program o ..'shcmd'... - text between quotes is treated as a shell command then substitution of the command by its output o (shcmd;shcmd2;shcmd3) $ - spawns three commands executed one after the other o shcmd1|shcmd2|shcmd3 - standard output of first is attached to standard output of second, etc. Some Shell commands include: o who - lists login name and terminal number of each user o ls - lists contents of current directory o wc -l file - lists number of lines (chars, words) in file (uses standard input if no file given) o sort - sorts file and writes sorted text o grep string file - search for character string in file and write to standard output o rem file - deletes file TOOLS (VNX) Page 10-4 UNIX o tee file - copies standard input to standard output and to file o p file - print file, displays 22 lines at a time and waits for CR before displaying next 22 lines o cat file1 file2 - concatenates file1 with file2 o lorder objfile1 objfile2 - gives ordering relation for a set of object files (loader goes through the archive in this order when linking modules) o ar x lib [file(s)] - extract from an archive o ar cr lib file1 file2 - creates an archive o comm [options] file1 file2 - writes to standard output all lines found in file1 but not in file2, lines from file2 but not in file1 o diff - lists differences between two files - if no differences you just get another prompt Using some of the command structures and commands given above, one can create various functions. For example, "who|wc -l" gives the number of users logged on. "who|grep frank" displays what terminal Frank is using while "who|grep tta7" dislays who is logged in at that terminal. To execute an image, simply type the filename. If this file is an executable image, UNIX creates a subprocess and executes it within the subprocess. The above examples illustrate the flexibility that can be created using the Shell, pipelining, and UNIX utilities but also illustrate the lack of consistency between command syntax and the overall simplicity of each of the commands. They are meant to be used in conjunction with each other, not to stand alone. 10.2 DEC/MMS - MODULE MANAGEMENT SYSTEM MMS is a relatively new product from DEC which is functionally equivalent to the UNIX MAKE program. MMS is a tool used for building or rebuilding a software system using minimum resources and programmer time. MMS determines which components of the software system have changed since the last time the system was built and regenerates them. For example, a large Fortran program might have it's common blocks defined in files which are INCLUDEd in various subroutines. When you want to make a new executable, MMS will recompile all routines which Include other routines which have changed. MMS is a general purpose tool which handles dependencies of any kind based solely on the relative dates of the two files. If one file is defined as being dependant on another and the latter has a later date then MMS triggers a user-supplied DCL command (such as FORTRAN/DEBUG) to update the dependent file. All the dependencies and DCL action commands are contained in TOOLS (VNX) Page 10-5 DEC/MMS - MODULE MANAGEMENT SYSTEM a file used by MMS which must be kept up to date manually by the user. 10.3 FUTURE TOOLS WE MAY SEE SOMEDAY There was considerable interest in tools to improve the quality of software and increase the productivity of programmers. DEC has a tools group which is introducing new products when the market seems strong enough to profitably support them. CMS is their first product and MMS is their second. DEC has a number of software tools internally which they have no intention of converting to products unless they would be sufficiently profitable. There was strong interest in having DEC present a seminar at the Fall DECUS describing their internal approach to software development and some of the tools they use. Tools which they hinted might be available in the future include: o A Specification Writing and Reading Aid to assist in the requirements phase of a project. o A Test Management program which would manage testing of a program by automatically running a set of predefined tests against the new version and comparing the results against tests on previous versions. o A Dynamic Analysis program which would monitor a program's performance at run time to see where it is spending its time, where its page fault overhead is highest, etc. o A Configuration Management program. o A program to provide visibility to project management of what's happening down in the trenches. o Language editors - this is an editor which knows the syntax of the language in which you are attempting to code and does a lot of the syntax checking and insertion for you. This would be like inserting a DO statement and having it automatically insert the ENDDO for you. I suppose it would also do auto-indentation and other beautification sorts of things. o A Static Source analysis program which would maintain a cross-reference data base of the entire program and could give the subroutine calling tree or every place in the entire program that a variable is set or referenced. CHAPTER 11 NETWORKING AND COMMUNICATIONS 11.1 DECNET PHASE IV The discussion of DECnet Phase IV, coming with VMS V3.4 in the August to September time frame, started with a summary of the growth of DECnet in functions, facilities, and topologies. This growth is summarized below: o Growth In Functions - Phase I and Phase II - task to task, file transfer - Phase III - network management, homogeneous virtual terminal, adaptive routing - Phase IV - heterogeneous virtual terminal, X.25, SNA o Growth In Communications Facilities - Phase I and Phase II - point to point - Phase III - multipoint - Phase IV - Ethernet, X.25 o Growth In Topologies - Phase I and Phase II - point to point - Phase III - star/mesh - 200 node max size - Phase IV - bus - 1000 node max size Following the discussion on the growth of DECnet, an overview was given on Phase IV DECnet itself. Following is a list of the DECnet Phase IV layers and some of the changes incorporated. NETWORKING AND COMMUNICATIONS Page 11-2 DECNET PHASE IV o User - remains basically unchanged from Phase III DECnet o Network Management - handles the Network Information and Control Exchange Protocol (NICE), the Event Logger Protocol, the Ethernet Loop Test Protocol, and X.25 support o Network Applications Layer - handles the Data Access Protocol, Network Virtual Terminal Protocol, X.25 Protocol, SNA Protocol, and Loopback Mirror Protocol o Session Layer - remains unchanged from Phase III o End Communications Layer - handles NSP Protocol as well as some performance enhancements such as cross-channel piggybacking and retransmission of connect initiate messages o Routing Layer - supports Ethernet, X.25 and DDCMP. It also supports larger networks and handles the compatibility with Phase III. o Data Link Layer - handles DDCMP, Ethernet, and X.25 protocols o Physical Link Layer - Addition of DEUNA and Ethernet Not mentioned in this talk, but somewhere else, was the fact that DEC only guarantees that Phase IV DECnet will work with another Phase IV or Phase III node. DEC has stated that they did not try to make the two incompatible, but will not guarantee that they are not. Other network happenings: o VAX PSI 2.0 will support the KMS11-P at 19.2 and 64 Kbps in addition to the DUP11. It is expected to ship in June 83. PSI is now fully supported by Software Services. o The Ethernet DEUNA interface will be available in July. A new Ethernet connection hub, the DELNI, can accomodate up to 8 nodes, with just one tap to the coaxial cable. The node cables may be up to 40 meters in length. 11.2 ETHERNET INSTALLATION Ron C. Souter of DEC gave a presentation on the installation of ETHERNET physical channel components. It was pointed out that although Ethernet products are manufactured from one common Ethernet specification, some differences exist in the NETWORKING AND COMMUNICATIONS Page 11-3 ETHERNET INSTALLATION Ethernet installation procedure and guidelines recommended by other vendors for their Ethernet products. This presentation defined the four major phases of the network installation process as well as the Physical Channel Components. 1. Feasibility survey - Issues such as building structure, occupancy, local codes and Ethernet configuration factors must be covered. 2. Planning. This combines the data gathered in the site survey with the rules for the hardware of the physical channel in order to determine Ethernet coaxial cable and transceiver drop cable runs, transceiver placement, and a ground system. The output of this step is a System Plan, which lists the required parts and details the appropriate procedures for installing the Ethernet physical channel components in the building site. 3. Installation - includes the Ethernet coaxial cable, transceiver drop cable, cable connector hardware, the Ethernet transceiver, and system grounding components. 4. Test - should also be done whenever the network is to be expanded or reconfigured, and when maintenance is indicated. There are tests available to verify proper operation of the Ethernet coaxial cable and interface hardware. The presentation was, in general, an overview of the information contained in a preliminary DEC document titled "ETHERNET INSTALLATION GUIDE." This document was designed to assist the customer and Field Service personnel who are responsible for Ethernet installation. 11.3 COMMUNICATION SERVERS Communication servers are dedicated, special purpose communication subsystems. They are shared resources in a network. There were three such communication servers discussed. They are as follows: o Terminal Servers - provides network virtual terminal connection to a host via Ethernet * Applications - Large terminal networks - Geographically distributed networks * Benefits - Offloads virtual terminal processing from host - server is downloaded by host NETWORKING AND COMMUNICATIONS Page 11-4 COMMUNICATION SERVERS - Fewer direct terminals connected to host - up to 32 terminals per server - Non-blocking terminal switch - Has autobaud and modem control * Availability - expected in "Summer 84" (Ethernet only) o DECnet Router - provides message routing within networks of similar systems; acts as gateway to LANs * Benefits - Routing function offloaded from local host - Improved network reliability - Shared cost of connection to outside world * Availability - expected in "early 84" o Gateway - provides communications with host having foreign vendor network * Applications - Multi-vendor network connection - Large terminal network - X.25 gateway will be on Ethernet - hosts runs "X.25 Access" package * Benefits - Gateway processing offloaded from host - Shared cost of connection to public packet switching networks - Multi-vendor communications * Availability - expected in "early 84" A few more details were gleaned from the Q & A which followed: o Performance improvements in Phase IV? Cross-channel piggybacking. Also, "SET HOST" has been improved in V3.4, and again in V4.0. o Is DECnet still bundled in VMS? Yes, DECnet 3.1 comes with VMS 3.4, but you will need a "key" to turn on multi-node DECnet. This is only furnished if you are currently under DECnet S/W maintenance. (Ed - In V3.0 this key was a short patch to NETACP.) However, the DECnet licensing policy has been significantly changed. VMS and RSX systems may be classified as "full nodes" or "end nodes", while RT-11 systems may only be end nodes. The end node license will be quite cheap. NETWORKING AND COMMUNICATIONS Page 11-5 COMMUNICATION SERVERS o Since the various routers, servers, and gateways are really PDP-11s, will a single box be able to perform multiple functions? No. o Will the terminal server support access to non-DEC hosts? Not in first release. o Plans for a TCP/IP gateway? No. o Ethernet to non-DEC nodes? Next DECnet release (4.0?) has a user interface to the data link layer of Ethernet. o File and line printer servers? Another group is looking at this. o Host loading when running EDT over terminal server? DEC is "concerned" about this. To reduce overhead, a Local Area Terminal Protocol (LATP) will be used in lieu of DECnet. The server waits a programmable time delay, then sends what characters it has to a given host. If none, then it sends an empty symbol as a keep-alive message. The character streams are demultiplexed in the DEUNA driver and passed to TTDRIVER. DEC is also investigating the possibility of distributed EDT and FMS, since these are the worst offenders. o Publish specs on terminal server? Yes, and maybe offer an OEM box for 3rd party vendors. o We need the ability for the host to dynamically attach to a particular terminal for graphics, plotting, etc. The location of this terminal is not known until a user logs in or runs some application. Sorry, the support will be static only. o How will a user select a destination via the terminal server? "SET HOST node". o An easy way to print a local file on a remote node (with all default options) is "$COPY FOO.BAR node::LPA0:" o A good number of the QIO calls to the Network Management Listener (NML) are undocumented. "$ ASSIGN n NML$LOG" on the remote node and observe the transactions. (Ed - the same feature is embedded with FAL. FAL$LOG is a hex 8-bit mask which selects what internal items are logged. Try it for yourself.) CHAPTER 12 COMPUTER SECURITY There were several sessions to discuss computer security as it relates to VAX/VMS. Topics included access control lists, network security, security in the commercial environment, and computer security in general. 12.1 VMS ACCESS CONTROL One major topic is the VMS Access Control List as it may be (is?) implemented in VMS V4.0 (VSIG pp. 39-45). Security is required to 1. Protect information from unauthorized distribution 2. Protect information from accidental or intentional destruction. In order to see how the VMS developers intend to meet this need, it is necessary to define a few terms: o OBJECT - anything that exists in the system to which a protection may be applied such as files, devices, and volumes o AGENT - anything that generates request for access to an object. Such requests must be checked to determine whether access may be granted. Examples include a process or a device. o IDENTIFIER - a unique way to identify a group to which one or more agents belong. Some aspects of an identifier are: * Internally represented as a unique 32-bit number * Externally represented as an alphanumeric name * May be defined at several levels - system wide, group wide or per user. o ACCESS CONTROL LIST - a collection of entries (ACE) that determine what access is to be allowed to an agent for a object. Some aspects of ACLs are: COMPUTER SECURITY Page 12-2 VMS ACCESS CONTROL * An ACL may contain one or more ACEs * An object may have only one ACL * For files, ACLs are propogated from a previous version of the file, or the parent directory In order to meet both requirements outlined earlier, an object must possess both a "security level" and an "integrity level". In each case 256 levels are available, ranging from 0 being least sensitive or trustworthy, to 255 being most sensitive or trustworthy. Other properties, however are almost opposite. o Security Properties - designed to prevent disclosure * READ: Agent .GE. Object (simple security property - agent cannot read more sensitive information) * WRITE: Agent .LE. Object (confinement property - agent cannot write less sensitive information) o Integrity Properties - designed to control modification * READ: Agent .LE. Object (Agent cannot read less trustworthy information) * WRITE: Agent .GE. Object (Agent cannot write more trustworthy information) In summary, security allows the user to read down and write up, while integrity allows the user to write down and read up. Each type of protection will feature a 64-bit mask identifying categories. For security, these might correspond to "NATO", "NO FOREIGN", etc. The ACL system will permit great flexibility, including the ability for one user to allow only certain other users to access his files without regard for current group membership. Unfortunately, this flexibility also leads to the necessity of educating the user community - otherwise the system manager/security manager will spend a good deal of time helping users access objects which are improperly protected. 12.2 NETWORK SECURITY - PROXY LOGINS Andy Goldstein of DEC presented a talk on Network Security (VSIG pp. 125-130). First some general tips on network security: o Scrutinize non-VMS nodes. Look for exposed passwords since they are stored unencryted. o Never, never place passwords for privileged accounts in command files. COMPUTER SECURITY Page 12-3 NETWORK SECURITY - PROXY LOGINS o DECnet default account - the best solution is not to have one. Otherwise, prevent its use by interactive and batch jobs and network "task" access. Set the "DISUSER" and "CAPTIVE" flags for that account, and specify an explicit login command file that is not in that directory (e.g., ___ SYS$SYSTEM:NETLOGIN.COM) $ IF F$MODE() .NES. "NETWORK" THEN LOGOUT $ SHOW LOGICAL SYS$NET To get a brief audit trail on remote file accesses, modify SYS$SYSTEM:FAL.COM $ SHOW LOGICAL SYS$NET $ DEFINE FAL$LOG 1 !Displays requested filespecs $ RUN SYS$SYSTEM:FAL $ IF F$USER() .EQS. DECNET UIC THEN - RENAME *.COM;* *.XXX;* !Prevent "TASK=XYZ" access The current default access mechanism is insufficient because: a) It is non-selective of who can use it b) It provides insufficient protection and accessibility - you must give world access or nothing. The current explicit access control is insufficient because: a) It is cumbersome b) There is a risk of password compromise c) A routing node could "wire tap" passwords passed in the clear d) It is difficult to audit The solution to all this is proxy login. At the Fall 82 DECUS, Gerry Smith spoke of the unsupported, undocumented proxy login feature embedded within VMS and DECnet-VAX. Since that time, DEC has gained considerable experience with proxies on their Engineering Net. In addition, a number of sites have experimented with the feature and provided feedback to DEC. They now feel confident enough to publish the details in the VAX SIG handout, and expect to support it in the near future. (DEC developers had first hand experience with network security problems this past summer when the E-net was penetrated by students who sneaked in to play Dungeon. A challenging cat and mouse game persisted for several weeks!) Proxy login allows a selective mapping between the user communities on different nodes: o Control and audit is by individual username o No passwords are transmitted o If there is no entry in the proxy data base, default access is used COMPUTER SECURITY Page 12-4 NETWORK SECURITY - PROXY LOGINS o The user may override proxy with explicit access control. He can also force default access with a null access control string (""). The proxy data base, SYS$SYSTEM:NETUAF.DAT, is contains entries of the form VAXF::JONES JONES VAXE::JONES2 JONES or VAXA::* * The Authorize utility is used to maintain the proxy file with commands like - CREATE /PROXY - ADD /PROXY node::user local_user - REMOVE /PROXY node::user - LIST /PROXY - SHOW /PROXY node::user - SHOW /PROXY * This information is currently in the Authorize help library, but commented out. To expose it, use the librarian to extract SYSUAF.HLP from SYS$LIBRARY:SYSUAF.HLB, uncomment the pertinent sections, and replace the library. Proxy access may be specified as "none", "incoming", "outgoing", or "both" for each node, object, and the executor. Outgoing proxy is recommended as it produces an audit trail - the username replaces the PID in the ACS, and therefore shows up in SYS$NET on the remote node. Note that proxy login is incompatible with non-VMS operating systems. It also conflicts with the use of default outgoing access control because on the remote node it is indistinguishable from an explicit ACS. To enable proxy login: 1. Set the executor characteristics - PURGE EXEC PRIV USER PASSWORD ACCOUNT - DEFINE EXEC DEFAULT PROXY OUTGOING - DEFINE EXEC PROXY BOTH 2. Enable proxies for selected nodes - PURGE NODE xxx PRIV USER PASSWORD ACCOUNT - PURGE NODE xxx NONPRIV USER PASSWORD ACCOUNT - DEFINE NODE xxx PROXY BOTH 3. Set object characteristics - DEFINE KNOWN OBJECTS PROXY BOTH - DEFINE OBJECT MAIL PROXY OUTGOING - DEFINE OBJECT REMACP PROXY OUTGOING - DEFINE OBJECT TASK PROXY OUTGOING !Your choice It is important to note that the proxy system is not totally COMPUTER SECURITY Page 12-5 NETWORK SECURITY - PROXY LOGINS secure. It is dependent on the integrity of the remote system as well as the local one. If a user can change their username on the remote system, they may masquerade as someone else on yours. A less likely but possible problem is that of node impersonation. The important rule to remember is don't use _____ ___ proxies for privileged accounts. _______ ___ __________ ________ Other issues that came up in the Q & A: o They will provide a way to prevent users from using explicit access control strings (forcing proxy). o What about encryption? They have tried a software DES algorithm and got 1200 baud out of an 11/780! They are now looking at hardware solutions, public key systems, etc. o Having the Professional Computer on Ethernet blows our network security. Yes, wait for encryption. o The "promiscuous" bit on the DEUNA allows one to look at the contents of every packet. Ditto - wait for encryption. 12.3 MISCELLANEOUS TIDBITS ON VMS SECURITY o Most systems are careful not to permit WORLD access to SYSUAF.DAT and SYSUAFALT.DAT. Many are not so careful about copies of SYSUAF.LIS. While this doesn't show passwords, it does show what usernames have privilege and thus provides a nice "shopping list" for would-be interlopers. o With the advent of the personal computer, and especially of DECs PRO line with its file transfer utility, correct file protection has become even more important. Beware of people running SYS$SYSTEM:PFT.EXE if it exists on your system. This is the PRO file transfer utility, and it may indicate that someone is pilfering files! o Insist on non-trivial passwords for all users, but especially for all privileged accounts. o DEC is reluctant to log the username in a login failure accounting record because it might disclose a valid password. o If you can help it, don't publicize dial-up numbers, or store them in world-readable files. COMPUTER SECURITY Page 12-6 MISCELLANEOUS TIDBITS ON VMS SECURITY o For VMS V4.0 DEC is exploring a number of break-in detection schemes. One rather extreme method would require call back on dial-in. o Doug Brown of Sandia National Labs is using a fiber optic V.35 DMR11 link at speeds up to 1 Mb. Doug also has a random pronouncable password generator program. o Will VMS 4.0 be delivered (with file protection) "tighter"? No, upward compatibility is a must. CHAPTER 13 GRAPHICS 13.1 CURRENT GRAPHICS PRODUCTS Donald Feinberg, DEC Supervisor of Display Systems Software, gave a "Graphics Products Overview". The information of interest was in the Q & A: o What's happening with your implementation of GKS (Graphical Kernel System)? We have a product but can't make any announcement yet. It has been designed for easy migration to RSX and P/OS. It will support a large device base. It will be a superset of the current Rainbow 100 capability, and will definitely be supported on the Rainbow. o When will we see multiple device support in CGL (Core Graphics Library)? Not sure. o Why is the VS100 (VAXstation) availability still slipping? The official ship date is now November 1983. It was announced in June 82. It is a complex product and we have also had problems getting the fiber optic interface to handshake properly. Future releases will support ReGIS. o What became of the GIGI? It is out of production. Its software including the graphics editor, is being converted to run on the VT125 and newer terminals. on the VT125 and newer terminals. o Are there any plans to offer PLOT-10 on newer terminals (VT240, VT241)? No, only on the VS100 for now. The VT24x will handle GKS, to which most commercial applications are expected to convert. GRAPHICS Page 13-2 DECSLIDE 13.2 DECSLIDE DECslide is a new product which will be available in Fall 1983 and is used with a VT125 for creation of text and graphics for slide presentations and hardcopy output. DECslide gives you ready-made figures for your design work. It also lets you make line drawings and enter text, and you can change the size and orientation of your designs. You prepare your work in black and white, and later you can add color to your designs, depending on the available output devices. Hardcopy capability is presently only supported using LA34-VA and LA100 printers. For color output, one would need to buy a film-type copier such as are made by Polaroid, Matrix, and others. 13.2.1 Menus DECslide uses two kinds of menus to present design options: 1. Iconic menus - DECslide's initial screen and utility menu use icons with symbols to represent choices for you to start and finish your design work. 2. Word list menus - DECslide uses word lists for its other menus: the object, change, and paint menus. DECslide displays these menus in the message line at the bottom of your screen. DECslide uses a highlight to let you choose a menu option. In the iconic menus, this highlight is a light-shaded square. In the word list menus, the highlight is a box that frames your option. You use the arrow keys to move the highlight to the desired option. Then you select that option by pressing the ACCEPT key (on the keypad) or the RETURN key. 13.2.2 Design Options DECslide offers you a variety of figures: a square, circle, triangle, and arc. You can make your own line drawings and enter your own text. After you select or create your entry, you can: o Change the entry's size, orientation, and pattern (figures only) o Join entries into a compound object or separate them from this object o Copy and move the entry GRAPHICS Page 13-3 DECGRAPH 13.3 DECGRAPH DECgraph is a new product which will be available in Fall 1983 and is used with a VT125 to produce charts of the quality required for presentations. Users do not need to know anything about plotting languages or routines. To help introduce new users to the product, DEC includes a tutorial session in the User's Guide. 13.3.1 Hardware Requirements At this time, DECgraph can use the LA34-VA or LA100 printers to provide black and white hardcopy. Color copies require the use of a color film copier such as those sold by Polaroid, Matrix, and others. 13.3.2 Menu System DECgraph offers a series of menus containing icons. The icons present choices for entering data, designing charts and displaying charts. Help is available by using PF2 on the keypad and includes multiple levels of help. Help is available for o An icon that is highlighted o A question that is asked o A field that is to be filled with a value Data may be entered from a file, from the keyboard, or from DATATRIEVE. In order to use this feature, you MUST have at least Version 2 of VAX-11 DATATRIEVE. The data you use must be in the DTR collection named CURRENT. 13.3.3 Chart Types o Stacked bar chart o Cluster bar chart o Line chart o Pie chart o Scatter chart o Histogram A cluster chart is a type of bar chart you can use to show trends of two or more factors over many periods. The cluster chart consists of bars of equal width placed side by side with no space between them. CHAPTER 14 PRO-SERIES PERSONAL COMPUTERS 14.1 APPLICATION DESIGN On Sunday, May 22, John Lucas II of DEC Educational Services gave a pre-symposium seminar titled "Design of Applications for the Professionals". This was largely targeted to OEMs currently producing or contemplating applications for the PRO-300 series computers. The presentation was supplemented with a very useful handout. This report will not attempt to replay the day-long lecture, but will concentrate on items not easily discovered in the open literature. 14.1.1 The User Interface The most important consideration in handling user input is that the PRO supports multiple keyboards for various natural languages. To implement a multi-national character set, DEC extended the standard ASCII set with new values between 128 and 255 decimal. The keyboard is totally soft, with the P/OS terminal driver performing the necessary mapping. The national replacement characters include "@[]{}\|#". This can be a problem under terminal emulation mode for certain computer languages such a "C". When no key legend corresponds to a needed character, the user must perform the "compose character" function to obtain it. One workaround is to tell P/OS that you have a U.S. keyboard, causing it to perform that mapping, regardless of key legends. One must also consider the collating sequence of the current character set in string comparisons, sorting, etc. For example, a German "o" oumlaut is of higher order than a regular "o". An additional note for international applications - translation to a foreign language usually increases the amount of text by 20-30%!. Be wary of key bounce when using defaults in menus. If the DO key bounces (repeats), and the next menu permits a default selection -- ZAP! PRO-SERIES PERSONAL COMPUTERS Page 14-2 APPLICATION DESIGN 14.1.2 Development Tips In general, the PRO application developer is driven by the constraints of RSX11M+, namely the 64KB logical address space limit. Under P/OS, the clustered libraries (e.g. RMS) immediately consume 16KB. Some applications must sacrifice performance to reduce memory requirements. However, the following tips will aid in this effort: o Follow normal RSX procedures: shoot for a flat task, then try overlays, and lastly use multi-tasking. Note that for multi-tasking, you will likely need the 256KB expansion memory option to prevent excessive checkpointing. o Keep forms as small as possible. The resulting impure data is the size of the largest form. o Try to use the same menu format throughout. Different menu classes use separate buffers. o The costs of using a given class of P/OS interface service are incurred if ANY of the services in that class are ___ used. o RMS requires task space for each open file, including the ones created by FDT (Frame Development Tool). Note that these costs are not specified by the designer, and do NOT ___ show up in a task build map. o Use the VMS ANALYZE/RMS and EDIT/FDL utilities (RSX DEFINE) to optimize file organization. Attention to bucket size, number of keys, and multi-buffer count can produce tremendous benefits. The defaults chosen by language compilers are seldom optimal. o You can debug using ODT by connecting a terminal to the printer port. A cable is included with the toolkit. 14.1.3 P/OS V1.5 P/OS V1.5 should be out of SDC by late June. All V1.0 customers who returned their warranty card will automatically receive V1.5 at no charge. This release is considered a mandatory update. It includes a number of bug fixes and performance enhancements, as well as OTS support for COBOL-81, F77, and PASCAL. (You also need the V1.5 Toolkit.) V1.5 can be diskette-based, which means the hard disk is no longer a mandatory option. PRO-SERIES PERSONAL COMPUTERS Page 14-3 APPLICATION DESIGN We were told that the error messages are only marginally better in V1.5, and that the documentation is not improved. A migration document titled "Converting Applications to the Professional" is now available (at DECUS). Also Mr. Lucas has been writing a book which includes application examples; he expects it to be available from Digital Press this Fall. The menus and utilities are being revised to permit multiple file selection on a single command (DELETE, COPY, PURGE). V1.5 includes some of these improvements. The PRO systems in the exhibit hall and in the PC suite were running P/OS V1.5. We noticed a considerable speed-up in stepping through menus. Much of this is attributable to the 10MB RD51 disk which is significantly faster than the RD50. 14.1.4 Diskette-based P/OS P/OS V1.5 performs a "sniffer boot". If a valid system diskette is in the RX50 drive, it will boot from there; otherwise, it tries the winchester. It is important to note that diskette-based P/OS is a two-diskette system - period. It totally ignores the presence of a hard disk. Once booted, the system diskette may be removed, and an application diskette inserted. This is possible because ~135KB of P/OS is made memory-resident. The remaining tasks and libraries must reside on EACH application diskette, along with a checkpoint file. This can be a terrible constraint, since as yet, an entire application must fit on one diskette (the second drive is for data only). It is almost certain that the 256KB memory expansion option will be required. 14.1.5 Developer's Toolkit On Host In general, the Toolkit products are the RSX products. However, they use RMS for I/O instead of FCS. o PRO-F77 produces different code than the RSX version. o FMS 1.1 is supported. One difference in PROFED (FMS Forms Editor) is the support for the multi-national character set. (One student reported that the output of VAX FED, passed through PROFUT, will run fine on the PRO.) PRO/FMS does not use the tab character to step fields; instead it uses backspace and escape! PRO-SERIES PERSONAL COMPUTERS Page 14-4 APPLICATION DESIGN 14.1.6 Native Toolkit Everyone has been waiting for a native toolkit on the PRO. ("If you guys would just give us RSX and a CLI it would be a nice system ...".) The V1.5 demo systems included a "prototype" toolkit with which we experimented. One selects the Toolkit as a menu item, and voila, you are in DCL. It has a limited command set, and is NOT extendable to user programs. ___ (Boo! Hiss!) However, a good number of the popular RSX utilities are there. We used EDT to create a FORTRAN source file, ran it through F77 and TKB, and it ran fine. The F77 and TKB execution times were quite respectable. Supposely the native toolkit will be priced much lower than the host versions. 14.1.7 Hardware/Firmware 14.1.7.1 Terminal Emulation - Since the PC350 we have been using is a demo unit with P/OS 1.0, we were anxious to discover if a number of the annoying bugs (features?) in terminal emulation have been corrected: o After pressing the "no scroll" key, pressing any other key ___ will resume the scroll. This is intentionally different from the VT1xx, to prevent a user from getting confused by no echo when he accidentally hits no scroll. o Once the keyboard is locked, there is no way to unlock it except to power down the unit. Supposely this has been fixed in V1.5, along with other setup problems. Terminal characteristics are now reset upon return to the menu. Also, the setup menu may now be entered at any time. o The terminal attributes (intensity, bold, blink, etc.) are different from the VT1xx. There are no plans to change this. John Lucas recommends that for PROFED, you are better off using the terminal emulation mode because of this incompatibility. o Why is the terminal limited to ~4800 baud? The terminal "firmware" is actually run by the CPU. Keep this in mind when selecting display attributes, especially blinking. The speed is better than 4800 baud, and always better than a VT100 (a design requirement). There are no plans to offload any of this processing to hardware, but they are working on code optimizations. PRO-SERIES PERSONAL COMPUTERS Page 14-5 APPLICATION DESIGN 14.1.7.2 Miscellaneous - o The parity setting is reversed on the communications port. o The production version of the PRO fixed a number of bugs in the field test hardware. o One user complained about the fan noise. He replaces the fan with a quieter one. The desk mount helps considerably because the fan exhausts near the floor. 14.1.8 Graphics A few tips from Mr. Lucas on use of the PRO Core Graphics Library (CGL): o Use PRO-BASIC as a prototyping language. It uses the CGL although the language syntax is different than the standard CGL calls. o Make changes in the color map to achieve animation speeds. It is much faster than replotting. The bicycle demo uses this technique. o Make text size >= normal text-mode characters. Kodak recommends a vertical ratio of <= 17:1 (the PRO's is 24). To calculate the proper character size to specify to CGL, first call P/OS to find the current window and viewport sizes. The argument to CGL should equal (window / (viewport * #char/line)). For italic lettering, use a 0-10 degree right slant for best effect. o To get a graphics dump on the LA100, you need the PC font ROM which corrects the aspect ratio. This is included in the LA100-PC. A retrofit kit is available for other models. o DEC is looking at something like ReGIS "save/restore" for CGL. Can you send ReGIS out the printer port while logged into a host via the comm port in terminal emulation mode? Not sure. Could you do a readback of the bit planes? Yes, IF you had the hooks, which is under consideration. o The fill algorithm is much faster in P/OS V1.5. Whenever possible, use "fill to line" instead of "fill to point" - time difference can be 12:1. Alternatives to fill - gray scale using extended bit plane, or use color and solid fill. PRO-SERIES PERSONAL COMPUTERS Page 14-6 FUTURES AND OTHER QUESTIONS 14.2 FUTURES AND OTHER QUESTIONS Jeff Ghanam, Toolkit S/W Engineering Manager, followed Mr. Lucas's seminar with a very frank Q & A: o Will FMS 2.0 be supported? The PRO will track RSX, but supposedly RSX FMS 2.0 is stalled or cancelled! _______ __ _________ o When will we see distributed data access? 12-18 months. o How about licensing the private I/O bus? Under consideration. o RSTS toolkit? Not from Central Engineering - other product lines and S/W Services are looking at this. o Will FCS be supported? No. Does the native TKB use RMS? No, we cheat! The whole kit uses FCSRES, but we won't supply the symbol table file (STB) for support reasons. DEC is extremely concerned about uniformity across the (hopefully) many thousands of PROs, especially with unsophisticated end users. o Supervisor libraries? The hardware does not yet support it, but it is likely for the future. o Access to the Real-time Interface from BASIC? Noted. Laboratory Data Products is developing the RTIF. o Why can't BASIC use the comm port? BASIC uses RMS exclusively, which only supports unit record devices, which the comm port is not. They are looking at a fix. The comm port can handle asynchronous, synchronous, bit, and byte-oriented protocols. Would this include DECnet over a DUP11? Not sure. o Right-to-copy license for S/W? Under consideration. o Digital Standard Runoff? Don't know, but they want it too. o Datatrieve-11? Soon. o Support for other operating systems? Don't want to, but may have to. o Capability for an application to span diskettes? This will be done. (Lucas) Until then, create files with "useropen" for optimal organization. Also, create a file with a very small initial size, and large extend size. o Suppress menu paints on typeahead? Maybe, also looking at memory-resident menus. (Lucas) Dynamic menus are the slowest (e.g., application list) because the hierarchy PRO-SERIES PERSONAL COMPUTERS Page 14-7 FUTURES AND OTHER QUESTIONS must be scanned. o Problems with PFT (running VERY slow or hanging) fixed? Think so. You are better off running it a 4800 baud or less. If the host doesn't keep up, the line will time out. o PRO Hotline response? Taking ~24 hours for a call back. o Are object files compatible with RSX? Yes. o How can my application utilize the printer port? (Lucas) Talk directly to the registers. o Why can't we format our own RX50 diskettes? The diskettes are formatted by the diskette vendor, not by DEC, and there are no plans to change this. Verbatim now sells the RX50s in bulk, and it is likely that other media suppliers will follow. Supposedly, the track density (96 tpi) leaves inadequate tolerance when diskettes are formatted on one drive and moved to another. (User) This is a business decision, not a technical one. If you are a large enough OEM, DEC will give you the format specification (as they did for the user's company). 14.3 MIGRATION ISSUES Richard Kirkman of Filetab Support Services gave a presentation titled "Converting RSX Software to Run on Professional Computers." The paper is reproduced in its entirety in the RSX handouts (RSIG pp. 359-386). Mr. Kirkman provides an excellent discussion of the differences between RSX and P/OS, and offers many good suggestions for migrating and debugging applications on the PRO. He is to be especially commended for successfully patching FCS and a number of utilities to run on the PRO, and for writing an MCR emulator. All of this is detailed in the handout, so I will not attempt to duplicate it here. CHAPTER 15 HARDWARE 15.1 VAX CPUS In a VAX hardware session, the DEC product manager for each CPU gave the current status of their processor: 15.1.1 VAX 11/730 o Now rated at 25% the throughput of an 11/780 under VMS or UNIX. o Dec 82 - supports TU80 tape with expansion cabinet. June 83 - expansion cabinet no longer required. o FP730 is up to 300% faster than microcode o Current options supported in expander cabinet: (1) UDA disk controller (2) DMF32, DZ11, or DZ32 (1) DEUNA Ethernet interface (1) LN01 or LP32 printer (1) DUP11, DR11-W, LPA11-K, VS100 15.1.2 VAX 11/750 o Over 5000 shipped since introduction 2.5 years ago o CI750 consists of four cards in a separate cabinet the same size as the CPU cabinet. They are looking at permitting two CI750s per cabinet. o The requirement for a local system disk on the CI is due to the 750 boot ROM. This will be fixed along with VMS V4.0. HARDWARE Page 15-2 VAX CPUS 15.1.3 VAX 11/780 o Introduction of 1 MByte memory arrays using 64Kb dynamic RAMs. Requires new memory controller - supports interleaving on each pair of arrays. It is not significantly faster than the old controller, so there is no longer an advantage in having two controllers. If you have one old controller and one new type, there is no way to interleave the memory in the old controller. This is quite important if you have an RP07 at the high transfer rate. o There are still lots of sites waiting for CPU Rev 7. Note that all like CPUs in a cluster much be at the same ECO level to allow a checkpointed job to be restarted on another CPU. 15.1.4 VAX 11/782 The only news here is that there are no plans to upgrade the __ _____ 782 memory controller (MA780) to handle the 64 Kb RAM boards. In the brief Q & A that followed, one user requested that all CPUs incorporate an over-temperature shutdown. Terrific applause followed. 15.2 MASS STORAGE 15.2.1 UDA50 Problems The recent press releases on DEC's problems with the UDA50 disk controller caused quite a stir at both DECUS and DEXPO. In the VAX Hardware session, Ron Brown, HSC50 product manager, set the record straight: 1. In September 82 the UDA50 was somewhat redesigned, with its local buffer increased from 12 to 50 sectors. This became the UDA50A. 2. In January 83 an investigation based on field reports determined that a number of RAMs were out-of-spec, and identified microcode bugs in the handling of certain error conditions. The product was put on engineering hold for 7 weeks. HARDWARE Page 15-3 MASS STORAGE 3. Last week (May 83) the hold was lifted. 4. Rumors about problems with the RA81 drive are unfounded. 15.2.2 Foreign Disk And Tape Beware of emulations which make a single large disk appear as multiple smaller disks. Not only can you be left high and dry at VMS update time, but a number of the standalone utilities on the console medium will not operate properly. Likewise for warm restart. 15.3 TERMINALS Digital Product Management hosted a terminals panel for "Current Products and Future Needs". Many attendees were vocally displeased that DEC refused to even acknowledge the existence of new terminals. Two individuals stated that they had quotes from their sales rep for VT240 and VT241 terminals, and one of them had placed orders with a delivery date of September 1983! Supposedly the VT240 is a replacement for the VT100, and the VT241 mimics the VT125 (with color). Other items of interest: o The new version of EDT will utilize the insert and delete features of the VT102 and VT131. o Firmware bugs in the VT102 and VT131 will be fixed! New ROMs are being masked and introduced to production. A mandatory FCO will be released around September, and kits will be available from A&SG for spares. The FCO fixes known bugs with the printer port, parity, stop bits, auto-repeat on/off delay, etc. o The VT1xx drops DTR (data terminal ready) during a setup/reset. Yes, a reset simulates a power-up condition, so it clears all communications. There are no plans to change this for present terminals. New terminals will feature a "soft" reset. o New printer ports will be of the VT102 type (as opposed to the VT125). The Professional Computer emulates the VT102. o There are no plans to offer interlaced scan, as flicker is regulated in Europe. Likewise for P31 phosphor tubes. Instead, larger screens and higher quality monitors will be used to achieve higher resolution. HARDWARE Page 15-4 TERMINALS o DEC terminals marketed in Europe offer amber screens. (A user in the U.S. received one by mistake.) These will not be made available in the U.S. o VT100 throughput is ~6400 baud in jump scroll and ~1700 baud in smooth scroll. o Don't turn off VT1xx flow control (via setup B) if you have a printer connected. o Single-buffered interfaces can be overrun by rapidly-generated terminal sequences. If the terminal sends XON/XOFF the host may only see the second character. All VAX terminal interfaces have silo input. o DEC CSS makes a bar code reading terminal. A session titled "VT100 Magic" was given by Sami Tabikh of Data Processing Design. He described bugs with VT100 type terminals and known workarounds. His session handout included a concise summary of terminal features, known bugs, and short programs which demonstrate them. Check the DECUS proceedings for the full paper. o When chaining escape sequences, make sure any change of column mode is done last, or the remainder of the list will be ignored. o Home the cursor before changing column modes. If not, the total number of lines displayed may be incorrect. Under certain conditions, changing from 132 to 80 column mode can send the screen into hieroglyphics. o Home the cursor before changing scroll modes. Otherwise, going from smooth to jump scroll may reverse index the screen. o Double-wide lines in 132 column mode are very readable and give 66 columns per line. Remember that you must send the escape sequence for each line you want to be double-wide. Bug - if you are on a double-wide line at column 66 and you address the cursor to a normal-width line at a column >66, it will go to 66. It refuses to go to a column higher than the maximum of the current line. _______ o Obscure bug - if a scrolled region is less than the whole screen, and the line above is double-wide, and you are in jump scroll mode, and you scroll the screen, that line will be hieroglyphics. It's ok in smooth scroll mode. o Remember that in "origin" mode, addressing is relative to the scroll region. HARDWARE Page 15-5 TERMINALS o The VT125 is not really a VT100 because the graphics board intercepts all the characters. It must interpret all escape sequences, but likes to see them together. If only a partial sequence should be received, the unit "times out" after 30 MS. You can tell if you have the latest revision of VT125 - on reset, it draws a box and says "VT125 OK". Be careful pressing the "Gold PF1" key or you can end up in graphics mode. To dump the current bit plane to the printer port, store that escape sequence as the answerback string (control break). There is no way to dump the text plane because the escape sequence intended for the LA34 is slurped up by the VT125 (e.g. "enter graphics mode"). o The VT1XX-AC printer port option doesn't garble or slurp escape sequences destined for the printer. The VT102 and VT131 have this bug which is fixed by the coming FCO (see above). o Most VT100 lookalikes do not have the VT1xx firmware bugs, but some do (a bit too-perfect emulation!). o If you feel creative, you can invent new characters by mixing the upper and lower halves of double-height, double-width lines. Note that these will appear different on VT100 lookalikes. o The use of bold and reverse video on the "space" character can be used to make bar charts. o Some attributes that may look fine on a dark background, will not look good on a light background. For example, bold + reverse video on a light backgroundground. For example, bold + reverse video on a light background will produce smeared video. Keep this in mind since you can't anticipate what each user will choose. o Once the keyboard is "locked", there is a seven-character buffer. This can be exploited as a poor man's full duplex. o According to DEC, the preferred way to use the VT100 graphics mode is NOT to change the G0 character set. ___ Instead, set G1 to the graphics set, then use "shift-out" (control N) and "shift-in" (control O) to switch between them. Not only does it require fewer characters to switch, but it lessens the chance of getting accidentally stuck in graphics mode. o Turning on keyboard LED 136 (ESC>[136Q) will sound the bell forever - you must reset the terminal. LED 137 will turn on "hyper-auto-repeat" mode - if keyclick is enabled, you're in music mode, with the shift key changing the octave! HARDWARE Page 15-6 TERMINALS o Some VT100s run at 19.2 kbaud, and some don't. o If your VT100 is "winking" at you, check for a bad solder joint on the crystal pins. Also make sure the power option switch is set for 120V. 15.3.1 Terminal Maintenance On Wednesday, May 25, Dick Devlin of Digital gave a presentation titled "Alternative Approaches to Terminal Maintenance". In his presentation, Dick compared the advantages of the different types of service agreements that DEC offers. These include: Basic, DECservice, Carry-in, Module Exchange, Select-a-Call, DECmailer and Self-Maintenance. The bottom line of his talk was that each customer should be aware of each service option. The trade-offs between cost and uptime can then be considered. Dick pointed out that because terminals are a low cost item to begin with, the Select-a-Call option, where DEC is only called in after more than one terminal is down, saves DEC money which they in turn pass on to the customer in the form of lower rates for this service option. In the area of Self-Maintenance, Dick pointed out that in his experience, companies that elect to do their own maintenance sometimes under estimate the manpower, budgetary funding and facilities needed to efficiently perform self-maintenance. He recomended that there be a full-time person devoted to the self-maintenance effort in order to ensure user acceptance. There should also be an area set aside for storage of tools and spare parts. Finally, the responsible person should be sent to DEC courses for training on the equipment that he will be expected to maintain. Another point that was brought up by Dick and from the floor was that Self-Maintenance should be limited to module exchange. It was pointed out that to test LSI built modules, special real time test jigs would be required. These test jigs would not be cost effective to purchase for most Self-Maintenance customers. The options that DEC offers are module exchange by the DECmailer plan, a Carry-in plan and Module Exchange on a per call rate. The DECmailer was said to be the lowest cost. The handout from this session was actually a DEC publication titled "Self-Maintenance Handbook" (111 pages). This handbook would be good reading for anyone who is planing to perform their own maintenance and also as general reading for someone interested in DEC maintenance in general. HARDWARE Page 15-7 FRONT END PROCESSORS 15.4 FRONT END PROCESSORS A panel of users and Digital representatives met to discuss "Front Ending" of VAX and DECsystem-10s and 20s with PDP-11s. The impression that was given from this session is that front ending could be the solution for more CPU power and for systems requiring redundant operation. Because of the advances in DECnet software and in Ethernet hardware/software it will be easier to interconnect the mainframe and the remote front end. Also the use of PDP-11s as front ends could make use of existing software on the host system. It became evident from hearing the panel discussion, that the most important part of a front end project is deciding how to divide the CPU load. The factors that play a role in the decision are processing speed requirements, redundancy, cost, and network configuration. The object is to minimize the overhead introduced into the system because of the front end. The project should be designed such that handshaking between the Host and the front end should be the minimum necessary for reliable operation. At the Q&A session following the panel, many people showed interest in increasing VAX performance with the use of a front end. Several persons were considering a "smart" front end that could grab a file(s) from the host VAX and run an EDIT session completely in the front end, transparent to the user. 15.5 UNIBUS 15.5.1 UNIBUS Tricks o The UNIBUS arbitrator's (the board on the end of the bus) job is to receive and remove grants, issue and remove SACK and issue and remove BBSY. o True UNIBUS arbitrators treat NPR as the highest priority request. o Lots of controllers take liberty to defeat arbitration, however. o NPR Monitoring -- Controller does not let bus mastership go and monitors NPR line. As soon as it sees it, it releases the bus to the requestor and immediately requests the bus again. It does not look for bus requests, so that interrupts cannot get the bus and you get data overruns. NPR Monitoring does not give the little guy his fair share of the bus. HARDWARE Page 15-8 UNIBUS o SACK Monitoring -- This is the lesser of two evils. The arbitrator either gets a BR or NPR request and issues grant and SACK. The bus is immediately released. Controller immediately requests and the grant is overlapped by the first device request. If you have more than one of these devices, the bus will toggle between the two devices. o HOG Mode -- This is when a device issues multiple word transfers and hogs the bus until all are completed. A device should never issue more than a few words at a time. Originally SACK was held until the last cycle was in progress, arbitration occured and another device got the bus. Today, SACK is removed after NPR is granted and the bus is obtained. If another NPR device requests the bus, it is granted immediately and arbitration is overlapped. When cycle 4 is done on the first device, BBSY is removed and bus clear (BCLR) allows the second device to take the bus. If you want to give DMA devices the last chance to get the bus, you hold SACK as in the first case. The second case takes less time, however. 15.5.2 UNIBUS Hints o Devices electrically closest to the processor have the highest priority if two devices make a request at the same time. Therefore, the devices requiring the fastest service should be next to the processor. o Devices with less buffer should be on the high end of the bus. o Fully-buffered disks should be at the back but they may not run their fastest. On the other hand, if they were at the front of the bus, it could cause data lates on other devices. o DR11-W software selects burst or non-burst mode. Burst mode is 2 or infinite cycles, but infinite cycles are prohibited on the UBA. The VAX expects it will get the UNIBUS in a set time limit. If it doesn't it will bugcheck. This is probabilistic in nature -- you can run until two requests are made after each other. If no terminals are on the bus it would probably be O.K. to do infinite cycles. o If you are in burst mode and another device not in burst mode is getting data lates, it would probably help to get out of burst mode. HARDWARE Page 15-9 UNIBUS o UNIBUS reflections -- These are due to impedance mismatches on the line. If the impedance is low, the pulse heads back up the line again. High impedance causes the pulse to go back to the beginning as a wave hitting a brick wall would ripple back to you. Each device on the bus creates a little reflection. Too many devices cause tremendous reflections. If this is the case, you should sepqrate the devices into distinct back planes. Each back plane should be sepqrated by 120 ohm transmission lines. Using different length cables from box to box also helps get rid of reflection. o Never have more than 20 devices on the bus and always design for at least 50 feet of cable for deskewing. CHAPTER 16 DOD ISSUES The DOD Working Group sponsored a session entitled "Digital: Trends in the Government Market" where a DEC representative from the Government Services Group (GSG) described the software, hardware and architecture trends from the perspective of the DOD environment. The form factor for all new disks is the 10-1/2" x 19" format of the RA disks. This permits easy mounting in a standard 19 inch rack such as would be required in a "non-office" environment. 16.1 TEMPEST In the area of TEMPEST equipment Digital is looking to the use of fiber optics to satisfy DOD TEMPEST requirements for interconnects. DEC is no longer producing a TEMPEST terminal. Instead they have licensed Delta Data Systems to provide this equipment to the DOD sector. DEC will however, soon introduce a new personal computer with TEMPEST protection. 16.2 MILITARIZED EQUIPMENT In the area of militartized or ruggedized equipment, DEC is working closely with vendors to provide them with the information they need to meet these DOD requirements. Norden Systems is continuing with the PDP series of militarized computers by announcing the availabiltiy of the MIL-VAX. There are at least two companies working with DEC to produce ruggedized VAXs: Norden Systems of Norwalk, Conn. and Rugged Digital Systems. DEC is known to be hard at work on an ADA compiler, but has not formally announced its availability. It is expected that the DEC version will be a completely integrated software product permitting inter-language calls. DOD ISSUES Page 16-2 DOD-PECULIAR HARDWARE 16.3 DOD-PECULIAR HARDWARE Gary Miller of DEC/GSG spoke on DOD-peculiar hardware. Mr. Miller described the preparations underway to develop a TEMPEST/RFI technical center in Salem, New Hamphsire. This center will be used to develop and test new products that have more stringent TEMPEST/RFI requirements than standard commercial environments. DEC is already developing both synchronous and asynchronous fiber optics communications links to reduce RFI. In addition, the recently announced H9660 cabinet will improve the RFI performance of future DEC equipment. Mr. D. A. Sussman of Norden Systems described the efforts of his company to meet the requirements for militarized DEC equipment. This equipment is designed to meet the specification for airborne electrical equipment, MIL-SPEC 540-C. It is packaged in either the Air Transport Rack (ATR) format or the MIL-STD-189 format (19 inch rack). Maintenance is organized into levels commensurate with the military's breakdown of fault detection/isolation. Reliability is predicted using formal analysis as per MIL-HANDBOOK 217 and demonstrated using laboratory accelerated tests and field history. The various computers already militarized by Norden Systems include: o LSI 11M o PDP 11/34M o PDP 11/44M o PDP 11/70M o MIL-VAX (VAX 11/780) In addition, Norden has plans to produce a militarized version of: o VAX 11/730 for low performance requirements o Super VAX 11/780 for ultra-high performance requirements (yet to be announced future DEC product) o Large capacity disk 16.3.1 Instruction Set Architecture Requirements The proposed DOD instruction 5000.5X would restrict military computer acquistion to certain standard Instruction Set Architectures (ISA): o 16 Bit Architecture - Air Force - MIL-STD 1750A - Navy - ELEX-P351 (AN/UYK-20) DOD ISSUES Page 16-3 DOD-PECULIAR HARDWARE o 32 Bit Architecture - Army - MIL-STD-1862 (Nebula) - Navy - PD-PMS-408-1 (AN/UYK-7) Presently, no commercial ISAs are included but the industry is working to modify this policy. The Nebula is "VAX-like" in that it is a virtual machine. 16.3.2 Military Software Requirements DOD instruction 5000.31 specifies the use of a set of high order languages for military software: o CMS II o JOVIAL J73 o FORTRAN 78 o ADA Special purpose languages: o ATLAS o SPL 1 o COBOL APPENDIX A VAX/VMS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS Roadmap to Sessions i Questionaire ix Compiler Directives in BASIC-PLUS-2 and VAX-11 BASIC 1 Introduction to DEC BASIC 15 VAX Clusters 28 VMS Security 39 VMS Organization 46 VMS Realtime 57 New Mass Storage Architecture 86 Lock Manager 86 DEC/MMS 96 V3 Shareable Images 99 Augmenting a DBMS with Concurrent Access Capability 112 Shareable Images for Large User Libraries 118 The New Look in VAX/VMS Documentation 120 Network Security 125 Introduction to Command Procedures 131 Novice Disk and RMS Tuning VAX/VMS 138 VAX-11 RMS Intermediate Tutorial 148 Introduction to VAX/VMS System Management 154 VAX/VMS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS Page A-2 DECNET-VAX Tutorial 223 Event Driven Graphical Menu Interaction 242 VAX-11 RMS, RMS Utilities and the Languages 251 DEC/CMS: A Tutorial 260 VMS Backup 272 VMS Librarian Tutorial 277 Advanced Techniques for Using DEC/CMS on VAX 286 Introduction to VMS AST and Timer System Services 290 Using KMC's on a VAX 302 Speakasy: A Conversational Language on VAX 308 Creation and Utilization of Information Structures 315 within Mapped Sections on VAX/VMS Software Tools for VAX/VMS Device Drivers 342 Advanced Techniques using DEC/MMS V1.0 361 SOFTQUOTA: A Disk Space Management Utility 365 APPENDIX B DATATRIEVE SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS Presenting VAX-11 Datatrieve Version 2 1 Applying Datatrieve to a Non-Database Problem 9 A Tutorial on Datatrieve Advanced Features 14 Maintaining Planning and Scheduling with Datatrieve 52 VAX-11 Datatrieve Technical Tutorial 65 Presenting Datatrieve-11 Version 3 75 Record Definition Workshop 87 APPENDIX C GRAPHICS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS Computer Graphics Preparation of Navy Technical 1 Manuals VS11-3D Graphics Package 25 Event-Driven Graphical Menu Interaction 33 Using REGIS Effectively 42 Programmer's Guide to Graphics using REGIS 43 APPENDIX D RSX/IAS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS From the Editor 4 RSX/IAS Session Abstracts and Schedule 5 RSX-11/IAS SIG Roadmap and Buzzwords 22 User CLIs -- A comparison of MCR, DCL, 66 TDX, and CLL RSX System Development under VAX/VMS 89 Compatibility Mode Indirect Command Files for New RSX Users 93 A Real-time Simulation for the Chemical and 127 Power Industries Systems Programming in FORTRAN for RSX-11M 155 A Walk Through RSX-11M 186 Supporting DIGITAL and Non-DIGITAL Terminals 202 The Mathematics of RSX-11M 219 Nifty Things to Do with RSX Indirect 225 Command Files Introduction to Files-11: The On-Disk 271 Structure Using Memory as a Disk Under RSX-11M/M-PLUS 294 Writing an I/O Utility for Foreign Mag Tapes 310 under IAS Hows and Whys of ASTs in RSX 322 Optimization of Binary Trees 350 RSX/IAS SIG SPRING 1983 HANDOUTS TABLE OF CONTENTS Page D-2 Converting RSX Software to Run on 359 Professional Microcomputers Introduction to the RSX-11M Executive 391 Data Structures Page Index-1 INDEX ACL, 12-1 FMS, 9-3, 14-3 ADA, 16-1, 16-3 FORTRAN, 5-2 to 5-3, 8-2 to 8-3 APL, 8-1 Fujitsu Eagle Disk, 5-5 BACKUP, 4-1, 6-1, 7-1 GIGI, 13-1 Bar code, 15-4 GKS, 13-1 BASIC, 5-4, 6-2, 8-1 Graphical Kernel System, 13-1 BLISS, 8-1 Graphics, 13-1 C, 8-1, 10-2 H9660 Cabinet, 16-2 CDD, 9-3 HSC50, 3-2, 3-4, 3-7 CGL, 13-1 Checkpoint, 3-6 Journaling, 3-5 CI, 3-2, 15-1 CI750, 15-1 KMS11-P, 11-2 CLE, 2-1 Cluster, 3-1 LA34, 15-5 CMS, 8-3 LISP, 8-3 COBOL, 8-2, 14-2 Lock Manager, 3-5, 5-4 Core Graphics Library, 13-1 LSI-11, 6-2 DATATRIEVE, 5-3 to 5-4, 9-1, MA780, 15-2 9-3, 13-3 Maintenance DCL, 2-1, 5-4 Terminal, 15-6 DEBUGGER, 4-4, 8-3 Mass Storage, 15-2 DECGRAPH, 13-3 MIL-VAX, 16-2 DECmailer, 15-6 MMG$UNLOCK, 6-1 DECnet, 11-1, 15-7 MMS, 8-3 licensing, 11-4 MSCP, 3-2, 3-5 Phase IV, 11-1 MWAIT, 6-1 SNA, 11-1 V3.1, 11-1, 11-4 Network Security, 12-2 X.25, 11-1 Norden Systems, 16-1 to 16-2 DECSLIDE, 13-2 DELNI, 11-2 P/OS, 13-1, 14-1 to 14-3 DES, 12-5 PASCAL, 8-2, 14-2 DEUNA, 11-2, 11-5, 12-5, 15-1 PL/I, 5-2, 8-2 DIBOL, 8-2 PLOT-10, 13-1 Documentation, 7-2 PRO-300 Personal Computers, 14-1 DSM, 8-2 Bugs, 14-4 Developer's Toolkit, 14-3 EDI, 6-1 Diskette-based P/OS, 14-3 EDT, 7-2, 14-4, 15-3 Futures, 14-6 Ethernet, 11-2, 12-5, 15-1, 15-7 Hardware/Firmware, 14-4 P/OS V1.5, 14-2 FLX, 2-1 Proxy login, 12-2 Page Index-2 PSI, 11-2 YACC, 10-2 RA60 Disk, 3-3 VAX 11/730, 15-1, 16-2 RA80 Disk, 3-3 VAX 11/750, 3-4, 4-5, 15-1 RA81 Disk, 3-3, 5-5, 15-3 VAX 11/780, 3-4, 4-5, 15-2 Rainbow 100, 13-1 VAX 11/782, 3-4, 4-5, 15-2 ReGIS, 13-1 VAX Clusters, 3-1 RK07 Disk, 5-5 VAX Memory, 15-2 RM80 Disk, 5-5 VAXstation, 13-1 RMS, 14-2 Versatec, 6-1 RP07, 6-1, 15-2 VIA, 9-3 RSX, 9-3, 13-1, 14-2, 14-4 VMS Rugged Digital Systems, 16-1 V3.1, 3-4 V3.3, 3-4, 4-2 SDL, 2-2 V3.4, 3-4, 11-1, 11-4 Security, 12-1 V4.0, 2-1, 3-4, 4-4, 4-6, Access Control List, 12-1 5-6, 6-1, 7-2, 12-1, Network, 12-2 12-5 to 12-6 Proxy login, 12-2 VNX, 10-1 SYSUAF, 12-5 Volume shadowing, 3-7 Select-a-Call, 15-6 VS100, 13-1 Self-Maintenance, 15-6 VT100, 15-3 to 15-5 SI-9751 Disk, 5-5 VT102, 15-3 SPR, 7-1 VT125, 13-1 to 13-2, 15-3, 15-5 Standalone BACKUP, 6-1 VT131, 15-3 Star Coupler, 3-2 VT1xx SUBMIT, 6-1 bugs, 15-3 to 15-4 SYSDUMP.DMP, 7-1 VT240, 13-1, 15-3 VT241, 13-1, 15-3 TA78 Tape, 3-3, 4-4 TDMS, 9-3 TEMPEST, 16-1 to 16-2 Terminals, 15-3 TU78 Tape, 4-4 UDA50, 3-7, 5-5, 15-2 UNIBUS, 15-7 HOG mode, 15-8 NPR, 15-7 SACK, 15-7 UNIX, 10-1 C, 10-2 LEX, 10-2 LINT, 10-2 MAKE, 10-1 to 10-2 NROFF, 10-2 ROFF, 10-2 SCCS, 10-1 Shell, 10-1 Shell commands, 10-3