CHAPTER VAX PAGESWAPPER - August 1986 - Volume 8 Number 1 Editor's Workfile . . . . . . . . . . . . . . . VAX-3 INPUT/OUTPUT . . . . . . . . . . . . . . . . . . VAX-3 LA50 Queue Facility . . . . . . . . . . . . . . VAX-6 Dial-out Support for the DF224 Scholar Modem . VAX-16 Special Images included with VAX APL V2.1 . . VAX-19 How Secure is Your Ethernet LAN? . . . . . . . VAX-22 Installing 256k RAM Chip Memory with VMS V3.7 VAX-30 The VAXintosh Class Workstation . . . . . . . VAX-34 Dallas Symposium VAXSIG Notes Conference . . . VAX-52 VAX System SIG Committee List . . . . . . . . VAX-127 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-131 System Improvement Request Submission Form . . VAX-134 VAX Systems SIG Fall 1986 SIR Ballot . . . . . VAX-136 PAGESWAPPER - August 1986 - Volume 8 Number 1 General material for publication in the Pageswapper should be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters and the number oftext lines per page should not exceed 48 (these limits are particularly important for sample commands, etc. where simple text justification will not produce a meaningful result). Please do not submit program source, as that is better distributed on the VAX SIG tape. Please do not submit "slides" from DECUS Symposia presentations (or other meetings) as they are generally a very incomplete treatment for those readers of the Pageswapper who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on such slides to get the content across to a wider audience than is able to attend. For information about on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - August 1986 - Volume 8 Number 1 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor VAXnotes has arrived - 45 days after the announcement/order date. You will find I/Os in this issue are in the form of a Notes extract (moved toward the front of the Pageswapper in honor of the event). Also, as promised, I have excerpted the VAXSIG conference from the Notes demonstration at the DECUS US Chapter Spring 1986 Symposium in Dallas. That excerpt also gives a bit of a better flavor for the interactive nature of Notes conferences, and I hope some indication of what could be accomplished in the way of Pageswapper IOs using the Notes software. INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. For information about on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. VAX-3 PAGESWAPPER - August 1986 - Volume 8 Number 1 INPUT/OUTPUT ================================================================ Note 477.1 Using incoming modems as outgoing modems 1 of 1 NODE::PAGESWAPPER "Offline Submission" 23-JUN-1986 22:06 -< Another Incoming/Outgoing Modem Security Hazard >- ---------------------------------------------------------------- It is evident to me that IO 493 and 497 do not address the principal problem with using an incoming modem for out-going calls. A port used for an incoming modem must be defined as /MODEM so that VMS will stop the active process if the line is disconnected. Failing to stop the process is an obvious security exposure; without /MODEM, VMS can't see the loss of carrier. Unfortunately, with /MODEM VMS insists upon seeing CD and/or DSR before it will send any output and will ignore any input without CD and/or DSR. Using an autodial modem is therefore impossible unless you strap CD high on the modem. But that defeats the ability to detect a disconnect. Does anybody have a real solution to this problem? Dave Close Anadex/Printronix 1080 Avenida Acaso Camarillo, CA 93010 Telephone: 805/987-9660 ================================================================ Note 487.1 RX02 Drive Errors 1 of 1 NODE::PAGESWAPPER "Offline Submission" 22-JUN-1986 20:38 -< DYDRIVER Problems >- ---------------------------------------------------------------- We have at least three DSD440 RX02 look-alikes running on VAX-11/750's that show symptoms almost identical to Dr. Branham's RX02. We can initialize some diskettes, but not others. If we format the diskettes using the drive's "hyperdiagnostics" mode (stand-alone), then we can use them all. Robert R. Horning Mail Stop B270 Los Alamos National Laboratory Post Office Box 1663 Los Alamos, NM 87545 Telephone (505) 667-5113 VAX-4 PAGESWAPPER - August 1986 - Volume 8 Number 1 INPUT/OUTPUT May 29, 1986 ================================================================ Note 496.1 Word Processing similar to Wang 1 of 1 NODE::PAGESWAPPER "Offline Submission" 23-JUN-1986 22:14 -< Word Processing similar to WANG >- ---------------------------------------------------------------- WORDMARC Composer is very similar in user interface to WANG word processing and it runs on VAXen and many other systems, supporting many terminal and printer types. See the SolveWare Systems Ad in the Dec Pro or similar magazines. Jim Cutler Electronic Data Systems 26533 Evergreen Southfield, MI 48086-5121 Telephone: 313 262 5572 ================================================================ Note 505.0 RMS Tape Block Sizes No replies NODE::PAGESWAPPER "Offline Submission" 22-JUN-1986 20:38 ---------------------------------------------------------------- Is there any way around RMS's insistence that tape block sizes be a multiple of 4? We need to be able to write tapes with arbitary block sizes to insure compatibility with non-DEC systems. Bert Kritzer Department of Political Science University of Wisconsin Madison, WI 53706 Telephone (608) 263-2414 VAX-5 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility LA50 Queue Facility James R. Cutler Electronic Data Systems Corporation Communications Services Division 26533 Evergreen Southfield, Michigan 48086-5121 6 June 1986 Preface When I connected my LA50 directly to the VAX and set up a private print queue, I found that I could not send an escape sequence to adjust the margins. My RUNOFF output could be adjusted to print nicely, but printouts of command files that were punched for my notebook had text missing. I was delighted to discover the VAX/VMX version 4 printer form capabilities. I immediately created a queue setup file to define several useful forms and to create and start the queue. The method I used is applicable to other printers, such as laser printers. The LA50 escape sequences control horizontal and vertical pitch, dot density, bold and underlined rendition, and selection of character sets. I created individual form control text library modules for controlling each of these. Margin settings, page size, and which setup modules are used is controlled using form definitions. The resulting LA50 print queue system is private to my group, but the form definitions are available to the entire system. Forms Defined We use three types of forms, unmodified output, notebook output with left margin for punching, and special forms. The default form is twelve-pitch, six lines per inch, zero margins, ASCII as VAX-6 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility the G0 character set, and VT100 Special Graphics as the G1 character set. The form description text indicates the variations from the system default form. Form name Description --------- ----------- BIG_PRINT 48 col Letter 6 cpi 4 lpi DEFAULT System-defined default DOCUMENT 96 col Letter DOCUMENT_10 80 col Letter DOCUMENT_16 132 col Letter DRAFT 96 col Draft DRAFT_10 80 col Draft LA50_DEFAULT 96 col Draft LINE_DRAWING 80 col Bold 8 lpi LISTING 132 col Draft NOTEBOOK 96 col Draft LM 12 NOTEBOOK_10 80 col Draft LM 10 NOTEBOOK_16 132 col Draft LM 17 PRETTY_NOTEBOOK 96 col Letter LM 12 PRETTY_NOTEBOOK_10 80 col Letter LM 10 Form and Queue Definition The command procedure, TERMINAL_PRINT_QUEUE, is used at system boot time to define the forms, set the terminal port characterstics, spool the device, and init/start the queue itself. Note that the queue is NOT defined as a terminal queue. The Job Controller will figure that out. The procedure receives the name, queue name, and queue owner as parameters. The protection and ownership of the queue is set to make the queue private to the user group. The first part of the procedure is standard boilerplate for any command file, giving history and interface information. $!++ terminal_print_queue.com $! $! 25 May 1986 J. R. Cutler $! $! This procedure is called at boot time to initiate a $! private print queue. The queue manager must be $! active before this procedure is invoked. VAX-7 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility $! $! Inputs: $! print_terminal parameter 1 $! queue_name parameter 2 $! queue_owner parameter 3 $! $! Effects: $! o Several forms are defined $! o The terminal characteristics are set $! o The terminal is set spooled $! o The queue is defined and started $! $!-- $! LA50 PRINTER DEVICE and QUEUE NAME $ $ print_terminal = p1 $ queue_name = p2 $ queue_owner = p3 $ $ if print_terminal .eqs. "" then exit 274 $ if queue_name .eqs. "" then exit 274 $ if queue_owner .eqs. "" then exit 274 The form library is defined as a symbol for convenience to minimize edit required for other uses. $! DEVICE CONTROL LIBRARY $ $ form_library = "LA50_DEVCTL" The next section defines the forms. The system-defined default form, DEFAULT, uses standard stock so that print from within MAIL will proceed. The LA50 form numbers are calculated, rather than hard coded, so that forms may be added or removed at will without having to manually calculate a form number. For brevity, I have omitted several form definitions from this example. The entire queue system described was placed in the MIVAX LUG library and will be on the next DECUS Symposium tape under the MIVAXLUG tree. There are two important points to remember here. First is that the four margins, banner width and truncation or wrap width are set as part of the form definition. The second is that form setup may include any number of modules to produce the desired printer response. $! DEFAULT FORM VAX-8 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility $ $ define /form DEFAULT 0 /stock=standard - $ $! LA50 FORMS $ $ form_number = 51 ! Arbitrary start $ $ define /form LA50_DEFAULT 'form_number' - /description=" 96 col Draft" - /setup=(defaults) - /stock=standard - /notruncate - /width=96 $ form_number = form_number + 1 $ $ define /form BIG_PRINT 'form_number' - /description=" 48 col Letter 6 cpi 4 lpi" - /setup=(cpi_6,lpi_4,density_enhanced,rendition_bold_on) - /stock=standard - /truncate - /width=48 $ form_number = form_number + 1 $ $ define /form DOCUMENT 'form_number' - /description=" 96 col Letter" - /setup=(cpi_12,density_enhanced) - /stock=standard - /notruncate - /width=96 $ form_number = form_number + 1 $ define /form DRAFT 'form_number' - /description=" 96 col Draft" - /setup=(cpi_12) - /stock=standard - /notruncate - /width=96 $ form_number = form_number + 1 $ $ define /form LINE_DRAWING 'form_number' - /description=" 80 col Bold 8 lpi" - /setup=(cpi_10,lpi_8,rendition_bold_on) - /stock=standard - /width=80 $ form_number = form_number + 1 $ $ define /form NOTEBOOK 'form_number' - VAX-9 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility /description=" 96 col Draft LM 12" - /margin=left=12 - /setup=(cpi_12) - /stock=standard - /truncate - /width=96 $ form_number = form_number + 1 $ $ define /form PRETTY_NOTEBOOK 'form_number' - /description=" 96 col Letter LM 12" - /margin=left=12 - /setup=(cpi_12,density_enhanced) - /stock=standard - /truncate - /width=96 $ form_number = form_number + 1 $ Terminal parameters are set here to override any system default settings. Our site uses port-powered line drivers so we use /MODEM. $! TERMINAL SETUP $ $ set noon $ $ set terminal 'print_terminal': - /perm /speed=4800 /device=la100 - /modem /nohang /page=66 /width=132 - /nowrap /nobroad /dma - /noupper /noset_speed $ $ set device /spooled 'print_terminal' Startup of the queue includes designation of a default module to be issued at the end of the job (/separate) as well as using /schedule=nosize to make the queue First In - First Out. Protections make the queue private to the user group. $! QUEUE INITIALIZE/START $ $ initialize /queue /start 'queue_name' - /on='print_terminal': - /form=la50_default - /default=(noburst,nofeed,noflag,notrailer) - /noenable_generic - /schedule=nosize - VAX-10 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility /library='form_library' - /separate=reset=defaults - /owner='queue_owner' - /protection=(s:rwed,o:rwed,g:rwed,w) $ $ exit Activating the Queue The system startup procedure calls the terminal queue setup, specifying the terminal port, queue name, and queue owner. $! GMNET_PRINT QUEUE $ $ gmnet_print_terminal = "TXD5" $ gmnet_queue_name = "GMNET_PRINT $ gmnet_queue_owner = "[GMNET]" $ $ @dev$jrc:[la50_control]terminal_print_queue - 'gmnet_print_terminal' - 'gmnet_queue_name' - 'gmnet_queue_owner' The resulting queue is $ SHOW QUEUE /DEVICE /FULL /ALL GMNET_PRINT Remote terminal queue GMNET_PRINT, on TXD5: /BASE_PRIORITY=4 /NOENABLE_GENERIC /FORM=LA50_DEFAULT /LIBRARY=LA50_DEVCTL Lowercase /OWNER=[GMNET,*] /PROTECTION=(S:RWED,O:RWED,G:RWED,W) /SCHEDULE=(NOSIZE) /SEPARATE=(RESET=(DEFAULTS)) Form Control Library for the LA50 The form control library is created from individual text modules containing escape sequences for particular control functions. These are called for by form definitions as needed. Note that VAX-11 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility the Job Controller requires the library to be in SYS$LIBRARY and requires it to be version 1 also requires it to be version 1. The following command sequence is used to create the form library. $!++ la50_library_create.com $! $! 5 May 1986 J. R. Cutler $! $! Create a new LA50 device control library $!-- $ la50_library = "SYS$LIBRARY:LA50_DEVCTL.TLB;1" $ if f$search( la50_library ) .nes. "" then - delete 'la50_library' $ $ library /create /text /log 'la50_library' $ set protection=(o:rwed,w:re) 'la50_library' $ $ library /replace /text /log 'la50_library' *.TXT LA50 Device Control Modules I created the text modules for controlling the LA50 with EDT, since EDT makes inserting and viewing control characters easy to do. is the actual escape character - what is printed here is what EDT shows on the screen as the file is edited. . CPI_10.TXT - [0w Set horizontal pitch to 10 characters/inch. . CPI_12.TXT - [2w Set horizontal pitch to 12 characters/inch. . CPI_16.TXT - [4w Set horizontal pitch to 16.5 characters/inch. . CPI_5.TXT - [5w VAX-12 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility Set horizontal pitch to 5 characters/inch. . CPI_6.TXT - [6w Set horizontal pitch to 6 characters/inch. . CPI_8.TXT - [8w Set horizontal pitch to 8 characters/inch. . DEFAULTS.TXT - \[0m(B[2"z Select enhanced density (near letter quality) printing. This has no effect at 16.5 cpi or when using VT100 Special Graphics characters. . DENSITY_NORMAL.TXT - [0"z Select normal density printing. . LPI_12.TXT - [3z Set vertical pitch to 12 lines/inch. . LPI_2.TXT - [4z Set vertical pitch to 2 lines/inch. . LPI_3.TXT - [5z Set vertical pitch to 3 lines/inch. . LPI_4.TXT - [6z Set vertical pitch to 4 lines/inch. . LPI_6.TXT - [0z VAX-13 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility Set vertical pitch to 6 lines/inch. . LPI_8.TXT - [2z Set vertical pitch to 8 lines/inch. . RENDITION_BOLD_OFF.TXT - [22m Turn off bold printing. . RENDITION_BOLD_ON.TXT - [1m Turn on bold printing. This has no effect at 16.5 cpi. DENSITY_ENHANCED takes precedence over RENDITION_BOLD_ON. . RENDITION_RESET.TXT - [0m Reset graphic rendition. . RENDITION_UNDERLINED_OFF - [24m Turn off underlined printing. . RENDITION_UNDERLINED__ON - [4m Turn on underlined printing. Using the LA50 Queue I defined several DCL command symbols to make it more convenient to use the special forms and the LA50 queue. Only the most popular have DCL symbols. For others, the form is specified as part of the print command. $ print :== "print /notify /queue=gmnet_print" $ $ docprint :== "''Gprint' /form=document" $ draftprint :== "''Gprint' /form=draft" $ listprint :== "''Gprint' /form=listing" $ notebook :== "''Gprint' /form=notebook" $ qform :== "show queue /form" VAX-14 PAGESWAPPER - August 1986 - Volume 8 Number 1 LA50 Queue Facility $ qp*rint :== "show queue /device /full /all gmnet_print" $ qset :== "set queue gmnet_print" Conclusion The effort put into researching the LA50 control sequences and mining the VAX/VMS document set for queue, device, and text library information were well worth the effort. We can get printout exactly as we want it (within the printer capabilities) and have local control of our own printer queue. You can use these techniques for your laser printer and put your results into the DECUS Symposium tape, too. VAX-15 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dial-out Support for the DF224 Scholar Modem Dial-out Support for the DF224 Scholar Modem Bob McCormick Video Communications, Inc. 1325 Springfield Street Feeding Hills, MA 01030-2150 This document shows how you can take the DTEDF112.EXE image distributed with VAX/VMS V4.2 or MicroVMS V4.2 and modify it to support the DEC DF224 Scholar modem. The first part applies a patch to change the module name within the old image to the name of the new image. Since the DF224 expects to see the "!" character at the end of the number, we have to replace the code that checks for the " " used in the DF112 dialing in the second part. Since most of the modems I dial are either DF03's or DF112's, I have set my DF224 to work at 1200 baud. Two important things should be set inside your DF224. First, your characters should NOT echo. Second, you should have the full responses set. My switch pack settings in the DF224 are: SWITCH PACK #1 1 2 3 4 5 6 7 8 --- --- --- --- --- --- --- --- OFF ON ON ON ON ON OFF ON | | | | | | | | | | | | | | +---+------ Bell 212 mode | | | | | +-------------- Async | | | +---+------------------ Internal modem timing | | +-------------------------- Full modem response | +------------------------------ Auto answer +---------------------------------- Input character echo disabled SWITCH PACK #2 1 2 3 4 --- --- --- --- OFF ON OFF OFF | | | | | | | +------------ Interface speed select disabled | | +---------------- MI/MIC ground disabled +---+-------------------- Force DTR on disabled VAX-16 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dial-out Support for the DF224 Scholar Modem In addition, I have my DF224 plugged into TTA2: on my VAX. This is the way I initialize the line upon system startup: $ SET TERMINAL TTA2:/PERM/NOAUTO/MODEM/SYS/DIALUP/SPEED=1200 You may also want to add a line in your startup file to install the image for the DF224 dialer, and any other dialers you have on your system. The following is how I used the VMS patch utility to modify the image to work with my DF224. If you desire further insight, look in the fiche. The DTEDF112 listing can be found on 621 C02 of the V4.2 fiche. Login to the SYSTEM account, or something with equiv privs...then... $ SET DEFAULT SYS$LIBRARY ! Let's work in here $ COPY DTE_DF112.EXE DTE_DF224.EXE ! Copy (create) new file $ PATCH/ABSOLUTE DTE_DF224.EXE ! Now lets patch the image PATCH Version 4-00 15-Sep-1984 %PATCH-I-NOGBL, some or all global symbols not accessible %PATCH-I-NOLCL, image does not contain local symbols PATCH>replace 005F !! Change the ascii OLD> 00323131 OLD> exit NEW> 00343232 NEW> exit old: 0000005F: 00323131 ! Was '112' new: 0000005F: 00343232 ! Now '224' PATCH>replace 080E ! Change the ascii here, too OLD> 07323131 OLD> exit NEW> 07343232 NEW> exit old: 0000080E: 07323131 ! Was '112' new: 0000080E: 07343232 ! Now '224' PATCH>update %PATCH-I-WRTFIL, updating image file SYS$SYSROOT:[SYSLIB]DTE_DF2 24.EXE;2 PATCH>exit $! $ PATCH DTE_DF224.EXE ! Now patch the code change PATCH Version 4-00 15-Sep-1984 %PATCH-I-NOLCL, image does not contain local symbols PATCH>replace/instr 00AE VAX-17 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dial-out Support for the DF224 Scholar Modem OLD> 'CMPB #23, (R4)' ! Change check for '#' OLD> exit NEW> 'CMPB #21, (R4)' NEW> exit old: DIAL_ROUTINE+1C: CMPB #23,(R4) ! Was '#' new: DIAL_ROUTINE+1C: CMPB #21,(R4) ! Now '!' PATCH>replace/instr 00FF OLD> 'CMPB #23, (R4)' ! Change this '#' check, too OLD> exit NEW> 'CMPB #21, (R4)' NEW> exit old: DIAL_ROUTINE+6D: CMPB #23,(R4) ! Was '#' new: DIAL_ROUTINE+6D: CMPB #21,(R4) ! Now '!' PATCH>update %PATCH-I-WRTFIL, updating image file SYS$SYSROOT:[SYSLIB]DTE_DF2 24.EXE;3 PATCH>exit $! $ purge DTE_DF224.EXE ! Clean up previous versions $ install add SYS$LIBRARY:DTE_DF224.EXE ! Got to be installed $! $! $! the following DCL command will do the connection $! if your phone system is DTMF, start number with T, else P $! (for pulse) $! end the number with the (required) '!' $! replace the TTan: with the correct tty line $! which should be set to the right speed, and modem, etc $! $ set host/dte/dial=(number:"T5551212!",modem:DF224) TTan: $! $!Good luck! VAX-18 PAGESWAPPER - August 1986 - Volume 8 Number 1 Special Images included with VAX APL V2.1 Special Images included with VAX APL V2.1 Shota Aki APL Development Team Digital Equipment Corporation As part of the VAX APL V2.1 support of the APL character set for the VT200 series terminals, two special images are included as part of the installation kit. o APLSHR,EXE, a shareable image containing privileged utility routines. o PCDRIVER.EXE, an image containing device driver code that supports the handling of pseudo-terminals. Since APLSHR provides VAX APL access to privileged code, its installation requirements are different from other images residing on the V2.1 kit. APLSHR must be installed as a shareable, protected image on all of the VAX/VMS systems that will be running VAX APL and using the VT200 terminal support. The following describes the steps to be taken by a system manager to properly install APLSHR.EXE. The instructions assume that the user's current default directory is SYS$SYSTEM, o Make sure that APLSHR.EXE has been correctly copied to SYS$SHARE by the VAX APL installation procedure. Verify that the image is owned by SYSTEM, and that its file protection allows read and execute access to the world. o Define the install utility as a foreign command: $ INSTALL :== $SYS$SYSTEM:INSTALL/COMMANDMODE o Invoke the install utility, and install APLSHR.EXE with the following commands: $ INSTALL ADD SYS$SHARE:APLSHR/SHAREABLE/PROTECTED/OPEN/HEADERRES *** important *** - the /PROTECTED qualifier must be VAX-19 PAGESWAPPER - August 1986 - Volume 8 Number 1 Special Images included with VAX APL V2.1 specified for the installation to succeed. PCDRIVER.EXE does not have to be installed, but instead it must be "loaded" via the DCL command procedure SYS$LIBRARY:PCLOADER.COM which is provded by the VAX APL installation kit. This procedure loads the device driver code and makes the appropriate pseudo-terminal devices known to the system. This may be done while time-sharing is underway on the system. The following illustrates the steps for loading PCDRIVER: o Verify that PCDRIVER has not already been loaded by executing the DCL command SHOW DEVICE. $ SHOW DEVICE PC If you get the following response then the PC device is already loaded: Device Device Error Name Status Count PCA0: Unavailable 0 alloc $ SHOW DEVICE PTY If you get the following response then the PTY device is already loaded: Device Device Error Name Status Count PTY0: Unavailable 0 alloc If the system acknowledges the existence of both devices then loading PCDRIVER is not necessary. This situation may occur if your system is running the VAX DTM product which also ships PCDRIVER.EXE. If VAX DTM has already been installed then it is very likely that PCDRIVER.EXE has been "loaded" also. VAX-20 PAGESWAPPER - August 1986 - Volume 8 Number 1 Special Images included with VAX APL V2.1 o Otherwise, make sure that PCDRIVER.EXE has been correctly copied to SYS$SYSTEM by the VAX APL installation procedure. Verify that the image is owned by SYSTEM, and that its file protection allows read and execute access to the world. Execute the DCL procedure PCLOADER.COM: $ @SYS$LIBRARY:PCLOADER The above command should be inserted in your SYS$MANAGER:SYSTARTUP.COM procedure to automate the loading of PCDRIVER.EXE. o Verify that PCLOADER.COM was successful by repeating the SHOW DEVICE commands in the first step. VAX-21 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? How Secure is Your Ethernet LAN? or *"I/O Trojan Horse Away!!"* by G. Beau Williamson Rockwell International, CTSD M/S 406-280 1200 N. Alma Rd. Richardson, Texas. 75081 (214) 996-5547 Pageswapper Editor's Note This article original appeared in the March 1986 issue of the newsletter of the Rockwell International VAX Users Group. ---------------------------------------------------------------- *A Trojan Horse: * any software package installed on your system --- particularly one that uses elevated privileges --- that either intentionally or unintentionally does something other than what it was advertised to do. ---------------------------------------------------------------- Congratulations on being the proud 1)owner, 2)manager or 3)user --- select whichever is appropriate in your case --- of an Ethernet Local Area Network connected to your VAX System. If your facility is like our facility and you have a number of DEC VAX, PDP-11, Terminal Servers, SNA Gateways etc., all interconnected via Ethernet, you know just how nice Ethernet can VAX-22 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? be. Even if you are simply using Ethernet to interconnect two VAX's in a simple two-node DECNET network, you no doubt have found out how powerful DECNET, Ethernet and Local Area Networks really are. (For the remainder of this article I will refer to Ethernet and its compatible protocol mate, IEEE 802.3, as simply Local Area Networks or `LAN' for short.) However, with the added flexibility of the LAN comes the need for network security. In general, DECNET provides a reasonably good measure of network security features and, although you sometimes have to dig to get at it, a good amount of documentation is available to describe these features. The problem becomes more acute when other vendors' non-DECNET equipment is added to the same physical LAN cable plant. Finally, these issues become even more critical when protocol translator packages are installed on your VAX system in order to communicate with these other networks over the same physical LAN cable plant. In this article, I will relate some incidents that I recently encountered that caused me to be a bit more aware of possible *Trojan Horses* and their effects on system integrity and network security. Additionally, I will try to outline some common-sense guidelines that you should keep in mind in order to identify and hopefully minimize the risks involved by the addition of any software package to your system. Before we begin our discussion on *Trojan Horses* and network security, let's lay some basic ground-work on LAN's. I have taken the liberty of dividing LAN's into three categories for the purpose of our discussion. These are: o Homogeneous LAN's o Partitioned Heterogeneous LAN's o Non-Partitioned Heterogeneous LAN's Once we have defined these three categories, you should be able to determine in which category your LAN falls. You may also find that someone in your organization is already making plans to use your Ethernet cable plant for something other than DECNET. If this is the case, you should be able to identify which category you will soon be in and be better prepared to handle the problems that will soon occur. VAX-23 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? *HOMOGENEOUS LAN's* If you are lucky enough to be one of those who happen to be using your very own private Ethernet LAN cable plant for DECNET, then you fall into the category of LAN's that I refer to as "Homogeneous LAN's". That is to say, all nodes on the network transfer information between each other using the same upper layer protocol (in our case DECNET's DNA protocol). This is obviously what DEC would like to see but as I will point out shortly, this is not always the case. In fact, after observing some trends in technology, I would say that many Homogeneous LAN's will soon give way to one of two types of Heterogeneous LAN's: Partitioned or Non-Partitioned. *PARTITIONED HETEROGENEOUS LAN's* DEC is not the only vendor that has recognized the power of Local Area Networks and has jumped on the LAN bandwagon. Today we are seeing LAN technology becoming an integral part of many new data processing and engineering products at an astounding rate. Terminal servers, file servers, distributed processing and PC networking all use LAN technology as the corner-stone of their product. As a result of the numerous applications of LAN's in use today (and more on the way), it is highly probable that your facility will someday -- if not already -- have in place more than one LAN. In addition, since there's been a growing push towards networking standards, it is very likely that these LAN's are all at least compatible with IEEE 802.3 standard and can operate on the same physical cable plant. Since the IEEE 802.3 standards really only defines the physical and transport layers of the protocol, the upper layers generally differ from vendor to vendor (DEC uses DNA, HP uses --- in some cases --- a form of TCP/IP, others use XNS and so on and so on). If two or more of these vendors are operating on the same physical plant but without communicating with other vendors' equipment, we have what I refer to as a `Partitioned Heterogeneous LAN'. Until recently, our facility fell into this category. We had HP, DEC, 3Com, Daisy and a few other vendor products peacefully coexisting on the same cable but without any form of information transfer across vendor boundaries. VAX-24 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? This type of LAN seems to work quite well (at least it has in our case) if everyone sticks to a protocol standard and packet type that has been licensed by Xerox. There are some vendors, however, that have not licensed their packet type with Xerox (we have one currently on our LAN). This is not a problem as long as such vendors are kept on their own Homogeneous LAN's or no one else uses their self-assigned packet type in a Heterogeneous LAN. However, if Xerox ever does grant a license for that vendor's self-assigned packet type to another vendor, there could be some serious LAN performance problems in a Heterogeneous LAN environment. *NON-PARTITIONED HETEROGENEOUS LAN's* "Partitioned Heterogeneous LAN's" are actually only phase I of the evolutionary cycle of multi-vendor LAN's. Phase II of the evolutionary cycle begins when a software package is installed on one or more of the nodes in the "Partitioned Heterogeneous LAN", that will translate one vendor's protocol to another vendor's protocol and vice versa. These nodes then become Gateway nodes between the two networks. At this point we have what I refer to as a "Non-Partitioned Heterogeneous LAN": a LAN capable of transferring information (typically files) between nodes of different vendor types and using different protocols. "You mean like DEC's SNA Gateway?", you might ask. Well, yes and no. Remember, the SNA Gateway translates DNA protocol on the Ethernet LAN to IBM's SNA network on a completely separate communications line. These Gateways translate one protocol to another and put it back out on the same physical communications medium. Phase II has already begun as more vendors come out with software packages which run on your VAX system that translates DNA to their particular protocol (and vice versa) over the LAN. It is just such third-party software packages that bring us to our main area of concern for our network security. *FILE-TRANSFER UTILITY OR TROJAN HORSE?* Our facility has now moved into the category of a "Non-Partitioned Heterogeneous LAN" as we have installed two third-party software packages that cause the VAX to operate as a Gateway node. I didn't think much about it when the first package was brought to me by a user who wanted to do file transfers between the VAX and the HP-9000. The package was VAX-25 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? written by HP and was designed to make the VAX look like a node on HP's network. (I was a little disappointed --- being the biased person that I am --- that HP didn't do the opposite and write a package to run on their HP-9000 to look like a DECNET node.) It wasn't until another user brought me a package for a PC-LAN product to do not only file transfers, but also do virtual terminal and file server operations that I balked. I had to ask myself, "What do I know about these software packages that I am installing?" I decided to take the time to take a closer look at what I was doing. What I found was this: both of these packages required images to be installed that ran with elevated privileges and quotas and could create other such processes within our VAX system. These processes in turn, somehow connected (the documentation didn't explain exactly how) to computing resources outside of our DECNET environment. When I stopped to think about what I was doing I found that it was very simple: *I was making `hot-line' connections directly from the heart of our VAX system to the outside world with little or no knowledge of what those `hot-line' connections did.* That wasn't the half of it. Not only were these connections to the heart of our VAX system, they were also connections to just about anywhere in the our DECNET network since the VAX could be used as a gateway node to any other node in the DECNET network. *Talk about playing Russian Roulette with your network's integrity!* With DECNET, you at least have plenty of documentation as to how and when processes are created by DECNET when an incoming connection is established. (See the section on "System-Level Access Control" in the "Guide to Networking on VAX/VMS", pages 2-50 through 2-52.) This information allows to you to establish security and resource guidelines within your VAX system to either guarantee system integrity or at least understand where your problem areas might be. With these other two third-party software packages, I didn't have enough information to make any such determinations. At this point, I hollered `whoa' (using an appropriate West-Texas accent for proper emphasis) and began calling the third-party software vendors to express my concerns and to request more technical data by which I could better understand what their software did inside the VAX. VAX-26 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? *THE HP PACKAGE* The people at HP were contacted about their package and were both helpful and happy to give me additional technical data as to what processes were created, under what conditions and by whom, when a file transfer took place. What they told me was that it was necessary for all incoming (to the VAX) file transfer requests to specify a valid username and password. A process is then created under that user account and the file transfer image run in the context of that process. Now I knew that I could at least provide some measure of security for HP's file transfers to/from the VAX via normal file protection methods. However, that also meant that there was a high probability that users would write command procedures on the HP system to perform file transfers to their associated accounts on the VAX system. The result would be that usernames and their passwords would reside in files on the HP system that could possibly be compromised. (I am not aware what sort of file protection schemes HP is using or what system procedures are in place to protect individual users' data on the HP system.) Although I was not completely satisfied with the situation, at least I knew what was going on and where to look if problems arose. I installed the package on the system and have had very little trouble with it to date. *THE "OTHER" COMPANY'S PACKAGE* On the other hand, this other company (I will do them the favor of not naming them here) was not so helpful. Their customer service representative was unable to give me the sort of technical details that I needed for my security and integrity analysis. They were also reluctant to put me in touch with anyone else that could answer my questions directly. They suggested that I go ahead and install the package and "play with it" (in my copious quantities of free time, I might add) in order to find the answers I needed. My inclination at this point was to not install the package at all. Unfortunately, since I was receiving a lot of pressure from one particular user community to install the package I had to go ahead and install it against my better judgment. And so I did, but not before making sure the rest of the user groups understood what was happening and what the risks were to network security and system integrity. (This is known as the [1]"Pontius Pilate" method of system management whereby one "washes ones hands" of the matter.) VAX-27 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? Since installing this package, I have had a minimum of 3 mysterious system crashes that I haven't had time to analyze and numerous complaints from the user community as to the reliability of this package. We are now looking for an alternative to this software package. *SUMMARY -- SOME RULES TO LIVE BY* First of all, one must keep in mind that a balance between system security and system accessibility must be achieved. Where this balance point depends on your environment. If you are managing a small limited-access system with a community of cooperating, knowledgeable, trustworthy users then your need for security is not going to be as great as someone managing a large networked system that has access to information critical to National Security. Once you have come to grips with what your security requirements are, you can begin to analyze your system to determine if it meets those needs. With this in mind, I will try to give you some basic common sense rules to apply when handed a software package to install on your system. 1. If the software is *not* installed with any privileges and is *only* run within the context of a normal user's process, then it is safe to be installed. 2. If the software is installed with any privileges other than TMPMBX or NETMBX, attempt to determine why it requires those privileges and how it is going to affect your security. 3. If the software requires any "Detached" processes to be running continuously, determine their process context. Pay close attention to the process's UIC, priority and privileges. Attempt to determine each process's function and how it will effect your security based on its context and function. 4. If incoming network connections cause "Detached" processes to be created, determine the rules that govern the context under which the process is created. (For example, can an incoming connection create a ---------- [1] See also CYA methods. VAX-28 PAGESWAPPER - August 1986 - Volume 8 Number 1 How Secure is Your Ethernet LAN? process under any user's account? If so, how and under what conditions?) There really is nothing new about these rules. They are based on good ole common-sense practices and really should go without saying. However, when things are really hectic, it's awfully easy to get into the habit of just typing: $ @SYS$SYSTEM:VMSINSTAL . . . without thinking every time a new package lands on our desks to be installed. VAX-29 PAGESWAPPER - August 1986 - Volume 8 Number 1 Installing 256k RAM Chip Memory with VMS V3.7 Installing 256k RAM Chip Memory with VMS V3.7 by John Russell Hawaiian Electric Company P.O. Box 2750, Honolulu, Hi. 96840 The following is not an exhaustive study, nor should it be construed as a recommendation to other sites. It is merely an attempt to report some of the problems confronted during our recent memory upgrade. If you use any of the information provided, it is at your own risk: we have enough problems, already! Those having corrections, rebuttals, or better explanations should put their knowledge in machine-readable format (Runoff source files preferred) and submit it to the PAGESWAPPER. (God knows that Larry is always begging for input.) For various reasons, we here at HECO have not yet been able to upgrade our dual VAX-11/780 Energy Management System to VMS V4.x (my very next project). One of the main reasons, though, was that we were told by DEC that we would need more than the 3.5 __ _____ __ megabytes that we had been running with in order to perform the VMS upgrade. Looking down the road, we knew we wanted to invest in the new memory technology which had become available since we purchased our systems (we had the 16k RAM chips). We decided to go with 256k RAM chips using the MS780-HC memory controller. During the preliminary evaluation phase, we believed the software requirements listed in DEC Educational Services publication EK-780EH-IN-001 ("MS780-EC/ED and MS780-HC/HD Installation Procedure"): The following system software is required to install the MS780-EC/CD: 1. VMS Version 3.2 or higher. 2. VMB.EXE Version 3 or higher. ____ The MS780-HC/HD memory system requires VMS Version 4.0 when ____ ____ _ _____ _____ ______ ___ _______ ___ _____ more than 8 M8374 array boards (32 Mbytes) are used. [Emphasis mine - JR.] We interpreted that to mean that, if we were going to have less than 32 Mbytes, we didn't have to have VMS Version 4.0. Our mistake. More clearly stated, the guideline should be: VAX-30 PAGESWAPPER - August 1986 - Volume 8 Number 1 Installing 256k RAM Chip Memory with VMS V3.7 The MS780-HC/HD memory system requires VMS Version 4.0 or higher. We purchased the upgrade kits with 8 megabytes for each machine from an OEM who was kind enough to send a complete extra kit for spares during the upgrade. That saved us quite a bit of time, as it turned out. Our Field Service Account Representative (eat your heart out, we've got one of the good ones: Tom Lau) did the installation for us. The hardware installation went fairly well (nothing obviously wrong). Microdiagnostics completed with no errors. Looked good. We tried to boot the system: %SYSBOOT-F-Unable to allocate SPT+PHD+SCB. HALT INST EXECUTED Going to the VAX/VMS System Messages and Recovery Procedures manual, we were told to reduce sysgen parameters affecting the System Page Table count. This struck us as odd, since we hadn't modified any sysgen parameters and there should have been an extra 4.5 megabytes to play around with. We decided to doubt the accuracy of the message. Rerunning diagnostics showed everything to be bright, cheery and ready to go. Repeated failures to either boot or locate the problem drove us to call our local VMS guru at DEC (Bill White) who asked, "What version VMB.EXE do you have?" Nonplussed, I responded, "How can I tell?" Further conversation established that the critical point was how many bytes got loaded during the bootstrap procedure. Our 4400 (hex) bytes just weren't enough. We needed a 5000 (hex) byte version. Bill brought us over a VMS V4.? console floppy. When we next tried to boot, the Force was with us, and all went well. Except ... for some reason, our sysgen parameter file had been drastically changed (maximum working set size set to 98, for example) with no human intervention. We recovered our original parameters, rebooted, and had no further problems. That, basically, was the end of that for our first conversion. We've had no problem on that CPU since. The second CPU, however, put up much more of a fight when we upgraded it a week later. The first two M8375 memory controller boards failed microdiagnostics (hurrah for the spare kit!). When those boards were replaced, the new hardware passed microdiagnostics with flying colors. Armed with a new console floppy, we booted the ________ system. All appeared well. Hah! VAX-31 PAGESWAPPER - August 1986 - Volume 8 Number 1 Installing 256k RAM Chip Memory with VMS V3.7 Less than an hour after Tom had packed up his kit, the system faded into the sunset. No crash. No error. No response. Halting the CPU at the console and examining the general registers and the PSL showed us to be looping in MACHINECHECK logic at IPL 31. The worst had happened: we had an intermittent problem on hardware that passed diagnostics, and the software couldn't handle the error. A call to DEC brought Tom back. A painful period of board swapping and testing ensued, during which we tried to repeat the error reliably and isolate the bad board. Results were conflicting, probably due to our inaccurate test procedure (a DIRECTORY of a whole disk seemed, eventually, to cause the problem). We always ended up looping in the same MACHINECHECK code. While Tom worked on hardware, I started investigating the software aspects of the problem. Whipping out my microfiche reader, I read fiche and used SDA to examine both the current system and crash dumps we had generated. The basic problem was in two images: INILOA and SYSLOA780. In both places, the software uses a memory type code to search for a matching type in a hard-coded array. The resulting index is used to map into the general memory types. INILOA uses this general type to load an address into a configuration vector (one slot per nexus) starting at MMG$GL_SBICONF. If no match is found, that slot in the vector is set to zero. SYSLOA780 uses the general type to vector to an action subroutine during memory error logging. The subroutine clears the error bit on the memory controller, and goes on to use the MMG$GL_SBICONF vector loaded by INILOA. If no match is found, the subroutine is not executed, and the error bit is not cleared. This causes more errors to be reported, and, voila, a tight loop at IPL 31! The real trouble was that VMS V3.x knows about 16k arrays and _ 64k arrays, but knows nothing about 256k arrays. Since I know about the 256k arrays, I decided to patch INILOA.EXE and SYSLOA780.EXE and let VMS know about them, too. Be warned: this invalidates the Digital warranty on the software! However, the whole point of the exercise, for us, was to get enough memory to be able to upgrade to the version of VMS which wouldn't need the patch. Besides, how much support do we get on Version 3.7, anyway? Investigating the VMS V4.4 microfiche, I got the type codes for the 256k memory, and verified the fact that the vectors and action subroutines were identical for the 256k and 64k memory. VAX-32 PAGESWAPPER - August 1986 - Volume 8 Number 1 Installing 256k RAM Chip Memory with VMS V3.7 This simplified matters considerably. All that was necessary was to replace the 64k codes with the 256k codes in both images. I created the following PATCH command files, duplicated INILOA.EXE and SYSLOA780.EXE (always leave an escape route), and applied the patches. (To be honest, I discovered the INILOA.EXE problem after patching SYSLOA780.EXE and getting into an endless crash-reboot cycle because the MMG$GL_SBICONF vector was not properly initialized. Keep a backup system disk around.) SYS$SYSTEM:INILOAPAT.COM: INILOA.EXE DEPOSIT 727=73727170 ! 64k codes were 6B6A6968 DEPOSIT/BYTE 72B=74 ! 64k code was 6C UPDATE EXIT SYS$SYSTEM:SYSLOAPAT.COM: SYSLOA780.EXE SET ECO 3 ! may as well DEPOSIT 820=73727170 ! 64k codes were 6B6A6968 DEPOSIT/BYTE 824=74 ! 64k code was 6C UPDATE EXIT Addresses were found using the map files on microfiche and verified using SDA and PATCH. Rebooting with the patched images, we forced the error to occur, and IT WAS LOGGED! A correctable error in the lower 4 megabytes. We swapped the memory array card out, and ran our primitive test again. SAME ERROR! (Which shows that the error logger doesn't know everything.) Moving the memory controller caused the error to shift, too. Replacing the memory controller card cleared up the problem. (If you've been keeping count, that means that 3 out of 6 M8375 cards shipped to us were bad.) In summary, we were able to install and use the new RAM technology on two VAX-11/780s running VMS V3.7 with about 4 days of effort. We had some unexpected problems (never take the published data at face value, verify it), but learned new things about how VMS works as a result. Use of the System Dump Analyzer and system microfiche enabled us to identify and correct the software incompatibilities in a relatively short time, and keeping a backup system disk with unmodified software saved us a lot of trouble while we were testing the patches. VAX-33 PAGESWAPPER - August 1986 - Volume 8 Number 1 Installing 256k RAM Chip Memory with VMS V3.7 Now all I have to look forward to is the trivial task of upgrading to VMS V4.4. The VAXintosh Class Workstation A DEC Low-End, Human-Engineered, Workstation James. G. Downward Chairperson, VAXintosh Working Group C/O KMS Fusion, Inc. P.O. Box 1567 Ann Arbor, Mich. 48106 Disclaimer This document occasionally refers to existing hardware and software systems and may suggest certain possible ways of achieving a VAXintosh Class Workstation (VCW). Take this in the proper spirit. The VAXintosh Working Group is not asking DEC to just build another Macintosh (Amiga, Atari ST, ...), nor is it committed to specific hardware and software implementations which might be discussed here. The working group is not trying to push the VCW onto DEC as a new PC although the functionality needed for a VCW probably makes it every bit as much of a PC as the VAXmate. While there are probably very few DECUS members who wouldn't encourage DEC to try to come out with a radically innovative PC, the VCW is not viewed primarily as a PC but as a workstation necessary for us to obtain needed functionality from our VAX systems. VAX-34 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation 1. VAXintosh Working Group The VAXintosh Working Group was jointly formed by the VAX SIG and the Language and Tools SIG because it was felt that DEC was not addressing an area which would be critical for VAX users in the near future, namely a low cost, Human Engineered Workstation/Terminal, which in this paper is referred to as the VCW (VAXintosh Class Workstation). In discussing the VCW, two issues are intertwined and inseparable, namely: o Low cost, bit-mapped graphic workstation. o Human-engineered user interface. The VAXintosh Working Group has two primary factions, which could be categorized as the "Planners" and "Do-ers." The "Planners" believe that if enough solid user input can be given to DEC during planning phases, it is possible that DEC might design and build a VCW. The "Do-ers" feel that DEC is incapable of addressing the VCW marketplace soon enough (if ever) and that what users need to do is pressure DEC software engineering into accepting a Macintosh (Amiga...) as a VAX-supported terminal/workstation. Both groups have a kind of "born-again," missionary zeal about them. They are composed of experienced programmers quite used to developing standard programs. Recently, however, they have been exposed to the Macintosh computer which embodies a completely different approach (metaphor, if you will) as to how a computer should interact with a person. This has been a revelation to many. The groups members are accustomed to hearing countless complaints about computers and programs being user-unfriendly, but given the available user- interface tools, there was little which could be done to create a truly user- friendly environment. Menu systems and hand holding programs can be developed, but they are really not the answer. The Macintosh visual human interface, however, demonstrated that there was another way. Perhaps not the best way for all situations, but a far, far better way to create a friendly software system for a general, perhaps unsophisticated, computer user. VAX-35 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation The "Do-ers'" position needs a bit of clarification. Even if VMS Development assigned the Macintosh to be a known terminal type, all would be in vain unless major amounts of software were written to allow the VMS user to take advantage of the Macintosh's capabilities as a workstation, and to provide program developers with a common user interface standard for using the Macintosh workstation. Of course, there are some who feel "we can go it alone with third party software and minimal VMS support from DEC." Realistically, however, most of the group realize that this position would only work if there were a major commitment from DEC to use the Macintosh as a VAX workstation front end. DEC's workstation/windowing software would have to have a driver for it as well as VAXstations. GKS would have to support it, and who knows what else. Technically, the "Do-ers" propose something not too difficult to contemplate, particularly if DEC were to use the Macintosh or its "soon to be announced" bigger-screened brother as a DEC low-end workstation. However, realistic assessment of the possibility of this happening is "slim to none." DEC is still primarily a hardware company and develops software predominantly in support of that hardware. As a consequence, this paper will try and elucidate the position of the "Planners," those who believe that unless DEC builds the hardware, they will not not develop the software necessary for an integral VCW. However, the requirements to be discussed here are also very representative of the requirements of the "Do-ers" for a VCW. 2. VCW Marketplace as Viewed by VAXintosh Working Group Members of the Working Group are generally responsible for programming and support for a wide variety of users. They must address the productivity needs of entire staffs rather than just a few high-performance engineers. To meet these needs, the working group believes a VCW is required which is inexpensive enough to replace existing terminals used by these staffs. Neither the VAXmate, DEC's current workstations, or rumors of terminal and workstation futures suggests that DEC has any product planned to fill what the group believes is currently the most critical and potentially profitable workstation market segment for DEC in the coming decade. VAX-36 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation There will always be a market place for quasi-smart (VT220-like) terminals, basically dumb CRTs. Maybe some future terminal will have full page editing, or multi-planes of memory to allow switching between VMS sessions, or maybe VT240 class graphics at a cheaper price. However, if the group's experience is any measure of the marketplace, many users now want and need much more than just simple terminals so that computers can become true productivity tools. The group believes that a VAXintosh Class Workstation meets this need. 2.1 Cost of a VAXintosh Class Workstation Currently DEC and many other vendors are pushing the workstation concept. A workstation is only cost effective if the perceived value of the increase in user productivity is greater than the workstation cost. Even then, the cost of a workstation may not be allowable if it exceeds certain limits or if it can not be justified over a sufficiently short enough period. Most members of the Working Group have commented that they need a product in the $2-3K price range. Numerous sites say that items costing more than around $3K fall into a special procurement categories and must undergo special review. The working group feels that at the $3K price range, companies would buy low end, VAXintosh Class Workstations rather than terminals at $1-2K. However, as the price rises to $10K and above, fewer and fewer workstations would be purchased to replace terminals. Consequently, unless a VCW is priced within an acceptable price range it is unlikely to become a large demand item. 2.2 Searching for Productivity Until recently, it was only programmers who had terminals on their desks. Now, however, terminals or PCs are appearing on everyone's desk, from technicians all the way up to top management. This has radically changed the audience of users who must be supported with software, applications, and productivity aids. The goal of providing computer access is, of course, to make each user more productive. Unfortunately the productivity gains for some users are marginal or negative because the computer/user interaction is not "friendly" or "familiar" in modes they can relate to. VAX-37 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation Companies have tried to provide increased computer access in several ways. The two ways of doing this seem to be either the "PC on Every Desk" or the "Terminal on Every Desk" approach. The "PC on Every Desk" approach requires an extensive on-going user support and training to avoid maximizing long-term chaos. Except for dedicated, black-box type use (i.e. just run the PC as spread sheet machine), this approach can result in productivity gains which are often marginal or negative as the user spends more and more time trying how to figure out how to use the PC for "one more application," how to get information from one PC to another or to a host, and in supporting an ever-increasing array of totally incompatible software. Even in those areas where PCs have been significant productivity enhancers "on the whole," they have a large number of drawbacks and do not lend themselves easily for future growth. Specific serious problems include: o The PC architecture and memory management system is obsolete. This imposes restrictions on software. o The time it takes to train a person to use an "industry standard" PC and software effectively is very considerable. Managers are having to spend inordinate amounts of time to learn the systems. o The PC DOS user interface is basically "user hostile." o The manuals and documentation are horrible. Software support and bug fixes are virtually nonexistent, integration is a myth, and user frustration is rising. o Staff is needed to support PC users but the software breeds, mutates, and changes faster than trained staff can learn to help. This happens because much PC software is shallow. By the time the users are proficient at one package, they have become frustrated with its limitations and are ready to buy another. o Dictating common software to use is a policy nightmare. All users want to use their own "favorite." o Enforcing a backup policy is impossible. VAX-38 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation o Documents aren't interchangeable between different PC programs or corporate computers. For example, transferring correctly formatted documents created using many different word processors to either the VAX or stand-alone word processors can easily turn into a semi-infinite sink of time. o Graphics resolution and speed is poor to marginal. o True networking and sharing of documents is nonexistent. DEC future PC and network offerings may solve some of these problems. However, creating a good user interface within the limitations of a PC-DOS framework is an awesome if not impossible task. The IBM PC architecture is so limited, that it is hard to believe it will survive in the long run. IBM-PC/AT class PC's lack the CPU capacity for providing a good human-engineered workstation environment. The second main approach, timesharing, or a "Terminal on Every Desk" is one that DEC pioneered. Assuming that one has adequate computer power to support terminals everywhere, there are still major problems with this approach. Specifically: o The VAX/User interface is inadequate for many classes of users. Too much knowledge is required to use a VMS system for even minor tasks. Generally DCL is great for programmers but for others it represents a "user hostile" human interface. VAX/VMS does not provide a common human interface standard for programs. Programs work different ways, and expect users to do different things. o Inadequate hardware. Current terminals' graphics capability is woefully inadequate. Regis and 4014 performance of the VT240 terminal is snail-like. Graphic resolution is inadequate. Graphic pointing devices are not supported. The VT240 does not really support bit-mapped graphics. o Inadequate integration tools to create user environments. All in One is not the answer. Neither is SMG or user-created menu systems. VAX-39 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation o Inadequate offloading. Current terminals are not "smart" enough to offload compute intensive graphic operations from the host computer. Currently neither "industry compatible" PCs, nor terminals, nor workstations offer the VAX system manager a solution for improving system usability, and general staff productivity in the future. The VAXintosh Working Group believes that a VCW would offer such a solution, and offer a natural migration path to higher performance workstations for users requiring increased performance. 3. The VAXintosh Class Workstation Based on many conversations with VAX users, Macintosh users, PC users, and graphics users, the VAXintosh Working Group believes a VCW must embody the following characteristics. o Reasonable cost. The basic price should be in the $2-3K range. Options to expand functionality, local programmability, or storage, or screen size may be available at extra cost. o A common, human-engineered user interface. The VCW should be integrally meshed with the abilities of VMS to provide a common human interface for applications. This means a published set of guidelines as to how applications should look to the user and behave if they are to adhere to the standard. At this time, most of working group is leaning toward an iconic, Macintosh-like user interface or an interface combining icons and text. However, it realizes that further research may lead to developing still better human-engineered interfaces. o Hardware abilities to match the human-engineered interface. The hardware requirements include a bit-mapped graphic display, a graphic pointing device, the ability to do windowing, use multiple fonts, the ability to support WYSIWYG editors, the ability to offload certain functions from the host (graphic, editing, windowing, ?), and local programmability, customizability, or intelligence. Note, however, that running VMS on the VAXintosh Class Workstation is not a requirement. The VCW is a front-end graphics processor, user interface workstation, not necessarily VAX-40 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation a stand-alone mini-VAX. o Software support. VT240 terminal emulation, WYSIWYG editor, multiple font support, drawing program and VCW user interface library upon first customer ship. 3.1 Cost and Competition In the $3K price range, DEC has a potentially huge workstation market; but as the price increases, the market size rapidly gets much smaller. DEC should also note that other vendors are targeting this price range. The only thing protecting DEC from real disaster in its terminal marketplace and future low- to mid-range workstation market is that to do a low-end workstation correctly, integral VMS support is a requirement. For example, there is no question that the existing Macintosh, Amiga, or Atari ST, given the proper terminal emulation package, an LK201 style keyboard and workstation/host software package would make a powerful, low-cost workstation. Processor speed and communication speed for using (for example) a Mac as a workstation front end are no problem. Already 4014 terminal emulator programs on the Mac can do graphics much faster than the VT240. Several implementations of DECnet/Ethernet have been developed for the Macintosh and a DECnet/Ethernet/Appletalk connection is close at hand. Moreover, Apple has demonstrated that at terminal line speeds, they can put a Macintosh Host program on a VAX, and a smart front-end program on the Mac and get good performance with Mac-like applications running on a VAX using the Macintosh as an intelligent workstation. If Apple manages to get their act together (quits fighting over keyboards, worries less about Unix and more about VMS implementations, decides to attack the problem aggressively), such software and the new high-end Macintosh workstation (the modular Mac) could make a major impact in the low end, VAX workstation marketplace. VAX-41 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation 3.2 Common User Interface Developing a Common User Interface (human-engineered, visual) is CRITICAL for the success of a VCW. Many potential users of a VCW are intermittent users, not "power" users or programmers. The learning curve for them to become proficient DCL/VMS users is steep. Although DCL and existing application interfaces may have more power and potential for high productivity use than a Common User Interface interface, this potential will remain untapped and frustration will flourish if the user lacks either the time or patience to learn "VAX Speak". Consequently, both forms of user interface are required as they address different needs and classes of users. Two areas must be addressed in creating a VCW Common User Interface. First there is the interface itself. This interface includes the user/VCW interaction metaphor, the use of the pointing device, the use of icons, menus, and commands. The user/VCW interface must be easy to use, productive, feel "friendly" (as opposed to user-hostile), and support users of varying skill levels. Second, and just as critical, is the consistency of the way applications running on the VCW appear to the user. If there is a high degree of consistency, the experience the user gains in learning one application will transfer to subsequent applications and the system as a whole will feel "easy to learn". While DEC is unquestionably a leader in many software areas, DEC's experience with windowing systems, iconic interfaces, and human-engineered user interfaces is currently very weak. Consequently, DEC needs to study and learn from existing systems which have proven to be successful. In particular, Xerox's Star user interface, Apple's Macintosh user interface and DRI's GEM interface should be studied. VAX-42 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation 3.2.1 Macintosh User Interface The Macintosh user interface is one of its greatest strengths. With little or no training and micro-manuals, users rapidly learn to use new applications productively. There is probably no simple reason that the Macintosh user interface works but Macintosh applications always seem easy to learn, even intuitive. Maybe it is because the only possible categories of commands always are displayed on the screen. Maybe it is because the interface is very constrained. Much of its success undoubtedly rests on the large amount of effort Apple spent in defining the user interface BEFORE they committed to a final product. The thoughts and concepts that went into their work are elucidated in an Apple publication: "Macintosh User Interface Guidelines." By adhering to guidelines on how applications should look and behave and and by using the provided common user interface routines, even radically different applications generally seem to have a consistent user interface. The concept of approaching a user interface as a "metaphor" is also important. This concept is certainly not new with Apple . The "Desktop Metaphor" chosen by Apple feels good, familiar, and friendly. Possibly other metaphors would also work well. The Macintosh windowing system is also an important factor -- particularly when one considers the severe handicap imposed by its small screen size. The windows and pull down menus work smoothly and generally do not bombard the users with excessive or confusing displays of information. Unfortunately, DEC's current windowing software and user interface on the VAXstation II is clumsy and awkward by comparison. 3.2.2 STAR Interface The Xerox STAR system interface was the precursor to both Apple's LISA and Macintosh user interfaces. The system is in many ways outdated by Apple's work, but, if only for historical reasons, it deserves serious study. VAX-43 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation 3.2.3 GEM The GEM interface is relatively new. Consequently, not enough software has yet been written to compare the overall effectiveness of the GEM interface with the Macintosh user interface. On the surface, the interface seems cruder. For example, GEMwrite is clumsy compared with MACwrite. However, this may be an artifact of either immature programs or using monitors apparently having less visual resolution. 3.3 Hardware Capabilities The hardware capabilities must be constrained by removing from consideration those options which would force a $3K, low-end workstation to be significantly more costly. Specifically, o Color is not necessary. It is nice, and eventually the marketplace and technology will force DEC to create a color VCW, but for now, no color. o VMS is not necessary. The goal of a VCW is not to run VMS applications in local, stand alone mode. Nor is the goal of a VCW to be a local VMS program development engine. This does not mean that the VCW should not be programmable in some language on a host VAX or locally programmable. In fact, it must be, and some mechanism must be provided to do this. However, the VCW should adhere to the KISS principle (keep it simple...). If VMS and a VAX CPU are not the most cost-effective way of building a VCW, then use a different CPU and simpler operating system. The working group realizes DEC has a single VAX/VMS strategy. So what? DEC's VT240 and HSC products don't run VMS. If they had to run VMS, DEC never would have brought the products to market at a cost anyone could have afforded. This does not mean the VCW cannot emulate VMS or a VMS subset in some ways. Maybe the VCW operating system provides VMS emulation so that programs developed in a high level language on a VAX can be compiled and run on the VCW. o Disk storage and expandability can be limited. There is no reason for a VCW to support huge amounts of disk storage or local memory. Some disk storage is probably required for program load, but a dual density micro-floppy might be adequate. Provision should VAX-44 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation probably exist for either a second floppy or some modest amount (say 10-20 mbytes) of local hard disk storage. However, if the VCW connects to an Ethernet and can use a virtual disk on its host, the requirements for local disk storage are not going to be high. Defining detailed technical specifications for a VCW are beyond the scope of of this position paper. Technology changes rapidly, and the proper hardware implementation selected today may not be proper tomorrow. Instead, the required VCW specifications and capabilities will be described in terms of usage. o Graphic display. The VCW must have a bit-mapped graphic display which allows text and graphics to be freely intermixed on the display. Text display on the VCW is accomplished via software controlling the bit-mapped graphic display. Because of this, some care must be taken to insure that if text scrolling is accomplished by pixel replication rather than hardware, that the process is fast enough to avoid annoying visual rippling. o Display resolution. The VCW must have adequate resolution to produce sharp and clear displays suitable for a WYSIWYG editor capable of mixing text with multiple fonts and graphics. The required resolution depends on a variety of factors. For example, the Mac has a resolution of about 72 dpi. This resolution is probably only adequate because of the square pixel size used by the display. Anti-rastering techniques can also be used to minimize resolution requirements. The basic goal must be clarity of iconic, graphic, and multi-font display. The user must perceive the display to be sharp and clear. o Display screen size. The VCW needs only a moderate size display screen, however the Macintosh screen is far too small. The screen size should probably be a bit larger than the current VT240 screen which many users also feel is a too small. For most applications landscape format seems adequate. However, a significant number of users would like to be able to use WYSIWYG editors which display a full page of text in a portrait mode. If the VCW can optionally use an VAX-45 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation alternate portrait display, it would be useful. o Graphics support. The VCW must support several graphics modes, minimally Regis and 4014 emulation. Support for GKS would also be useful. Vector drawing and area fill must be much, much faster than VT240. Graphics primitives for windows, lines, and shapes (maybe display lists, etc.) must also be present. One must be able to select a graphic object with a pointer device and move it. One must be able to run a MACdraw or MACpaint type application using the VCW. DEC's new graphics coprocessor has good capabilities, particularly if its use can fit within the cost objectives of the VCW. The number of addressable points (x and y) for vector drawing should be great enough to allow 4014 emulation to work properly. o Graphics pointing device. The VCW requires a graphic pointing device, probably a mouse, trackball or touchpad. It would be desirable for the device type used to be a user option. o Form factor, footprint, and office impact. One reason a large monitor is neither needed nor desirable is that the VCW is targeted toward a group of users who may not either need to use a computer workstation 8 hours a day every day and who have no desire to be on aggressively friendly terms with a computer. The VCW footprint should be modest. It must not overwhelm a desk. If a system box is needed, be sure it can be unobtrusively placed under or behind a desk. If the VCW must be fan cooled, make it ultra-quiet. The VT240 terminals are obtrusively noisy. If the VCW has a disk drive, it also must be quiet. o PC or not PC? The basic concept of the VCW does not require that it be a PC or a stand-alone processor. However, if cost goals can be met, PC capabilities would be a definite advantage. For example, performing word processing or text editing without host intervention would be very valuable. Whether this is possible or reasonable depends primarily on software availability and cost. VAX-46 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation o Expandability. The VCW should be expandable if this can be done without compromising cost objectives. Rather than building "slots" into it, provide the VCW with a CPU bus port which can later be used for an expander box connection. At some future time, DEC may want to add voice I/O capability, a Telephone Answering System, or digitized input support, or a local CD-ROM reader. Such functions do not belong on the host VAX processor, so leave yourself hooks to expand the VCW's marketplace and usefulness. o The hardware architecture of the VCW should be "open" if this can be done without compromising cost objectives. Allowing other vendors to attach their boxes to it will enlarge the marketplace for the VCW and increase its acceptance. o Windowing. Here the VCW must tie in closely with VMS. A lot of thought needs to go into how this is done. The VCW needs to be able to connect windows to processes (subprocesses) and transparently handle I/O while the user is in another window. Given the proposed size of the display, serious thought must be given to how multiple windows are displayed, organized, clustered, switched between and used by a user. o Menus. Serious thought needs to be given to which of menu bars, pop up, pull down, etc. menus should be used and when. In any event, the VCW hardware/software should support the majority of this work without intervention from the host. o Programmability and customizability. The VCW should be able to load a program from either local storage or host which controls its behavior. Being able to offload applications or parts of applications from the host seems very desirable. o Communication port and speed. It is very unlikely that a 9.6kb terminal line could have adequate bandwidth to support a VCW utilizing the VAX host as a virtual disk or for transferring significant amounts of bit-mapped graphic information. For such uses, the VCW should have a built-in high speed I/O port (Ethernet jack perhaps). VAX-47 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation In addition to the above requirements, DEC should carefully consider the implications of tie-ins to two areas, CD-ROMs and WYSIWYG editors, which the working group believes will play major and significant rolls in the financial success of the VCW. First, there is a critical need to be able to display mixed text and graphics information from a CD-ROM at a user's workstation. CD- ROMs and optical disk technology now make it possible to retrieve and display composite documents, abstracts, and information data bases economically with a computer. CD-ROM data base display workstations will find extensive use at high tech companies, libraries (information services) and educational institutions. However, the acceptance and use of this technology will be severely limited until terminals (workstations) can display high resolution graphics and images as well as simple text. This poses much more severe constraints on VCW/host communication than can be supported by a simple terminal interface. A high bandwidth communication bus (ethernet and higher) is required or the CD-ROM must interface locally to the VCW. If the communication bandwidth problem can be solved, the ability to easily display stored documents on a VCW would amplify sales of both a VCW and CD-ROMs. Second, once a low cost VCW, a reasonably priced WYSIWYG editor and a page composition system are available which intermix text and graphics, users will never be satisfied with using a simple terminal again. In the technical marketplace, the savings in staff time if users were able to mix graphics and text, alter fonts and type sizes, and do equations properly could easily justify replacing a large fraction of existing terminals with VCWs. The impact outside of the technical marketplace might be equally large. At recent DECUS meetings, users representing small publishers, newspapers, and advertisers said the potential marketplace for a VCW in the desktop publishing arena was huge. 3.4 Software Support The software basis for the VCW poses a number of very interesting problems. The solutions to these problems apply not only to the VCW but to high-end bit-mapped graphic workstations. Problems which need to be addressed include: VAX-48 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation o What is the best way to implement an iconic or visual human interface? Should it be a separate task under VMS or a separate CLI? To what extent is a pointing device required and which is the best pointing device to use? o Within the context of a visual human interface, what metaphors and actions best match the VMS command line paradigm? The command line paradigm allows for many modifiers on a single verb, and one or more objects for the verb's action. The Macintosh user interface, on the other hand, only allows for verb and orderless object selection. Modifiers require further selection from menus or dialog boxes. Is it reasonable or required for the VCW user interface to have access to DCL's richness for command line parsing? o How should the VCW manage the windows for the user? Should windows be tiled (back to front with edges showing), or should only the current main large window show with inactive windows returned to the desk top border? If multiple small windows are displayed, should they be selectable/organizeable as a group which can be put away and recalled at will? On a VCW with a screen smaller than on DEC's larger workstations, greater care must be shown in using and displaying multiple windows. Since multiple windows, if properly done, could be a significant productivity enhancer, DEC must put considerable thought into them. o What should be the Common User Interface standard to which VCW applications are expected to adhere? This is very important because it will determine how easy it is for users to move from one application to another. It needs to be restrictive enough to encourage applications to behave similarly, but not so restrictive that radically new applications cannot be implemented. o What graphic primitives should be available for programmers? Certainly the windowing system (window shape, size, borders, etc.), scroll bars, dialog boxes, etc. are primitives. What about Quick-Draw like capabilities (boxes, circles, ellipses, lines, the ability to create display lists of of these objects or their logical intersections)? What about the ability to store segments of the screen as images for later VAX-49 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation redisplay or to display/generate bit-mapped graphic images? GKS is now the graphic standard, but GKS does not have the inherent ability to implement a Quick-Draw like system let alone manipulate bit-mapped graphics. o Printed output. Being able to support high resolution printed output of VCW graphics and multi-font text to a laser printer is necessary. This suggests that the VCW or the VAX host should support Postscript. o What about ease of programming? The Macintosh is not an easy machine to program for. Surely DEC can do better. o Application interruptability. The Macintosh allows work on the current application to be interrupted to use a "Desk Accesory". The VCW does not need this metaphor because the VCW supports multiple active windows. However, the VCW user interface must still be able to create a new window (subprocess) for a user at any time, retaining the context of the previous work (and any I/O to that window in the meantime). Besides having a VCW application support library, the VCW should have a number of software applications available at first customer ship. At minimum, a WYSIWYG editor, loadable font support, full VT240 terminal emulation, and a drawing program are needed. The VCW VT240 terminal emulation application poses some additional interesting problems. In addition to being able to respond to VAX host inquiry (SET TERM/INQUIRE), with the correct response for the currently active window, the VCW must be able to let the host know that it is a VCW acting as an emulator. The host inquiry mode must be able to tell if the VCW is in single window VT240, VT100, 4014 mode or a mode in which one of many possible windows may be emulating a terminal. This requires a more sophisticated approach than is used with DEC's current terminals. Currently, terminal inquiry status replies can get intermixed with user input. Given the simple minded way a terminal interacts with a program via the terminal driver, this problem is probably unavoidable. However, a VCW will be much more complex. So that a host program can know what is going on in the workstation, a bidirectional workstation/host communication protocol that can not be scrambled by user input may need to be developed. VAX-50 PAGESWAPPER - August 1986 - Volume 8 Number 1 The VAXintosh Class Workstation Conclusions Digital and its customers are now poised at the threshold of being able to use computers in dramatically new and different ways. To cross this threshold the metaphor by which programmers and non-programmers alike interact with a computer must be changed. Over the past twenty years or so, the mechanism by which a person interacts with a computer has changed radically; from punch cards and batch, to teletypes and timesharing; from dumb terminals with text, to smart terminals with graphics. However, during this period each computer still required that all important peripheral, the highly trained computer user. Each "peripheral user" had to be "computer friendly" and speak what ever language the computer needed, whenever the computer wanted to be spoken to. Even with the advent of personal computers, technology has not really created "personal" machines which can unobtrusively assist us in our daily activities. Rather, PCs have created a new class of low cost computer peripherals, the semi-trained computer users. Hopefully this rather grim view of the user's place in the computer/user interaction is on the verge of changing radically. Applying new metaphors to the user/computer interface, using visual (iconic) interfaces, pointing devices, and mode-less programming will help evolve workstations which are far easier and more unobtrusive to use. Proven technology now exists to do this at a cost comparable with that of terminals just several years ago. The power and sophistication of VAX systems, the dynamic expandability of DEC's network architecture, and the expertise of DEC's software engineering teams can provide the vehicle for delivering this technology to Digital's user base in the near future. VAX-51 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Dallas Symposium VAXSIG Notes Conference edited by Larry Kilgallen From the Notes conference on the demonstration cluster at the Spring 1986 US DECUS Symposium I have extracted those notes I felt were most useful to Pageswapper readers. In the process I have also removed (with possibly some misses) references to individual and company names for two reasons: 1. Participants did not consent to being quoted. 2. There was (with a few exceptions) no authentication as to who was really entering the text we read. The messages contained herein should thus be classed as "rumors", something that may point you in the right direction but may not. Topics Note 3.0 WPS-PLUS puts LQP02 into half-space mode Note 5.0 Problems with VAXTPU pattern matching Note 6.0 emacs-like key bindings for tpu Note 9.0 Decnet access to CMS libraries Note 14.0 LSE Templates for other stuff Note 16.0 How to create a log of DCL commands ?? Note 17.0 Slave Printer Type Note 19.0 MODPARAMS.DAT ADDPARAMETER Note 20.0 Pagefile Fragmentation Note 21.0 TPU and SMG Note 24.0 emacs on VAX/VMS? Note 28.0 DECalc Deletion of Grids Note 30.0 DECnet ACP file create failure Note 33.0 .EXE FILE TRANSFER WITH KERMIT Note 37.0 creating multi-volume tape sets Note 55.0 HSC load balancing problem Note 57.0 TeX and LaTex but not LN03 Note 59.0 Mount Verification Timeout Recovery VAX-52 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Note 61.0 Recovering from spurious XOFF Note 64.0 Suspected BUG in NOTES! Note 66.0 Bad pages in memory Note 71.0 BANNER PAGES AND LASER PRINTER PAGE LENGTH Note 72.0 LSE TPU source Note 73.0 DISKQUOTA problem - Disk Leakage Note 76.0 running out of PAGEDYN Note 85.0 PCA with DTM Note 92.0 set terminal/speed=38400 Note 94.0 File Ownership "Leakage" Note 97.0 Indirect dialup access Note 105.0 750 w/Adage-3000 .. Bugcheck ASTDEL Note 108.0 CPUBIAS Note 109.0 RA Dual port to UDA and KDA? Note 111.0 Boot problem in Microvax II Note 122.0 Loss of Disk Quota Problem Note 126.0 Foreign Terminals Note 127.0 EVE->WPSPLUS Note 128.0 Cluster w/non-Digital Disks Note 129.0 Help implementing common page/swap file Note 134.0 How'bout BACK/REC'D=IMMEDIATE Note 138.0 TTYDMASIZE Note 146.0 SOURCE LIBRARIES ACCESS Note 147.0 Printing thru DECNET ================================================================ ================================================================ ================================================================ Note 3.0 WPS-PLUS puts LQP02 into half-space mode 6 replies 4 lines 28-APR-1986 14:01 ---------------------------------------------------------------- We just installed WPS-PLUS on VMS systems, and are experiencing problems printing to LQP02's. After printing a WPS-PLUS document, the LQP02 goes into half-space mode, thus messing up the next print job that didn't come from WPS-PLUS. Any suggestions? VAX-53 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 3.3 WPS-PLUS puts LQP02 into half-space mode 3 of 6 6 lines 29-APR-1986 20:02 -< user RESET feature of print queue commands >- ---------------------------------------------------------------- I'm not sure why WPS-PLUS is leaving the printer in that state, but you can use the INIT/QUEUE/SEPARATE=RESET=module command to specify the name of a module from the device control library to be sent to the printer before each print job. Create a module with the proper reset escape sequence (see the LQP02 manual) and subsequent jobs will be printed correctly. ================================================================ Note 3.5 WPS-PLUS puts LQP02 into half-space mode 5 of 6 15 lines 30-APR-1986 09:56 -< ONE WAY TO GET AROUND IT >- ---------------------------------------------------------------- At the present time, the only way to really clear this problem is to recycle power on your LQP02. We are running WPS-PLUS from ALL-IN-1, and the problem you described occurs when an EDT document is sent to the LQP02 immediately after a WPS-PLUS document. I think you will find, that if a WPS-PLUS document is sent after the first, you don't have this problem. We took care of it through ALL-IN-1 by changing the script for the LQP02 so that it clears 1/2 line spacing for every document that is printed.. A real problem THAT MUST BE FIXED if DEC expects people to take WPS-PLUS seriously. ================================================================ ================================================================ ================================================================ Note 5.0 Problems with VAXTPU pattern matching 1 reply 50 lines 28-APR-1986 15:50 ---------------------------------------------------------------- I have a some problems regaurding pattern matching in VAXTPU. If I attempt to do the following, it does not work as I would expect. PROCEDURE SELCTIVE_DELETE VAX-54 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference LOCAL DIGITS, P, ANS; DIGITS := SPAN( '0123456789' ); POSITION( BEGINNING_OF( CURRENT_BUFFER )); LOOP P := SEARCH( 'A = ' & DIGITS, FORWARD, EXACT ); EXITIF P = 0; ! The following line is for highlighting only P := CREATE_RANGE( BEGINNING_OF( P ), END_OF( P ), REVERSE ) POSITION( BEGINNIN_OF( P )); UPDATE( CURRENT_WINDOW ); ANS := READ_LINE( 'Delete? [Y/N]: ', 1 ); EXITIF LAST_KEY = CTRL_Z_KEY; IF ANS = 'Y' THEN ERASE_LINE; UPDATE( CURRENT_WINDOW ); ENDIF; ENDLOOP; ENDPROCEDURE; ( I appologize for any syntax errors since I am doing this all from memory) The pattern that is matched (at least thorough VMS V4.3) is the first instance of the string 'A = ', up through the first instance of any digits after the string 'A = '. In otherwords the pattern would match the following section of text A = "THIS IS A TEST" ! FOR SHOW B = C D = 123 I would have expected a search failure in this case, but it does not happen. It is as though an implicit SCANL( anychar ) is done at each concatenation. I'd be gratefull if anyone can clear this up for me. VAX-55 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 5.1 Problems with VAXTPU pattern matching 1 of 1 12 lines 28-APR-1986 17:02 -< Yup, this is confusing >- ---------------------------------------------------------------- It looks like you're getting caught by one of the more confusing aspects of TPU patterns. When you combine pattern variables, the search is restarted from the current position, which is the string that matches the pattern TPU has process so far. You can force TPU to tie the search to the current position using the ANCHOR builtin. For example, define DIGITS to be DIGITS := ANCHOR & SPAN ('0123456789'); ================================================================ ================================================================ ================================================================ Note 6.0 emacs-like key bindings for tpu 3 replies 8 lines 28-APR-1986 17:05 ---------------------------------------------------------------- I like using emacs (on vms). I would use tpu, but I can't bind anything to the ESCape key, because it's reserved so you can use the tt driver to read escape sequences. I would like to be able to define my own keymaps nearly as EASILY as I can in emacs. This includes the escape key. p.s. I know many emacs users who would use tpu if they could get their key bindings transfered. ================================================================ Note 6.1 emacs-like key bindings for tpu 1 of 3 21 lines 29-APR-1986 10:21 -< Key Maps with TPU for VMS 4.4 >- ---------------------------------------------------------------- The version of TPU shipped with VMS 4.4 sounds like the answer to your request. VAX-56 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference As of VMS 4.4, TPU provides KEY MAPS and KEY MAP LISTS. A key map is a collection of key definitions that you can manipulate as a group. A key map list is an ordered list of key maps. You can bind a key map list to a buffer. When you are positioned to the buffer, and a key is pressed, TPU will search the key maps in the key map list bound to the buffer for a definition. The search stops after the first definition is found, so definitions in key maps in the front of the key map list override definitions in later key maps. While you still can't use the ESC, X, S, Q, C, and Y keys, this should go a long way towards allowing you to build an EMACS style interface. P.S. Put your EVE extensions into the DECUS library! ================================================================ Note 6.2 emacs-like key bindings for tpu 2 of 3 5 lines 30-APR-1986 13:43 -< can use ^X, etc., in PASSALL mode >- ---------------------------------------------------------------- X, Y, C can be used if you set your terminal in PASSALL mode. Of course, they won't perform their usual terminal driver functions if you do this. ================================================================ Note 6.3 emacs-like key bindings for tpu 3 of 3 5 lines 1-MAY-1986 11:03 ---------------------------------------------------------------- You'd be better off using PASTHRU mode instead of PASSALL mode. PASTHRU works better. It still honors S/Q, but that can be changed with HOSTSYNC and TTSYNC. VAX-57 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 9.0 Decnet access to CMS libraries 2 replies 8 lines 29-APR-1986 09:30 ---------------------------------------------------------------- DOes anybody know why CMS is restricted to non-decnet access ? SPecially in a ethernet environment with a number of micro-vaxes or vax-stations it would be *very* useful to be able to do reserves and fetches over decnet... ================================================================ Note 9.1 Decnet access to CMS libraries 1 of 2 11 lines 29-APR-1986 11:15 ---------------------------------------------------------------- The reason why CMS is restricted to non-DECnet access is because the 'data-base' used by CMS is implemented by a mapped section; because of this, there are no interlocking primitives available over DECnet. Thank you for your suggestion. You must realize that we have the same problem inside DEC, and it would behoove us to provide a solution. :) (that's a little smiling face over thar). ================================================================ ================================================================ ================================================================ Note 14.0 LSE Templates for other stuff 4 replies 5 lines 29-APR-1986 10:31 ---------------------------------------------------------------- Does anyone have a LSE Template for writing LSE Templates? Does anyone have a LSE Template for SAS or SAS/Graph? VAX-58 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 14.1 LSE Templates for other stuff 1 of 4 12 lines 29-APR-1986 13:17 -< Extracting a Language Template >- ---------------------------------------------------------------- If you would like to make a new language template, I found it very helpful to see an existing one, say Pascal ; In LSE, do the following: SET LANGUAGE PASCAL EXTRACT PLACEHOLDER * EXTRACT TOKEN * EXTRACT LANGUAGE PASCAL Then, make your new language, do a DO and then SAVE ENVIRONMENT/NEW Stephen Hicks Rockwell International, Richardson, TX ================================================================ Note 14.2 LSE Templates for other stuff 2 of 4 10 lines 30-APR-1986 11:23 -< I concur - are you listening, LSE developers? >- ---------------------------------------------------------------- Right on! Anyone who's written and LSE knows that the damn syntax is a real pain. I can't believe DEC developers don't have an LSE template for LSE! Can you please get it in the kit? Also, how about DCL and TPU? (I con't get the dang ; in TPU...) ================================================================ Note 14.3 LSE Templates for other stuff 3 of 4 7 lines 30-APR-1986 13:48 -< noted ... >- ---------------------------------------------------------------- Yes, we're listening. We didn't do this for V1 because we were too busy trying to get the code to work. It's a case of the cobbler's children not having shoes. Rest assured that LSE templates for LSE, DCL, TPU, RUNOFF, System Services, and MACRO have a prominent place on the wish list for LSE V2. VAX-59 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 14.4 LSE Templates for other stuff 4 of 4 4 lines 1-MAY-1986 17:36 -< more templates... >- ---------------------------------------------------------------- An LSE template for Macro and TPU would be great! ================================================================ ================================================================ ================================================================ Note 16.0 How to create a log of DCL commands ?? 12 replies 9 lines 29-APR-1986 10:39 ---------------------------------------------------------------- How can one create a complete log of a DCL session ? I want to document both the commands I type and the output returned for documentation purposes. It would be nice to be able to log the entire session into a file and then follow up with editting so that one can provide a 'cookbook' procedure or demonstration of a particular technique. ================================================================ Note 16.1 How to create a log of DCL commands ?? 1 of 12 6 lines 29-APR-1986 11:14 ---------------------------------------------------------------- Use the SET HOST 0/LOG command. The log file can be named, but defaults (I think) to SETHOST.LOG. The command is documented in the SET HOST section of the DCL dictionary. DECnet is not required so even a standalone system has this functionality. ================================================================ Note 16.10 How to create a log of DCL commands ?? 10 of 12 8 lines 1-MAY-1986 11:44 -< Alternative using PC emulators >- ---------------------------------------------------------------- You can also use terminal emulators running on PC's, if they are available. For example, I commonly use the "data capture" feature of SmarTerm-220 on my IBM PC to capture everything that goes on to a file on the PC's floppy disk. VAX-60 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 16.2 How to create a log of DCL commands ?? 2 of 12 10 lines 29-APR-1986 15:02 -< SET HOST/LOG 0 >- ---------------------------------------------------------------- Use SET HOST/LOG 0 At least single node DECnet (no license is required) must be up and running. You'll be left with a SETHOST.LOG file in the default directory. ================================================================ Note 16.8 How to create a log of DCL commands ?? 8 of 12 6 lines 30-APR-1986 17:23 -< @tt:/out= >- ---------------------------------------------------------------- for many simple sessions, @TT:/out=filename can accomplish the same thing - but you won't get prompted for missing command paramaters (you are executing a com file), and the prompt will be $_ ================================================================ Note 16.9 How to create a log of DCL commands ?? 9 of 12 5 lines 1-MAY-1986 10:27 -< minor bug in SET HOST/LOG >- ---------------------------------------------------------------- Note also that SET HOST nodename/LOG will not log blank lines. This is a bug in VMS V4.0 thru V4.3 that we expect to address in a future update. ================================================================ ================================================================ ================================================================ Note 17.0 Slave Printer Type 5 replies 10 lines 29-APR-1986 10:39 ---------------------------------------------------------------- I need a program perferrably in pascal that will identify the type of slave printer attached to a VT102 ie. LA100, LQP02 etc. I am able to achieve this for printers attached as terminal printers by sys$getdvi using the devices's secondary characteristics. I have had very little success trying to get this information by using the escape sequences in VT102 manual VAX-61 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference for slave printers. Also some way of determining if the slave printer is ready as opposed to existence would be appreciated. ================================================================ Note 17.2 Slave Printer Type 2 of 5 20 lines 30-APR-1986 00:38 ---------------------------------------------------------------- A quick check of the VT102 manual reveals the following: ESC [ ? 15 n - Request printer status report Responses: ESC [ ? 13 n - No printer attached (DTR not seen on the printer port since power up) ESC [ ? 11 n - Printer not ready - DTR was once on, but is now off ESC [ ? 10 n - Printer is ready (DTR is on) I believe that's all the information you can get; the VT102 will act on a Device Attributes request itself, rather than passing it on to the printer. (I may be wrong about this; you may get responses from both - the documentation doesn't say and I don't have a VT102 here to test.) ================================================================ Note 17.3 Slave Printer Type 3 of 5 12 lines 30-APR-1986 13:25 -< DCL capture of printer response? >- ---------------------------------------------------------------- re: .2 I have difficulty obtaining the response with a QIO read. Can this response from the printer be captured by a DCL command procedure? The solution to this problem would make my trip to DECUS worthwhile. VAX-62 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 17.4 Slave Printer Type 4 of 5 9 lines 30-APR-1986 13:59 -< How to capture DECID/DA response >- ---------------------------------------------------------------- It is possible to capture the output using a QIO, you need to use the IO$MNOECHO and IO$MNOFILTR options on the virtual read request. I have a routine to do this, catch me in V144 (System Mgmt in Research Lab, I'm the speaker) on Thursday if you want more details. ================================================================ Note 17.5 Slave Printer Type 5 of 5 10 lines 30-APR-1986 15:06 -< P.S. on capturing DECID/DA/etc responses >- ---------------------------------------------------------------- P.S. You also need to make use of the "alternate terminator character set" feature of QIO since the responses include escape characters which the system treats as input terminators. There may be other critical details like this that I have forgotten :-) ================================================================ ================================================================ ================================================================ Note 19.0 MODPARAMS.DAT ADD_PARAMETER 4 replies 7 lines 29-APR-1986 10:42 ---------------------------------------------------------------- I would like to know if when modifying MODPARAMS.DAT using the ADDparameter format if the ADDparameter is accumulative i.e. if I enter ADDpagedyn=100 followed by ADDpagedyn=100 will the pagedyn parameter be increased by 100 or by 200 over the current sysgen parameter? VAX-63 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 19.1 MODPARAMS.DAT ADD_PARAMETER 1 of 4 8 lines 29-APR-1986 11:50 -< ADD_params >- ---------------------------------------------------------------- ADDparameters are not cumulative in a single invocation of autogen but MAY be cumulative if you run autogen with the SAVPARAMS argument The reason for this is that autogen 'executes' the lines in MODPARAMS to create local symbols, therefor it follows that the second definition of an ADDparam will simply replace the first. SAVPARAMS save the old parameters in a similar fashion. ================================================================ Note 19.2 MODPARAMS.DAT ADD_PARAMETER 2 of 4 17 lines 29-APR-1986 12:00 -< ADD_foo not cumulative >- ---------------------------------------------------------------- The simple answer is no, they are not cumulative, so you have to keep track of how much you want to add to whatever parameter. I use comments on the line or in blocks to to keep track of what I've included in that ADD parameter (so I know I've kept track of all the products that need GBLPAGES for instance). I had this same question. By examining AUTOGEN.COM I found that the various lines in MODPARAMS are the defined as symbols (after first defining the ones from SETPARAMS.DAT), then each parameter is looked at first for value (FOO=3) (with MODPARAMS overiding SETPARAMS), then the ADDFOO is added in. Frequently in the middle of all this is a procedure to make this parameter (or related parameters) fit some sort of rule (like it is supposed to be a power of 2). VAX-64 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 19.3 MODPARAMS.DAT ADD_PARAMETER 3 of 4 11 lines 29-APR-1986 14:00 -< ADD SEVERAL SYMBOLS TOGETHER. >- ---------------------------------------------------------------- I don't know if this will work; I'm going to try it when I get back to my site. Since autogen creates symbols for the parameters, why not just do the following: ADDxxxFORyyy = 25 ADDxxxFORzzz = 50 ADDxxx = ADDxxxFORyyy + ADDxxxFORzzz I don't know if something like this will work - it is just a thought. ================================================================ Note 19.4 MODPARAMS.DAT ADD_PARAMETER 4 of 4 6 lines 1-MAY-1986 16:54 -< add symbols works >- ---------------------------------------------------------------- The suggestion in 19.3 WILL work! As long as all symbols used in the equation are defined PREVIOUSLY in MODPARAMS.DAT! ================================================================ ================================================================ ================================================================ Note 20.0 Pagefile Fragmentation 10 replies 18 lines 29-APR-1986 10:50 ---------------------------------------------------------------- We have just got a MICRO VAX II up and running with 5 MB and 3 RD53's. The system initially came up with two page files in sys$system: both of which were relatively small. After placing all the software required on the system disk we were left with less than 10k blocks. Therefore a third page file of about 10k blocks was created on the third disk using sysgen (contigious was not selected) it was install in systartup. VAX-65 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference On two occasions at least the system console has received messages about the page file being severly fragmented and saying the system was continuing. The status of the page file at the time is unknown how ever the problem looks like it will repeat itself. Any suggestions re how to diagnose and solve this problem would be appreciated. This never occured to me on our 780's but then we had lots of space on the RA81's. ================================================================ Note 20.1 Pagefile Fragmentation 1 of 10 16 lines 29-APR-1986 11:21 ---------------------------------------------------------------- Congratulations, You've been bitten by the VMS bug. The page file must be mappable in a limited number of file pointers (A single file header I think). When the file is non-contiguous, multiple pointers are necessarily required. The creation or extension of a page file must abide by the rules, or be cast out by the All Knowning Lords within VMS. The problem gets really serious when the default page file is extended (via AUTOGEN) and the system is rebooted. If the page file (as a result of the extension) becomes too fragmented, VMS will no longer boot at all (this happened at our site). VMS V4.3 supposedly has a fix which will prevent AUTOGEN from creating an invalid page file, but I have not tested this at this time. Unfortunately, there is no way to fix the problem, other than to use contiguous page files in the first place. As you stated, this has not been a problem with RA80/81 disks, but is generally a severe problem with RD52/53 disks. ================================================================ Note 20.2 Pagefile Fragmentation 2 of 10 9 lines 29-APR-1986 12:06 -< Build a page file on another disk >- ---------------------------------------------------------------- The message about pagefile fragmentation seems to refer to internal fragmentation of the file when it gets mostly full. It is an indication that you need more paging file. There are instructions in the doc set for creating a secondary page file on another disk. VAX-66 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 20.3 Pagefile Fragmentation 3 of 10 8 lines 29-APR-1986 13:08 -< Fragmentation ==> bad performance >- ---------------------------------------------------------------- In additon, you should note that fragmented page- and swapfiles (i.e., many retrieval pointers) mean that paging and swapping IO will take longer, resulting in longer reponse times. Making your page/swapfiles large enough and contiguous enough is usually worth the effort. ================================================================ Note 20.4 Pagefile Fragmentation 4 of 10 8 lines 29-APR-1986 13:56 -< Primary pagefile full. >- ---------------------------------------------------------------- We had a similar message come out on the operator's console that our page file was fragmented. We finally tracked this down to the primary pagefile being full, but had plenty of space in the secondary pagefile. There was (is?) a bug in VMS when you create a global section and have backing store as the pagefile - VMS only uses the primary pagefile for the backing store - and never uses secondary pagefiles. Hence, we just increased the size of our primary pagefile and solved the problem. ================================================================ Note 20.5 Pagefile Fragmentation 5 of 10 11 lines 29-APR-1986 14:55 -< pagefile problem >- ---------------------------------------------------------------- I think your problem is due to filling up the file, not so much as its fragmentation on the disk drive. BUT if you want, If possible, remove the page file. Backup/image your system to tape. Re-install from tape, the backup/image. NOW your space left should be contigeous. Try to run sysgen and re-create your pagefile useing contigeous. If at all possible, always run on a system disk thats been thru a image compress. (I know its a waste of a saturday, but bring a six pack). VAX-67 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 20.6 Pagefile Fragmentation 6 of 10 9 lines 30-APR-1986 00:49 ---------------------------------------------------------------- BTW, it appears from .0 that you have two page files left in SYS$SYSTEM. There is never any good reason to have two page files on the same disk. It is especially a bad idea to have the primary pagefile - the only one that can be used for certain things, like backing store for global pagefile sections - on the same disk with a secondary pagefile. Combine the two pagefiles into one pagefile with the same total size. (Note: Be careful to do this in a way that does NOT involve deleting a pagefile while it's in use, or you are likely to clobber your disk!) ================================================================ Note 20.9 Pagefile Fragmentation 9 of 10 18 lines 1-MAY-1986 10:58 -< dissertation >- ---------------------------------------------------------------- You can demonstrate the problem by generating a BATCH job into a queue which can handle a BIG number of concurrent jobs. Be sure the batch job re-submits a copy of itself. The net effect is to generate a GROWING number of processes, all of which require space in the PAGEFILE. You will see the 60% message, the 90% message, and finally, NO MORE MESSAGES. The bottom line is that you must have sufficient PAGEFILE/SWAPFILE/DUMPFILE for your MEMORY, WORKLOAD, CONCURRENT USERS, WORKING SET SIZES, etc. You should do a SHOW MEMORY occasionally durring peak times, and observe the utilization of the PAGEFILE. If it exceeds 60%, there is a performance penalty. You can improve performance by... BUY MORE MEMORY and increase WS (this reduces pageing load) or by INCREASE/ADD SECONDARY pageing files. VAX-68 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 21.0 TPU and SMG 9 replies 3 lines 29-APR-1986 10:51 ---------------------------------------------------------------- Will TPU and SMG ever be combined? I would really like my windows to be less then the line width of my terminal. I would also like to have terminal independance. ================================================================ Note 21.1 TPU and SMG 1 of 9 3 lines 29-APR-1986 11:23 ---------------------------------------------------------------- The statement from TPU development continues to be that, were they to provide this, it would only be sold separately -- i.e., NOT bundled with VMS (odd, I'll admit, since both SMG and TPU are bundled). ================================================================ Note 21.3 TPU and SMG 3 of 9 8 lines 29-APR-1986 12:01 ---------------------------------------------------------------- Right now, TPU has no plans for SMG support. As stated in 21.1, it could be done - if there was sufficient demand for it as optional (non-bundled sw). What we keep hearing is that people *want* it, but are not interested in purchasing it. ================================================================ Note 21.4 TPU and SMG 4 of 9 4 lines 30-APR-1986 10:13 -< I would buy it. >- ---------------------------------------------------------------- NOT INTERESTED in purchacing a product is relative! If it is cheap many would be sold ... I guess the thing is a business decision. I would by it, if it had nicer windows, and could support a 6x line terminal. VAX-69 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 21.5 TPU and SMG 5 of 9 7 lines 30-APR-1986 10:40 -< I *could* buy it, but won't. >- ---------------------------------------------------------------- I'm much more interested in maintaining a common set of tools across the operating system. Sure, I'd love to have TPU with vertical split window capability, but I'm not going to pay for it even though I could quite easily because then I wouldn't be able to sell or trade anything based on that capacity. I believe that the unbundling of tools makes it necessary to reinvent the wheel everytime that you want to do something for public access. ================================================================ Note 21.6 TPU and SMG 6 of 9 8 lines 30-APR-1986 12:56 -< SMG-TPU connection belongs bundled >- ---------------------------------------------------------------- PLEASE lets keep something so basic as part of the standard VMS system. The way to do this is for you, the DECUS member, to vote for it on the VAX Systems SIG System Improvement Request ballot. ================================================================ Note 21.7 TPU and SMG 7 of 9 11 lines 30-APR-1986 15:59 -< Why unbundle it? (!) >- ---------------------------------------------------------------- What I don't understand is why it would have to be unbundled. Is there some sort of political war inside DEC between the TPU people and the SMG folks? I don't understand why I should *have* to pay for it. If DEC is going to provide a 'uniform' interface (i.e., SMG), it seems to me to behoove DEC to use it themselves. I can see this not being possible while both TPU and SMG were in development for 4.0, but why this resistance to modifying the situation? VAX-70 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 21.8 TPU and SMG 8 of 9 18 lines 30-APR-1986 16:13 -< Unbundling leaves me in the cold >- ---------------------------------------------------------------- We didn't have to purchase TPU (it probably snuck in under just under the unbundling wire)!!! Why should we purchase enhancements to it? I understand (and even agree to some extent) with DEC's policy of unbundling major functionality from VMS. But, this would simply bring the current product up to DEC's own screen management standards (even DEBUG is going in this direction). Does this new direction imply that we will have to pay separately for things like making RMS more efficient? ================================================================ Note 23.3 PRINT?SETUP 3 of 5 32 lines 29-APR-1986 14:03 -< PRINT/SETUP Problems/solutions >- ---------------------------------------------------------------- PRINT/SETUP= has three problems you should be aware of, two of which can be fixed by using PRINT/FORM= 1) If the setup library entry requested does not exist, you don't get any indication until the file prints. It will then give you a flag/burst page followed by a one line page saying the library entry was not found. Really convenient to learn this if your printer is busy or a long walk from your desk. Fix: define forms (using /STOCK=DEFAULT) that specify the setup library entry. The FORM=xxxx is validated immediately and the job won't be queued if there is an error. 2) If you use /SETUP= to change the number of lines or characters per page, you may find that the print symbiont still thinks the page geometry is the same as before. Fix: define forms with the appropriate page geometry. VAX-71 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference 3) If the library entry for a setup entry contains what VMS thinks are printable characters, it will print a page eject. This is a problem with many printers that don't use DEC standard escape codes to control the printer. Result is a bunch of wasted paper (as many as two pages per job if a /RESET string is also set on the queue). Fix: beat on DEC to fix this silly behavior. The user should be able to tell the print symbiont whether or not a /SETUP string is printable or not. ================================================================ Note 23.4 PRINT?SETUP 4 of 5 7 lines 29-APR-1986 15:00 -< Looong setup modules >- ---------------------------------------------------------------- Another limitation of having the modules in a test library is that there seems to be some kind of (undocumented?) limitation on how many bytes of control information can come out of the library and get to the printer without something (librarian? symbiont? ??) inserting carriage returns. (ie. It didn't work to download a character set to a printer {about 5000 bytes}) ================================================================ Note 23.5 PRINT?SETUP 5 of 5 15 lines 29-APR-1986 20:10 -< Use imbedded carriage control and /nowrap/notrunc >- ---------------------------------------------------------------- The symbiont processes modules from the library [almost] exactly like any other data obtained from the print file. Some users take advantage of this to do custom (but static) flag pages. Its difficult for the symbiont to define special processing rules for these modules, though that does lead to some incoveniences. One thing to be aware of, modules stored in the library with the DCL LIB command retain the carriage control type of the source text file --- in some cases you can get rid of extraneous carriage control by creating the source module as "imbedded" carriage control. VAX-72 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference However, the symbiont will still supply carriage returns or truncate the line unless you are using a form that specifies /NOWRAP /NOTRUNCATE. ================================================================ ================================================================ ================================================================ Note 24.0 emacs on VAX/VMS? 8 replies 10 lines 29-APR-1986 11:26 ---------------------------------------------------------------- I have seen emacs mentioned in these notes. I come from a UNIX (TM) environment and use emacs there. I am now in this VAX/VMS environment and would like to have it available. Is a version available from anyplace that runs on VAX/VMS? ================================================================ Note 24.1 emacs on VAX/VMS? 1 of 8 11 lines 29-APR-1986 11:46 -< You're in luck >- ---------------------------------------------------------------- Yes there are several versions of EMACS available for VMS. CCA makes a good implementation that runs on several machines. The sources to GNUEmacs was distributed on the Spring VAXSIG tape in hopes that someone would port it to VMS. Last but not least DEC has a very good version of Emacs that they use internally, I think it's being maintained by Barry Scott, but as far as I know there are no plans to release it as a layered product. Howver that's what they said about NOTES a couple of years ago too! Good Luck ================================================================ Note 24.3 emacs on VAX/VMS? 3 of 8 12 lines 29-APR-1986 16:00 -< gnu emacs port by sasaki >- ---------------------------------------------------------------- I brought this up in the Languages and Tools roadmap, specifically asking if the gnu emacs port that marty sasaki of harvard was working on has been completed. kevin carosso of hughes aircraft said it has and is available from somewhere via the anonymous login convention and ftp (if you have access to the arpanet of course...). other distribution status: unknown. we had hoped for a BOF on this too but as of now (tuesday 1600 odd) i haven't seen it advertised. check daily.update tomorrow VAX-73 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference am to see if a BOF will be held on the vms-emacs question. ================================================================ Note 24.4 emacs on VAX/VMS? 4 of 8 11 lines 30-APR-1986 13:57 ---------------------------------------------------------------- Barry Scott's EMACS is based on the Gosling version for Unix. Gosling sold exclusive rights to it to a third party (CCA, I think). DEC has this available under a site license, and Barry has done some mods to the code. Unfortunately, there are sticky copyright and legal problems with DEC distributing or marketing this version of EMACS. Your best bet is probably GNU EMACS. Marty Sasaki is reportedly very close to distributing this for VMS (if it isn't available already). ================================================================ Note 24.5 emacs on VAX/VMS? 5 of 8 10 lines 30-APR-1986 16:06 -< Gosling's Emacs vs. CCA >- ---------------------------------------------------------------- James Gosling sold his Emacs to Unipress, not CCA. One of the 'xxx Professional' magazines featured a comparison review of CCA vs. Unipress a few months ago; the article(s) was/were quite good. I have a copy of Gosling's Emacs (as hacked by Dave Kashtan) by and with permission from James to re-distribute it to interested parties. The only caveat is: it's written for Eunice, and some heavy hackery would be needed to get it functional (or at least rebuildable) under VMS. The executable works fine, tho... k ================================================================ Note 24.6 emacs on VAX/VMS? 6 of 8 4 lines 1-MAY-1986 11:35 ---------------------------------------------------------------- RE: .5 VAX-74 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Is that to say the executable will run under VMS? ================================================================ Note 24.7 emacs on VAX/VMS? 7 of 8 8 lines 1-MAY-1986 17:23 -< Look on VAX86A,B >- ---------------------------------------------------------------- I got a copy of VMS GNE Emacs from Paul Ferrill and have brought it for the Spring '86 VAX tape. If no later version surfaces before release date, at least a working version will be available. I intend to call Harvard to see if its developer has a later release to try and get the latest one for the tape. But no promises...these things sometimes fall thru.. Glenn Everhart ================================================================ Note 24.8 emacs on VAX/VMS? 8 of 8 7 lines 1-MAY-1986 17:43 -< GNU Emacs from BITNET >- ---------------------------------------------------------------- I got a copy of VMS GNU Emacs from Harvard via BITNET. If anyone out there wants it and has JNET 2.x, let me know and I'll dig up the address to send a request to (I got it from USENET). ================================================================ ================================================================ ================================================================ Note 28.0 DECalc Deletion of Grids 1 reply 4 lines 29-APR-1986 11:59 ---------------------------------------------------------------- Does any one know the reason that DECalc allows you to delete a grid that was created with a password without using the password to delete it? ================================================================ Note 28.1 DECalc Deletion of Grids 1 of 1 9 lines 30-APR-1986 14:44 -< No Password Necessary >- ---------------------------------------------------------------- When you create a grid in DECalc, your UIC is associated with it. The password that you add is for viewing purposes only. When the DELETE command is invoked, a check is done on your UIC. If it matches the stored one, the deletion is allowed. Therefore the password is not required. VAX-75 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 30.0 DECnet ACP file create failure 6 replies 9 lines 29-APR-1986 12:33 ---------------------------------------------------------------- Does anyone know if running different versions of VMS, specifically 4.1 and 4.3 can cause the error: ACP file create failed. Network partner exited. when copying files between the two DECnetted systems? This seems to occur most often when either or both of the systems are relatively busy. ================================================================ Note 30.3 DECnet ACP file create failure 3 of 6 18 lines 29-APR-1986 14:55 -< << TYPE NODE::NETSERVER.LOG >> >- ---------------------------------------------------------------- Look at the NETSERVER.LOG on the remote node. (the node you're trying to get at.) Around my site the most common error... Check for NETWORK-mode errors in the LOGIN.COM or the SYS$SYLOGIN procedures. If for any reason the login procedures fail with an untrapped or unhandled error the network access will fail with the "NETWORK PARTNER EXITED" message. The SYS$SYLOGIN procedure is executed by everybody -- the LOGIN.COM procedure executes if it exists in the default directory for the login on the remote node. (Type DIRECTORY NODE:: to see where the default is -- typically it's SYS$SYSDEVICE:[DECNET] -- unless you've set up proxy access) VAX-76 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 30.4 DECnet ACP file create failure 4 of 6 14 lines 29-APR-1986 16:07 -< one possible solution to partner 'excited' >- ---------------------------------------------------------------- We have been having this for years until recently when it became intoleravble and we thought we better do something about it. the problem at OUR site was the 750s reporting the messages were just too swamped to give decent response to the incoming link...and after awhile the default timer value at the intiating node (think default is 30 seconds) would give up and report 'network partner exitted'. Just because the 750s didn't have the horsepower to do all we wanted them to do. So we told the bigger machines that they should wait longer. I believe the command was something like NCP> SET OUTGOING TIMER 45 or something similar. it helps. ================================================================ Note 30.5 DECnet ACP file create failure 5 of 6 25 lines 29-APR-1986 22:49 -< Increasing EXEC INCOMING/OUTGOING TIMERs can help >- ---------------------------------------------------------------- Reply .4 has got it right. Some more general information which might be helpful: frequently, the "network partner exited" message will be seen when attempting to start up a link to a busy node; if the link fails to get completely started (i.e. acknowledged at the NSP protocol level) within the originating node's EXECUTOR OUTGOING TIMER or the target node's EXECUTOR INCOMING TIMER, this error will be seen. One reason this might occur is if a new NETSERVER process must be created to accommodate the new link, and target system loading is sufficient to make this a lengthy process. If the failure was induced at the target node, looking in that node's accounting log will frequently give you the reason. Increasing both the timers cited to values like 60 or 90 seconds will reduce the incidence of "network partner exited" problems caused by system load. One possible down-side of doing this is the fact that this increases the duration of a real timeout being reported (for example, a truly unreachable node which is being addressed on an all-endnode Ethernet). VAX-77 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Hope this helps. ================================================================ ================================================================ ================================================================ Note 33.0 .EXE FILE TRANSFER WITH KERMIT 3 replies 4 lines 29-APR-1986 13:01 ---------------------------------------------------------------- I'M HAVING TROUBLE SENDING A .EXE FILE VAX TO VAX VIA TELENET. I HAVE SET PARITY MARK ON BOTH ENDS AND SET FILE TYPE FIXED. AFTER A PERIOD OF TIME, AN ERROR OCCURS - FILE TOO BIG. ANY HELP WOULD BE APPRECIATED. ================================================================ Note 33.1 .EXE FILE TRANSFER WITH KERMIT 1 of 3 8 lines 30-APR-1986 09:49 -< Maybe this will help... >- ---------------------------------------------------------------- I've experienced the same problem, but it seems to be less of a problem when you use the KERMIT> SET FILE TYPE BINARY, although I don't remember whether you do this on the sending or receiving end (I think the latter...) Good luck. ================================================================ Note 33.2 .EXE FILE TRANSFER WITH KERMIT 2 of 3 4 lines 1-MAY-1986 17:03 -< Use FIXED, not BINARY >- ---------------------------------------------------------------- I believe you should use SET FILE TYPE FIXED instead of BINARY. We have transferred EXE files successfully this way. ================================================================ Note 33.3 .EXE FILE TRANSFER WITH KERMIT 3 of 3 3 lines 2-MAY-1986 10:53 -< kermit 3.2 >- ---------------------------------------------------------------- I believe a SET FILE FIXED will also fix the problem if running 3.2 of kermit. VAX-78 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 37.0 creating multi-volume tape sets 2 replies 23 lines 29-APR-1986 13:37 ---------------------------------------------------------------- I wonder how to create multi-volume files-11 tapesets given the following contraints: 1) All scratch tapes are degaussed 2) I have 1 tape drive. 3) It is not possible to determine ahead of time how many tapes will be required. 4) Pre-initializing tapes is not a viable alternative. According to documentation REPLY/BLANKTAPE should do the trick BUT it doesn't (it appears that it is the requestor, not the respondor who needs VOLPRO and OPER and I don't want to give users VOLPRO or OPER). It also appears that REPLY/INITIALIZE and REPLY/TO both require that the tape be pre-initialize with some valid label. It should be noted that BACKUP handles this situation just fine whether or not the user is privilged. Thank you for any light you might be able to shed on this subject ================================================================ Note 37.1 creating multi-volume tape sets 1 of 2 7 lines 30-APR-1986 10:04 -< A STEP BACKWARDS >- ---------------------------------------------------------------- You are correct. We had a similar problem and finaly got TSC to admit it. In a previous version of VMS BACKUP had the same problem, but with Version 4.3 the "feature" was moved to COPY. Our operators init all tapes prior to use anyway. TSC gave the stock answer "Will be fixed in future release". Sorry, but that was the only workaround we received --- INIT prior to use VAX-79 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 37.2 creating multi-volume tape sets 2 of 2 10 lines 30-APR-1986 10:26 -< More info >- ---------------------------------------------------------------- This is in 4.0, 4.1, and 4.2, I am not yet on 4.3. I have not had the problem with backup since 2.n when backup came out. (note that concurrent with 4.0 was when we started degaussing the tapes primarily because we had several instances (greater than 75% of the time) that a user could not INIT a tape because the tape had an expiration date written on it that was approx 1 year into the future. We also got bit security wise on a tape which contained sensitive data, had been re-INITed but not degaussed and then the sensitive data was read (actually a VERY simple thing to do.) ================================================================ ================================================================ ================================================================ Note 55.0 HSC load balancing problem 4 replies 13 lines 29-APR-1986 16:31 ---------------------------------------------------------------- I have 2 HSC50s with 17 RA81s between them , each disk cabled to both HSCs. Normally I keep half the disks mounted from each HSC for load balancing. If 1 HSC fails, half the disks failover to the other HSC. On a power failure, whichever HSC comes up first mounts all the disks, and I'm not load-balanced unless I do it manually via drive buttons. Is there (or will there be a way) to ensure that my disks are mounted balanced on both HSCs after a power failure? ================================================================ Note 55.1 HSC load balancing problem 1 of 4 6 lines 29-APR-1986 16:41 -< Preferred Path >- ---------------------------------------------------------------- An extension of the MOUNT command that would implement a concept that I call "a preferred path" has been considered for VMS. However, no promises can be made regarding when such a feature would appear. VAX-80 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 55.2 HSC load balancing problem 2 of 4 9 lines 30-APR-1986 10:22 -< VAX/HSC after failure >- ---------------------------------------------------------------- Watch out - we have a similar environment in which we separated the drives between two HSC's by odd/even numbering. We lost a node of the VAX Cluster for a period of time (hard crash), and then later lost an HSC. When were able to finally get the VAX back up, it refused to boot properly until it could re-establish the original paths through both HSC's. It seems the machine remembers where it was last attachted through and throws a coniption-fit (sp) if it can't get there. Colorado spring is unable to determine if this was intended to happen in VMS. Maybe 4.4 fixed? ================================================================ Note 55.3 HSC load balancing problem 3 of 4 8 lines 1-MAY-1986 11:34 ---------------------------------------------------------------- Same experiance - Seems to be necessary (occasionally) to reboot EVERYTHING (6 VAX, 2 HSC) if severe system bouncing has occured. This seems to be cleanest way to insure all will come up clean ================================================================ Note 55.4 HSC load balancing problem 4 of 4 6 lines 1-MAY-1986 14:28 -< Preferred Path >- ---------------------------------------------------------------- I would like to express my support to the preferred path extension to the MOUNT command. Please do it soon!!!! VAX-81 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 57.0 TeX and LaTex but not LN03 6 replies 11 lines 29-APR-1986 16:45 ---------------------------------------------------------------- Question regarding TeX and LaTex Does anyone know of device support for TeX other than the LN03? We have LN03's but would like to give smaller departments draft-type output devices. ================================================================ Note 57.1 TeX and LaTex but not LN03 1 of 6 10 lines 29-APR-1986 17:13 -< PC TeX >- ---------------------------------------------------------------- There is also a (gasp) PC TeX for the IBM PC. It is NOT public domain, though, and must be purchased from Addison-Wesley publishing (I have address & price if you call) You can use other printers but I can't think of ony DEC supported printers that cost less than the LN03 ================================================================ Note 57.2 TeX and LaTex but not LN03 2 of 6 7 lines 30-APR-1986 10:13 -< IMAGEN >- ---------------------------------------------------------------- There is also support for TeX from Kellerman & Smith in Portland(?), Oregon on any of the IMAGEN laser printers, they supply TeX and Necessary Symbionts for VMS, Works reall well. VAX-82 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 57.3 TeX and LaTex but not LN03 3 of 6 5 lines 30-APR-1986 12:50 -< Talaris Sys - TeX >- ---------------------------------------------------------------- There is also a version of TeX for Talaris laser printers available from Talaris Sys in Calif. ================================================================ Note 57.4 TeX and LaTex but not LN03 4 of 6 8 lines 30-APR-1986 13:19 -< VersaTeX >- ---------------------------------------------------------------- We use Versatec printer/plotters for draft copies. We wrote our own code to do the DVI to raster conversion. ================================================================ Note 57.5 TeX and LaTex but not LN03 5 of 6 12 lines 30-APR-1986 13:37 -< TeX User's Group >- ---------------------------------------------------------------- There are TeX drivers for just about any laser printer you can think of. Texset in Ann Arbor is a good place to start. The TeX User's Group newsletter (TUGboat) is published quarterly and contains an up-to-date listing of various drivers. You can get a sign-up sheet for TUG from the L&T campground in W. 103. (They also have LaTeX running on a VAXstation, with the LSE LaTeX templates). Also, the Languages and Tools Information folder contains a list of tool sources that includes places to find TeX drivers. You can pick it up from the L&T campground. VAX-83 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 57.6 TeX and LaTex but not LN03 6 of 6 19 lines 30-APR-1986 15:42 -< draft printing and previewing >- ---------------------------------------------------------------- original message was interested in draft copies. addison-wesley publishing's pc tex offers several printing-quality modes (including draft) for the several printers it supports. another company has tex for the ibm pc, but apparently not for different quality modes. concerning draft quality, there are also screen previewers for viewing the output without wasting reams of paper. addison-wesley will also be coming out with tex for the macintosh, and will have a screen previewer for it. there is also already a screen previewer for pc tex on the ibm, but it requires a hercules (?) graphics board. i have no idea how well it works. gotta send a note to the notes note about adding functionality (like text reformatting when you add text to the middle of a line, and cutting and pasting) ================================================================ ================================================================ ================================================================ Note 59.0 Mount Verification Timeout Recovery 2 replies 16 lines 29-APR-1986 16:52 ---------------------------------------------------------------- I had a fault on a disk. The mount verification timed out. We observed the transaction count (greater than 1) and stopped all processes which could possibly be using the disk (we thought). We tried to remove installed images, but the the install didn't want to since the disk was "unavailable". We tried to dismount the disk despite the transaction count remaining at 2. It was marked for dismount but not dismounted. We then discovered the DISMOUNT/ABORT command and tried it. Of course we got the device not mounted message. We tried to mount it and got the device already mounted message. We finally shutdown and rebooted the system to get the disk back. VAX-84 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Did we have some less drastic alternative. ================================================================ Note 59.1 Mount Verification Timeout Recovery 1 of 2 8 lines 30-APR-1986 10:11 -< Install/Command_mode to remove KFE >- ---------------------------------------------------------------- Yes, there is a less drastic way IF the problem is installed files. There is an option in the INSTALL/COMMAND that will tell install to remove the entry, period, regardless if it can get to it. I believe the format is REMOVE USER1:[FOO]BAR, but am not 100% sure. ================================================================ ================================================================ ================================================================ Note 61.0 Recovering from spurious XOFF 2 replies 10 lines 29-APR-1986 16:56 ---------------------------------------------------------------- From time to time, one or another of our devices sends a spurious XOFF. These are devices like printers and embossers running through sometimes bizarre communications gear. How can we restore the flow of data without unplugging the device from the port, plugging in a terminal, and hitting control-Q? ================================================================ Note 61.1 Recovering from spurious XOFF 1 of 2 5 lines 30-APR-1986 01:14 ---------------------------------------------------------------- Yes, though you'll have to write a little program to do it. There is a "mode" you can set with a SETMODE QIO to the terminal line that clears the XOFF condition. The name escapes me, but it's really obvious - probably XON. See the chapter on terminals in the I/O User's Guide. VAX-85 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 61.2 Recovering from spurious XOFF 2 of 2 9 lines 30-APR-1986 16:59 -< easy as pie >- ---------------------------------------------------------------- You can also use SET TERM/XON ttxn:. It does the $QIO that 61.1 mentions. You need SHARE priv. This is not doucmented because it isn't perfect. If there is another I/O not done posted to the terminal, it may not get through. ================================================================ ================================================================ ================================================================ Note 64.0 Suspected BUG in NOTES! 8 replies 9 lines 29-APR-1986 17:43 ---------------------------------------------------------------- I think I have found a bug in notes. Several times now I have done a DIR /ALL and gone to the beginning (notes 1-17) of the buffer. I have then read a note and a reply. Upon going back to the directory, I have been unable to go past note 17. Any ideas on what I am doing wrong? ================================================================ Note 64.1 Suspected BUG in NOTES! 1 of 8 8 lines 29-APR-1986 17:54 ---------------------------------------------------------------- In VAX Notes, the DIR command displays 17 entries surrounding your current Note context. So it's not a -bug-, it's the way Notes works. To get beyond 17, you have to establish a new context. The easiest thing to do is simply read the latest topic (the header shows the number of topics) and then do a DIR. VAX-86 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 64.2 Suspected BUG in NOTES! 2 of 8 4 lines 29-APR-1986 18:07 ---------------------------------------------------------------- Or: Notes> DIR 999-1 Or: Notes> DIR *.* ================================================================ Note 64.3 Suspected BUG in NOTES! 3 of 8 3 lines 29-APR-1986 20:56 ---------------------------------------------------------------- Or DIR LAST-1 (reverse listing, topics only) Or DIR * (forward listing, topics only) ================================================================ Note 64.4 Suspected BUG in NOTES! 4 of 8 9 lines 30-APR-1986 09:59 -< It's not a feature, it's a pain. >- ---------------------------------------------------------------- Come on, guys, let's call it what it is. It's a kludge to have to "re-establish context" by doing a DIR 999-1 or reading the last message. You should be able to get to higher numbered directory entries by hitting the PREV SCREEN key or the keypad 5 while displaying the directory. ================================================================ Note 64.5 Suspected BUG in NOTES! 5 of 8 3 lines 30-APR-1986 12:37 ---------------------------------------------------------------- re .4: You are of course correct. Fixed in a future release. VAX-87 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 64.6 Suspected BUG in NOTES! 6 of 8 3 lines 30-APR-1986 12:38 -< look again >- ---------------------------------------------------------------- RE:64.4 Prev Screen does work as mentioned!! ================================================================ Note 64.7 Suspected BUG in NOTES! 7 of 8 8 lines 30-APR-1986 14:06 ---------------------------------------------------------------- RE: .6 Only if you have used NEXT SCREEN to scroll down a screen or two. It doesn't work if you're on the first screenful of the current directory listing. This is a known problem in NOTES and a correction is being investigated. ================================================================ Note 64.8 Suspected BUG in NOTES! 8 of 8 3 lines 1-MAY-1986 16:34 -< another way >- ---------------------------------------------------------------- To get to the top, just type 9999999 and it will show you the newest message. ================================================================ ================================================================ ================================================================ Note 66.0 Bad pages in memory 2 replies 10 lines 30-APR-1986 09:35 ---------------------------------------------------------------- When running under VMS version 4.1, 260 bad pages show up when you do show memory. Diagnostics show that all the memory is good and no memory errors are logged. How can I find out where the bad pages are and remove them other than removing the boards one by one. VAX-88 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Show memory under version 3.7 will not reveal these bad pages. System has been running fine with this problem. ================================================================ Note 66.1 Bad pages in memory 1 of 2 14 lines 30-APR-1986 14:10 -< ANALYZE/ERROR >- ---------------------------------------------------------------- Had a problem with a VAX780 system -- bad memory was showing up occasionally. Turned out to be from two sources -- one was the diagnostics. Apparently the diagnostics left garbage out in the second memory controller which VMS saw as bad memory. The other was caused by a couple of failing boards. ANALYZE/ERROR showed which board(s) was bad for the latter. Dumping the memory power supply (while the system was down) to clear the memory and then rebooting cleared the other. ================================================================ Note 66.2 Bad pages in memory 2 of 2 20 lines 1-MAY-1986 09:29 -< SHOW MEMORY >- ---------------------------------------------------------------- If VMS has detected memory errors and discarded pages as a result, SHOW MEMORY will indicate 3 different failure possibilities: Dynamic: number of failures AFTER the system was booted I/O Errors: number of failures detected during page fault handling Static: number of failures detected during the memory test at bootstrap time Errors that occur during the bootstrap test cause VMS to discard the pages that encountered the errors. No data is logged at this time because the boot-time environment has no way to talk to the error logger. If memory diagnostics do not call out the problem you may have intermittent single-bit errors. VAX-89 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 71.0 BANNER PAGES AND LASER PRINTER PAGE LENGTH 2 replies 14 lines 30-APR-1986 10:57 ---------------------------------------------------------------- WE HAVE TO SET ARBITRARILY LONG PAGE LENGTHS (255) FOR OUR LASER PRINTER QUEUES (PRINTERS ARE NON-DEC) SO THAT WE CAN CONTROL THE PAGING WITH COMMANDS SENT TO THE PRINTER. THIS PAGE LENGTH IS SET WITH THE DEFINE/FORM COMMAND WHICH IS THEN ASSOC WITH THE QUEUE. THE PROBLEM IS THAT WE NOW HAVE BANNER PAGES THAT ARE ALSO 255 LINES AND MULTIPLE PAGES. WE ALSO HAD THIS PROBLEM WITH THE WIDTH BUT SOLVED IT BY SETTING A REASONABLE WIDTH AND USING /NOTRUNC/NOWRAP ON THE QUEUE. IS THERE A WAY TO HAVE MY BANNER PAGE FIT ON ONE PAGE AND THEN HAVE AN ARBITRARY LENGTH/PAGE FOR THE DOCUMENT BEING PRINTED? ================================================================ Note 71.1 BANNER PAGES AND LASER PRINTER PAGE LENGTH 1 of 2 6 lines 30-APR-1986 14:48 -< ex >- ---------------------------------------------------------------- You can fix this by DEFINEing/FORMs (must use /STOCK=DEFAULT if no paper change is desired) that specify the page geometry and RESET entry associated with each output format. (see notes on PRINT/RESET=) ================================================================ Note 71.2 BANNER PAGES AND LASER PRINTER PAGE LENGTH 2 of 2 8 lines 30-APR-1986 17:08 -< use INIT/QUEUE/DEFAULT=NOFEED >- ---------------------------------------------------------------- Initializing the queue /DEFAULT=NOFEED will probably solve your problem. Define the page length to obtain the desired banner length. Using /NOFEED (which may also be specified on the PRINT command) will cause the symbiont to allow pages to run past the page length without inserting a form feed. VAX-90 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 72.0 LSE TPU source 1 reply 12 lines 30-APR-1986 10:59 ---------------------------------------------------------------- I'd like to be able to extend LSE using my particular flavor of EVE. This is a problem because of the way that LSE is implemented in TPU - that is, there is no TPU source for the section, so the only way one can modify the LSE editing interface is to write TPU code from scratch, rather than layer it on top of existing code like EVE. Is there a work-around? Is there any chance that DEC will release the LSE TPU source? ================================================================ Note 72.1 LSE TPU source 1 of 1 18 lines 30-APR-1986 14:13 ---------------------------------------------------------------- At present, there is no work-around. We do not release the LSE TPU source because it is in a state of flux. It changes (sometimes rather radically) from update to update. We do not want to pull the rug out from our users, and we don't want to be constrained by the current state of the code. Therefore, we don't ship the sources at present. We recognize this is a problem and we're doing a couple of things in this area. First, EVE, NOTES, and LSE are working towards adopting a "common editing kernel" of TPU procedures. These would be documented for users to use in their own TPU extensions to the products and would be available uniformly across the various products layered on the TPU editing engine. We're not there yet, though. Second, we are looking at making more of the internally-used TPU procedures in the LSE section file documented, stable, and supported so user-written code can use them. VAX-91 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 73.0 DISKQUOTA problem - Disk Leakage 9 replies 18 lines 30-APR-1986 11:02 ---------------------------------------------------------------- Every since installing VMS V4.x the DISKQUOTA system leaks!!! That is the space used reported by SHOW QUOTA is very often + or - by large amounts from the real space used!! I know of the bug associated with EDT that causes the space used to get off by one block with every edit. We however are sure that this is not the only bug!!!!! In fact, recently we have seen that a PL/I program writing a disk file until the QUOTA is exceeded will bomb is such a way that when the file is delete the QUOTA used is not reduced by the size the space released. This problem is not allways reproducable... ================================================================ Note 73.5 DISKQUOTA problem - Disk Leakage 5 of 9 16 lines 30-APR-1986 15:11 -< comments and caveats >- ---------------------------------------------------------------- We noticed this problem back with V4.1, and a number of our users had problems with it. I called TSC. First they said you had to add one block for every file you own - however this was not enough to cover the difference (often as high as 10% over what dir/size + of files totalled). I read the other replies. It may be true that the file system sometimes loses headers, but I find it hard to believe that this would account for all the missing space either. I was told that the software engineers were "aware of the problem". Maybe in 4.4 they will have found a way to correct it. By the way, analyze /disk/repair will fix it, but it will start to accrue again afterwards, so this is not a true fix. VAX-92 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 73.9 DISKQUOTA problem - Disk Leakage 9 of 9 26 lines 1-MAY-1986 18:22 -< More ways to miss files >- ---------------------------------------------------------------- re: .5 Adding one block per file accounts for the headers. However, some files can have extension headers - if they have a lot of extents or big ACL's, for example. Hence, that's only an approximation - each extension header also costs one against the quota, but doesn't get accounted for by DIRECTORY. Finally, depending on you have the directories themselves. If you do a DIR/GRANDTOTAL [*...] the directories files - and, in fact, ALL files - in [000000] are not counted. You can try: DIR/GRANDTOTAL [000000...] which counts thos files, but causes another problem: any given filespec can only contain 8 levels of subdirectory, and an explicit [000000] counts as a level; so this command will miss anything in directories exactly 8 levels down. DIR/GRANDTOTAL [*...],[000000] should catch everything - ASSUMING that you haven't used rooted directories to create stuff that is REALLY more than 8 levels down from the MFD, and that no users have done that either. ================================================================ ================================================================ ================================================================ Note 76.0 running out of PAGEDYN 9 replies 31 lines 30-APR-1986 11:35 ---------------------------------------------------------------- I had a VAX system that started to run out of PAGEDYN (not NPAGEDYN, but PAGEDYN.) The symptom was that users would get through LOGINOUT to the point of the Welcome message, then die with the message "Insufficient dynamic memory." I traced the problem to insufficient pagedyn, and used SDA to find out where it was going. Nothing looked too strange, though - just a few piggy logical name tables. However, I didn't want to just "add a few more thousand bytes." I want to know how PAGEDYN is allocated and used during process creation. VAX-93 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference 1. How much PAGEDYN is required to complete LOGINOUT? The problem started to evidence itself at about 10-12k bytes left. But HOW MUCH is actually required? I.e., at what point will LOGINOUT fail? 2. As processes are created and deleted, PAGEDYN doesn't change very much. Not surprising - it's dynamically allocated. But the only reason I can think of why it doesn't change much is that there is some sort of PAGEDYN sponge out there soaking up all my spare PAGEDYN to some limit. In this case, the limit must be "wrong" - i.e., not big enough to allow me to create processes? This is all happening in a cluster, on a 780, running VMS V4.2. Any ideas anyone? ================================================================ Note 76.1 running out of PAGEDYN 1 of 9 14 lines 30-APR-1986 15:33 -< some thoughts on pagedyn and logname tables >- ---------------------------------------------------------------- We saw exactly the same problem when doing our conversion to v4 from a 3.7 system; we changed our user-application environment and converted what had been a bunch of separate group logname tables to system shared logname tables. lots of them. some very large. and once created,they stick around. our only solution was to vastly pump up the pagedyn. tsc recommended that we put it way up until we figured out what the system 'stable' point was; then set pagedyn about 20000 bytes hugher for 'normal' use (on a 785). it seems to have worked. By 'stable' point I mean once the system has started and the first user logs in, SHO MEM shows X bytes pagedyn 'in use'. Wetook that number and added 20K. ================================================================ Note 76.2 running out of PAGEDYN 2 of 9 7 lines 1-MAY-1986 10:24 -< agreeded an Pagedyn. maybe decnet??? >- ---------------------------------------------------------------- At Racal, we had the same problem, Pagedyn turned to PageOcean so bad that sho mem comes back with Pacific+Atlantic. I found Decnet to use a great deal. I dont have a solution but I agree that it sure eats you out of BYTE and home-BLOCK. VAX-94 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 76.3 running out of PAGEDYN 3 of 9 12 lines 1-MAY-1986 10:37 -< I agree,...but check disk caching also >- ---------------------------------------------------------------- :-) I agree as well...also any disk caching you may be doing is allocated from pagedyn....Keep that in mind...If pagedyn is to low disk caching will be effectivly turned off..ie only 7 entries will be cached..."TSC" said to add another 20K to make it work...If you are low on pagedyn...check to see that disk caching is turned on also...it may be off because of lack of space...instead of 20K addition you may have to add 50K!!! ================================================================ Note 76.4 running out of PAGEDYN 4 of 9 10 lines 1-MAY-1986 12:12 -< 20 k isn't very much cushion! >- ---------------------------------------------------------------- You'd be better off waiting until your maximum number of users log in, then calculate PAGEDYN as used+(20 to 100)k. Each process gets a fair bit of memory - particularly if your people have discovered job logical name tables (I have!). During process startup, the system assumes worst case shared logical name table creation (group + job + some others odds and ends). If you don't have that available, then you get insufficient memory errors. (Also do a SHOW MEMORY /POOL /FULL because it can get very fragmented.) ================================================================ Note 76.5 running out of PAGEDYN 5 of 9 8 lines 1-MAY-1986 14:35 -< Use AUTOGEN for param. changes >- ---------------------------------------------------------------- RE: .3 If you do determine that the problem may be in the XQP caches (low hit rate (<75%), moderate attempt rate from Monitor/SPM), then you'd want to bump up the appropriate ACP* parameter in MODPARAMS, then re-Autogen. Do NOT just bump these (or PAGEDYN) in SYSGEN, because of the effect on other parameters, like SYSMWCNT. Autogen knows about these relationships, and will correctly "trickle-down" your changes. VAX-95 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 76.6 running out of PAGEDYN 6 of 9 13 lines 1-MAY-1986 15:09 -< PAGEDYN used by caches >- ---------------------------------------------------------------- Recently I was doing some tuning of the ACP caches, trying to achieve a larger hit rate. I discovered that all of the ACP caches come out of PAGEDYN, and that if you increase them, you had better increase PAGEDYN as well. We had the same login problem after my increases to cache. I did pretty much what everyone else says: bumped it up a lot, like 50K, and then did a SHOW MEM when the system got busy to see how much was actually in use. It would be helpful if DEC would document how much paged pool is used up by each of the various ACP caches so we can calculate how much paged pool will be eaten up if we increase them. ================================================================ Note 76.7 running out of PAGEDYN 7 of 9 15 lines 1-MAY-1986 16:17 -< Possible solution ???? >- ---------------------------------------------------------------- We recently had a somewhat similar problem but we had plenty of pagedyn available ( 300,000 bytes allocated, 156,000 used) and increasing pagedyn did not make the "insufficient virtual memory" message go away. After much harrassment of software support they found a "special" sysgen parameter called CTLPAGES (or something close to that) that controls the virtual memory for individual processes. I believe the default if 50 and we changed it to 100 and have not seen the message yet. ================================================================ Note 76.8 running out of PAGEDYN 8 of 9 6 lines 2-MAY-1986 07:34 -< Check your MOUNT command ! >- ---------------------------------------------------------------- One thing to definitely check is to make sure that you are not doing a MOUNT/PROCESSOR=UNIQUE on your disk devices. This will create a brand new set of "shared" XQP caches for each device mounted this way. These caches come out of paged pool. Incidentally, the problem given in ;-1 is due to process IO VAX-96 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference space reserved to RMS probably being depleted. This obviously has nothing to do with paged pool. ================================================================ Note 76.9 running out of PAGEDYN 9 of 9 16 lines 2-MAY-1986 11:29 -< Thanks for the help >- ---------------------------------------------------------------- I found out about the CTLPAGES parameter from TSC as well. But when I looked into the Internals manual I soon realized that it had nothing to do with the problem, as SIEGAL has noted. So whatever made your problem go away was not related to the CTLPAGES parameter. (I tried it anyway - it's possible that TSC knew something that wasn't documented in the V3 internals manual - but it didn't help in our case.) Thanks to everyone for the ideas on this. But is there anyone at DEC who can answer the original questions?...I.e., what is the "magic number" that a processs requires to be created?...etc. ================================================================ ================================================================ ================================================================ Note 85.0 PCA with DTM 1 reply 22 lines 30-APR-1986 14:07 ---------------------------------------------------------------- I am a novice PCA user and have never used DTM. I have a problem using PCA which I know cannot be solve within PCA but possibly there is an answer if PCA is used with DTM. Here is the question: I have a quality assurance requirement that I must show path coverage for all lines of executable code within a given routine. This assures no dead source code. I can use PCAs path coverage operation to do this. The problem comes when I must change a test driver routine to force coverage of lines of code that a previous test did not cover. ie. Ten routines linked to form one image is executed and shows 50% executable line coverage in one module. I must link with another driver to show coverage of the other 50%. I cannot simply use the append datafile to collect the two path coverage data for this one module because I have two different executable images. VAX-97 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Can I use DTM in conjunction with PCA to combine this coverage data into one printable report? ================================================================ Note 85.1 PCA with DTM 1 of 1 28 lines 1-MAY-1986 09:39 -< PCA and DTM >- ---------------------------------------------------------------- I'm afraid the answer is no. DTM does not help overcome PCA's limitations. The obvious first suggestion is for you to combine your two drivers into one image, I expect that you have good reasons for not doing so. As a second suggestion, you could use the LIST command to analyze the data from both data files with a program you write. That doesn't sound like much fun and you could get the same effect by placing two listings side by side. Finally, we'll add your need to our wish list. We are aware that many contracts require coverage data and we are considering ways to enhance PCA's coverage support. A brief explanation of DTM's interface with PCA follows: The user must link his program with the collector and provide an initialization file which contains the collector commands necessary to gather the data. DTM provides the data file name. The user then runs those test he wants. From DTM's review mode, the PCA data can be accessed with the PCA command. DTM's review mode spawns another process and starts PCA's analyzer. DTM passes the name of the data file and sets up a filter which makes the information from the "current" test available. Thus, PCA uses DTM's paradigm, one of reviewing the results of one test at a time. Once the user is sitting at the analyzer prompt, of course, the filter could be canceled and all of the analyzer's capabilities could be used. VAX-98 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 92.0 set terminal/speed=38400 2 replies 7 lines 30-APR-1986 14:36 ---------------------------------------------------------------- I recently found out that I cannot use my DHV or DHU at 38.4K baud under VMS, since there is no way to use the set terminal command. Set terminal only goes to 19.2K. Calling software support got the reply "I have never heard of 38400 baud, and 19.2 is there but not supported". Any help? ================================================================ Note 92.1 set terminal/speed=38400 1 of 2 18 lines 30-APR-1986 17:09 -< long story... >- ---------------------------------------------------------------- 19.2 is supported, always has been. 38.4 is supported in V4.4, I think. The DHV has a feature that setting 38.4 can change the speed on another line. It has group A speeds and group B speeds. Each pair of lines of the DHV must be set to either an A group or a B group. Before 4.4, VMS only allowed A groups. V4.4 allows the /speed=38400 syntax, but I'm not sure what happens when you do that. The DHV really isn't any faster if you do set 38400. It has a throughput maximum that is hit about 19200. Sorry I'm not sure of the details, perhaps the 4.4 release notes have more. ================================================================ Note 92.2 set terminal/speed=38400 2 of 2 8 lines 1-MAY-1986 15:30 -< 38.4 with Emulex >- ---------------------------------------------------------------- Emulex sells a DHV emulator which can fake 4.3 into doing 38.4 kbaud, but I don't know if the thing will work properly at at that speed under 4.4. The Emulex DHV clone has higher throughput than the real thing. VAX-99 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 94.0 File Ownership "Leakage" 4 replies 43 lines 30-APR-1986 14:40 ---------------------------------------------------------------- We've been having a recurring bizarre problem whih we refer to as "file ownership leakage". This problem has occurred on a number of systems under V4.0, 4.1, 4.2, and 4.3. The particulars are as follows: A user (say [100,10]) creates a file in a directory owned by [100,0]. This user has TMPMBX, GROUP, NETMBX privs only. The disk is typically one volume of a multi-volume (2) set. This has been observed on both clustered and non-clustered systems. The user does not have any ownership privs associated with the volume. At some time during his session, usually following a WRITE and CLOSE of the file (all programming done from FORTRAN with "good" programs) the file will mysteriously change ownership - say to [143,43]. Both the original owner and the new owner appear to have new correlation with eachj other, and the problem is not restricted to a particular "new owner" - i.e., the new owner is random. The one clue is that the new owner has also been logged in at the same time as the original owner of the file. Disk quotas are enabled on the system. We have discussed this with TSC on several occassions and their suggestion has been to submit a SPR with an IMAGE BACKUP of the disks - note that this is about 6 6250 tapes! This seems like a waste of time since it only represents an after-the-fact image. we would appreciate any suggestions (esp from VMS development) on how to debug this problem/get the info that would be necessary to VMS devel. We have been unable to cause the problem to appear at will (of course). Our suspicion is that internal buffers are getting confused within the file system, but have no idea where to go from here. Note thtat no global buffers are assigned to the file. VAX-100 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference any suggestions??? ================================================================ Note 94.1 File Ownership "Leakage" 1 of 4 8 lines 30-APR-1986 15:03 -< Reply from info in today's XQP internals seminar >- ---------------------------------------------------------------- -< fixed? in 4....>- I only caught the end of XQP Internals today, but that was listed as one of the bugs (caused by losing the relative volume number and only using the FID) which has been fixed. It only happens under rare situations with volume sets. Probably fixed in 4.4 if you still have it under 4.3. Anyone from DEC with more info? ================================================================ Note 94.2 File Ownership "Leakage" 2 of 4 6 lines 30-APR-1986 15:48 -< Fixed in V4.4 >- ---------------------------------------------------------------- This problem did exist prior to V4.4. It HAS been fixed for V4.4. The problem, however, was only seen on volume sets. ================================================================ Note 94.3 File Ownership "Leakage" 3 of 4 1 line 30-APR-1986 17:42 ---------------------------------------------------------------- Correction. The fix did not make V4.4. ================================================================ ================================================================ ================================================================ Note 97.0 Indirect dialup access 3 replies 16 lines 30-APR-1986 15:10 ---------------------------------------------------------------- Problem: Under VMS 3.7 indirect dialup could be prohibited while V4.x does not prevent it. VAX-101 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference Under VMS 3.7 if I had VAXes on DECnet, some with dialup and some who did not permit dialup, it was possible to control the situation. If I dial in to node A and set host to node B, I could not log into any accounts set DISDIALUP. Under V4.2/4.3 I can log in. It should be possible for security concious sites to have a network connection but still disallow indirect dialup access as was the case under V3.7. DEC seems to take the position that this was an undocumented feature (I havent found it documented, have you?) and is therefore not to be expected in any future VMS. I consider this a security problem that should be addressed. Am I the only one who cares about it? ================================================================ Note 97.1 Indirect dialup access 1 of 3 13 lines 1-MAY-1986 17:43 -< They do provide it in V4.n >- ---------------------------------------------------------------- DEC has provided a very similar setup. I don't know the details of the syntax, but in AUTHORIZE, there is a /DIALUP qualifier for MODIFY (and others). It works in a similar way to ACCESS where you specify hours (primary and secondary) when someone can log in over a modem. You can set this to be /NODIALUP= and then specify all days all hours with (I believe) not much difficulty. Read the HELP inside AUTHORIZE for details and examples. ================================================================ Note 97.2 Indirect dialup access 2 of 3 20 lines 1-MAY-1986 17:53 -< Oops! Didn't read carefully enough! >- ---------------------------------------------------------------- Actually I just reread your problem and realised there was a little more to it than I first thought. I don't know whether my suggestion will fix it or not - you don't mention it - have you tried it? I find it a rather convoluted security problem. If the person with that account is allowed to log in over the network, why wouldn't you want them to dial in over the phone? We have never done that because we have a couple of computers which people need to access from home, which don't have enough ports for modems (e.g. uVAXes) of their own. You have an interesting point. It is possible that in V4 they have expanded the network database and stuff so that it is completely separate VAX-102 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference from any dialup access; also, when the RT driver passes Node B information about the source on Node A, the terminal character- istics are probably not in it, nor the process characteristics. Sorry my first reply will probably not help you - I don't know how to delete replies, or I would do that and save you the time. ================================================================ Note 97.3 Indirect dialup access 3 of 3 10 lines 2-MAY-1986 12:11 -< Not that simple... >- ---------------------------------------------------------------- No, the point of the problem is that DISDIALUP does not disable all dialup access to an account as it used to under V3.7. This was not an enormously effective check as it is easy to hook up a modem to a port without telling VMS it has been done. It was, however, rhobust enough that if you originated on a modem port and set host to some intermediate accounts on the same or other machines, you could still not log into a /DISDIALuped account. ================================================================ ================================================================ ================================================================ Note 105.0 750 w/Adage-3000 .. Bugcheck ASTDEL 8 replies 16 lines 30-APR-1986 16:05 ---------------------------------------------------------------- We have a 750 with an Adage 3000 ... Adage supplies their interface, the IK11. Sometimes when we boot the vax and load the IK Driver, VMS will crash with Bugcheck ASTDEL. At the last DECUS, I found someone who had the same problem, but no fix yet. Does anyone have a similar problem, And a Fix ?? ================================================================ Note 105.1 750 w/Adage-3000 .. Bugcheck ASTDEL 1 of 8 17 lines 30-APR-1986 16:17 -< IKDRIVER.MAR >- ---------------------------------------------------------------- I had the same problem with an Adage IK-11 board. It's an easy fix -- it turns out the initialization section (connect) of the driver neglects to clear R3 (I think it's R3 -- look in the init code for the register that gets dumped into the CSR) out -- then proceeds to load the contents of the register (plus a couple of VAX-103 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference bits the driver AND's in) into the CSR of the IK11 board and -- if the low (go) bit is set -- goodbye VMS. CLRL the register, reassemble and relink the driver (the "No Transfer Address" message is normal). This has calmed the driver down considerably. ================================================================ Note 105.2 750 w/Adage-3000 .. Bugcheck ASTDEL 2 of 8 2 lines 30-APR-1986 17:35 -< THANK YOU THANK YOU THANK YOU *KISS* >- ---------------------------------------------------------------- YAHOO!!!! That problem has cursed us for two years!!! THANK YOU!!! ================================================================ Note 105.6 750 w/Adage-3000 .. Bugcheck ASTDEL 6 of 8 14 lines 1-MAY-1986 13:11 -< another crash problem with adage >- ---------------------------------------------------------------- Interesting, we have not seen that problem on our 780, but another graphics device on the same unibus has taken to crashing the system ever since we added the adage ik11. maybe it is a related problem depending on what went out to the csr... has anyone else had this type of problem? it is not a boot, but occassionally the non-adage device program crashes at the point the first ios go to it (it is a vector general). pulling the adage board seems (note, seems) to fix the problem. ================================================================ Note 105.7 750 w/Adage-3000 .. Bugcheck ASTDEL 7 of 8 21 lines 1-MAY-1986 16:27 -< Just a bit off... >- ---------------------------------------------------------------- The IK-11 board driver suffered intermittant crashes under earlier versions of VMS -- but VMS V4.x did it in. The driver was originally from Adage but comments in the code indicate they picked it up from Schlumberger (Please excuse any misspellings) Doll Research Center. SDR cleaned it up quite a bit from earlier versions. The register bug was found after much digging around in the source code. (got REAL sick of picking up the pieces of the crashes) VAX-104 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference System involved was a V750 under V4.x. (V4.0 to start -- tested thru V4.2 -- with no problems) P.S. Don't run the interface cables long without shielding them either... This'll cause equivalent unpleasant weirdness. (25' worked fine. 50' -- unshielded -- crashed VMS) ================================================================ Note 105.8 750 w/Adage-3000 .. Bugcheck ASTDEL 8 of 8 13 lines 1-MAY-1986 16:33 -< Bus Hog >- ---------------------------------------------------------------- Also: The Adage board is a BUS HOG. We suffer UDA time-outs on the UNIBUS when somebody performs a transfer to the IK11. This results in all sorts of interesting messages in the error log. This MIGHT adversely affect other boards on the bus -- the UDA "simply" re-initialized. The company I did the work for wasn't on great terms with Adage when I made this fix... ================================================================ ================================================================ ================================================================ Note 108.0 CPUBIAS 4 replies 6 lines 30-APR-1986 16:46 ---------------------------------------------------------------- Is it possible to bias which CPU processes can run under on the 8800 etc., via the SET PROCESS/CPU command? ================================================================ Note 108.1 CPUBIAS 1 of 4 13 lines 30-APR-1986 16:50 ---------------------------------------------------------------- Well, sort of... Under VMS V4.4 there is a $SET PROCESS/NOATTACHED which will prevent the scheduler from ever running that process on the attached processor. It really doesn't make a whole lot of sense to try and schedule a process for only the attached, cause every process does something that requires kernel mode, or at least page faults once.... VAX-105 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 108.2 CPUBIAS 2 of 4 27 lines 30-APR-1986 16:58 -< SET PROC/CPU=[NO]ATTACH bias >- ---------------------------------------------------------------- Yes, there is a form of biasing that the SET PROCESS/CPU command creates. The biasing is not of the form "which processor do I run on", however, but defines whether or not the process *can* be run on the secondary processor. This command tries to get around a very common 782 complaint - namely that a process doing a significant amount of I/O can be scheduled for execution on the secondary processor and then, once it is on that processor, initiate an I/O. This requires the process to be rescheduled to the primary to service the I/O - thus the wasted effort (read "inefficiency") of moving it to the secondary in the first place. Now, if you know a process is going to be predominantly doing I/O, you can prevent this from occuring by defining that process as not being executable on the secondary. (Through a SET PROCESS/CPU=NOATTACH) If a process has not been restricted to the primary by the use of the NOATTTACH option and is computable in USER mode code, there is no method of biasing which of the processors it will be executed on. If it was doable, attempting to force this bias could lead to system-wide inefficiencies by having, for example, two batch jobs biased for the secondary while the primary is happily running the NULL process. ================================================================ Note 108.3 CPUBIAS 3 of 4 8 lines 30-APR-1986 17:10 -< VMSD2 >- ---------------------------------------------------------------- VMSD2 (So I've been told) holds the highest priority process allowed to run on the attached processor. Interestingly bothe the 8300 and the 8800 show this parameter at zero. (The way the scheduling works on compute bound processes don't get the priority boosts that the I/O-intensive processes get.) VAX-106 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 108.4 CPUBIAS 4 of 4 10 lines 1-MAY-1986 17:13 -< VMSD2 = 0 >- ---------------------------------------------------------------- Re the previous reply: a lot of parameters are set to 0 when they really mean there's no limit (e.g. MAXDETACH). This looks like one of them. After all, it wouldn't make much sense to only allow the NULL process to run on the secondary. Somebody at DEC has a sense of humour! ================================================================ ================================================================ ================================================================ Note 109.0 RA Dual port to UDA and KDA? 5 replies 11 lines 30-APR-1986 16:55 ---------------------------------------------------------------- I would like to share data on RA81's currently on a UDA50 on a 785 with a soon to be installed MicroVAX II. They will have ethernet running between them, but I would like to have direct access to the RA devices from the MVII without adding overhead to the 785 or using the Ethernet. I do not NEED any kind of lock manager at either the File or Record level. Can I dual porting RA81 to a UDA50 and KDA50 (or KDB50)? ================================================================ Note 109.1 RA Dual port to UDA and KDA? 1 of 5 6 lines 30-APR-1986 17:10 -< Nope >- ---------------------------------------------------------------- In a word, "No." One or the other VAX system can have access to the disk at any given time, but not both at the same time. There's also no failover, as with HSC's. VAX-107 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 109.2 RA Dual port to UDA and KDA? 2 of 5 5 lines 30-APR-1986 17:16 -< Follow up question >- ---------------------------------------------------------------- Can I switch from one to the other with just a logical DISMOUNT on the first system and MOUNT on the second (leaving A and B in), or do I have to change the A and B in the middle? ================================================================ Note 109.3 RA Dual port to UDA and KDA? 3 of 5 0 lines 30-APR-1986 17:24 -< It should work >- ---------------------------------------------------------------- ================================================================ Note 109.4 RA Dual port to UDA and KDA? 4 of 5 13 lines 1-MAY-1986 10:34 -< Hearing no response from Colorado >- ---------------------------------------------------------------- Just to expand a bit on the reasons why it doesn't work with the later technology controllers: a lot of the drive state is known by the controller. The idea being that the controller is the one doing the seek and rotational optimizations that we all know so well. Remember that the controllers are talking to different CPUs and have different work items to perform. So if you were to have an active dual port, then both controllers would be fighting each other and unable to optimize any requests. There may be other reasons as well, but this is what comes to ================================================================ Note 109.5 RA Dual port to UDA and KDA? 5 of 5 6 lines 1-MAY-1986 16:17 -< Be sure to explain to the operator >- ---------------------------------------------------------------- The both-buttons-in approach works... Just make sure everybody coordinates mount's and dismounts... (Two processes using ethernet task-to-task could control...) VAX-108 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 111.0 Boot problem in Micro_vax II 4 replies 17 lines 30-APR-1986 16:59 ---------------------------------------------------------------- We have a Micro-Vax with 3 RD53s. The system disk is drive 0. Later I decided to put Standalone Backup [Syse...] on drive 1. The next time the system was booted it booted standalone Backup from drive 1 rather than VMS from drive 0 ... The Boot procedure looks at all disks starting at 0 to see if it is bootable in any way and then boots from the last drive which isn't the way it works on the other processors. When we complained to our local Field Service they say that this is a feature and not a Bug ... I find this unacceptable and no good reasons were given as to why this would be a feature for the Microvax Anybody else care to throw some light on this ? ================================================================ Note 111.1 Boot problem in Micro_vax II 1 of 4 17 lines 30-APR-1986 17:08 -< Removeables, then fixed >- ---------------------------------------------------------------- It's not supposed to work that way. The way it works is this: For each disk controller, in ascending order, it looks at all the removeable disks, in ascending unit order, then the fixed disks in ascending unit order. If a bootable system (presence of [SYSn.SYSEXE]SYSBOOT.EXE) isn't found, it keeps looking. It should only choose the [SYSE] root if you explicitly asked for it on the B command. But it WILL choose a removeable disk (RX50 or removeable RC25) over the fixed disk on the same controller, even if the unit number is higher. I realize this doesn't explain your problem, but the answer you were given isn't right either. Please see if the information I have given you helps at all. If not, please try your DEC support contact again. VAX-109 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 111.2 Boot problem in Micro_vax II 2 of 4 10 lines 1-MAY-1986 12:47 -< S/A BACK-UP ON NON-SYSTEM RD53 >- ---------------------------------------------------------------- I HAD A SIMILAR PROBLEM AFTER CREATEING S/A BACKUPS ON RD-53S. IT SEEM THAT STABAKIT LOOKS TO SEE IF THERE IS A SYS0 ON A DISK - IF SO, IT CREATES THE NEW S/A BACKUP INTO SYSE, ELSE INTO SYS0. IT TOOK ME AWHILE TO REALIZE THIS, THEN I RENAMED THE SYS0'S TO SYSE'S ON THE NON-SYSTEM DISKS (COULD HAVE DELETED THE SYS0 TRE ON THESE AND THEN SPECIFIED SYSE IN THE NEXT ATTEMPT TO CREATE S/A BACKUPS. ================================================================ Note 111.3 Boot problem in Micro_vax II 3 of 4 8 lines 2-MAY-1986 10:03 -< Boot order on uVAX-II >- ---------------------------------------------------------------- I had the same problem, only I had a backup copy of uVMS on Drive DU2:, and it booted instead of DU0:. Perhaps the boot rom mistakenly thinks it's removable and boots it. I don't see how it will autoboot [SYSE...] though. Could it be that your DU1: S/A-BU is really in [SYS0...]? ================================================================ Note 111.4 Boot problem in Micro_vax II 4 of 4 5 lines 2-MAY-1986 11:22 -< Bootable Software in [sys*...] >- ---------------------------------------------------------------- No my Standalone Backup is definitely in [syse...] Bootable Software can reside on any of [sys*...] directories ? Did you call your local DEC office about your system booting off DU2 ? VAX-110 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 122.0 Loss of Disk Quota Problem 1 reply 4 lines 1-MAY-1986 10:20 ---------------------------------------------------------------- I have two 785's on a cluster. I have seen disk quota entries that were modified go back to there pre-modified state. This seems to happen after a reboot of the system. Is this a known problem? Any work arounds? Vms version to fix this? ================================================================ Note 122.1 Loss of Disk Quota Problem 1 of 1 10 lines 1-MAY-1986 11:07 -< QUOTA.SYS cached >- ---------------------------------------------------------------- Periodically invoke DISKQUOTA and "REBUILD" the QUOTA.SYS file. Apparently the XQP caches QUOTA.SYS. After a long enough period of time QUOTA.SYS itself becomes "stale" and if the system crashes you can lose part of the cache currency. This info comes to you from an XQP novice who heard this in the "XQP internals session." P.S. They are working on the problem... ================================================================ ================================================================ ================================================================ Note 126.0 Foreign Terminals 5 replies 24 lines 1-MAY-1986 11:11 ---------------------------------------------------------------- Is there any hope at all for support of foreign terminals for any dec full-screen product? for example, notes is great, but most of our users have non-vt compatible terminals. we have a full-screen editor for these people (vi) but they can use none of the other dec full-screen stuff. ibm recognizes the exsistence of non-3270 terminals, and supports their use via a 7171 or yale series-1 emulator. seems to me that dec has fallen behind here, and ought to seriously consider support for non-vt compatibles. dec has made a token step in this direction with SMG, however, it is pretty useless, since most dec full-screen software does not use it. what our site needs is a reasonably-priced product that allows us to somehow tell vms VAX-111 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference what escape sequences to send to these foreign terminals to allow the users of these terminals to function productively with decs full-screen products. ================================================================ Note 126.1 Foreign Terminals 1 of 5 5 lines 1-MAY-1986 12:07 -< SMG, SMG, SMG! >- ---------------------------------------------------------------- Sad but true, it can't be done so long as VT Escape Sequences are hard-coded into the utilities. We're just going to have to convince the VMS developers that this isn't a little abberation that's going to blow over. Making it the 1 vote getter for San Fiasco's SIRs will go a long way toward this! ================================================================ Note 126.2 Foreign Terminals 2 of 5 6 lines 1-MAY-1986 13:08 -< DEBUG 4.4 uses SMG >- ---------------------------------------------------------------- Starting with version 4.4 of DEBUG the debugger will use SMG for it's screen output. ================================================================ Note 126.3 Foreign Terminals 3 of 5 10 lines 1-MAY-1986 13:59 -< Hurrah for DEBUG!!!!!! >- ---------------------------------------------------------------- Bravo, DEBUG folks!!! Wonderful! Now, can you tell the TPU people your rationale for reworking your product into SMG? So far, they seem to be insisting that if they redo TPU to use SMG, it would be unbundled and sold separately - which seems like sheer idiocy to me. Yay again, DEBUG! VAX-112 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 126.4 Foreign Terminals 4 of 5 20 lines 1-MAY-1986 15:37 -< smg and tpu >- ---------------------------------------------------------------- The hard part of making TPU work with SMG has already been done in VMS 4.4. TPU's screen updater is a separate shareable image. One can invoke a different screen updater with /display=imagename. Very minor changes are needed to make the current screen updater in TPU to use SMG's Foreign terminal routines instead of writing the hardcoded escape sequences to the terminal. These changes could then be bundled into a separate shareble screen updater image that woule be invoked on only foreign terminals. TPU's approach to supporting foreign terminals is actually better then the debuggers' method. VT100/VT200 users get the fast(current) screen updater image invoked on their terminals, and foreign terminal users would get the not so fast screen updater image that uses SMG. ================================================================ Note 126.5 Foreign Terminals 5 of 5 27 lines 1-MAY-1986 19:31 ---------------------------------------------------------------- Full-screen utilities fall into three classes: 1) Those that hard-code the screen support. TPU and products based on it, and EDT, are the only two that come to mind. These require special-case changes. EDT will never change. TPU is part way there (as noted above). 2) Those based on SMG. They automatically support foreign terminals through the SMG foreign terminal facility. Most new screen-based products are in this class. Many older ones are converting - e.g., DEBUG. 3) Those based on the old SCR library calls. These do NOT use the SMG FT facilities; but they DO use the old SCRFT.EXE facility. This was never really documented, outside of the file SYS$EXAMPLES:SCRFT.MAR on V3 systems (probably still on V4 systems). Note that to use the SCRFT facility, the terminal VAX-113 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference must be set to FT1, FT2, ... FT8. Many people forgot about this facility because of a problem in V4.0 and 4.1 in which an FTn erminal could NOT be handled by the new SMG foreign terminal facility. This left you with a choice: Support SMG applications, or support SCR applications. The choice was removed in (I think) V4.2: A terminal set as FTn can be correctly supported by both facilities. I've used systems set up this way, and they work just fine. There remains the inconvenience of calling the terminal FT1 instead of, say, DM1520, but that's pretty minor and will go away as various utilities migrate from Class 3 to Class 2. ================================================================ ================================================================ ================================================================ Note 127.0 EVE->WPSPLUS 3 replies 11 lines 1-MAY-1986 11:12 ---------------------------------------------------------------- Is there an easy way to bind the WPS-PLUS wrap symbol [it looks like an "o" when you do a Gold-View] to the Return key? I'm familiar with the Learn command, I just don't know how to refer to the word wrap symbol. Our application would be to transfer first draft documents created with EVE to the WPSPLUS environment for attribute enhancement and text/graph merging via DECpage. Currently, all the hard CR's screw-up WPSPLUS wordwrapping. ================================================================ Note 127.1 EVE->WPSPLUS 1 of 3 17 lines 1-MAY-1986 18:14 -< You can do this, but... >- ---------------------------------------------------------------- You could bind the return key to insert any text you wanted. For example, DEFINEKEY ("COPYTEXT ('')", RETKEY); would insert the string into your buffer whenever you pressed the return key. VAX-114 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference However, TPU doesn't understand the WPS-Plus wrap token, so you'd run into line length problems, and wouldn't be able to see your line. You'd probably be better off writing a small utility (perhaps in SCAN) to concatenate records and separate them by the character WPS-Plus uses to indicate wrapping. ================================================================ Note 127.2 EVE->WPSPLUS 2 of 3 8 lines 1-MAY-1986 20:32 ---------------------------------------------------------------- You could leave EVE alone and use TPU's callable interface,specifically a user-written FILEIO routine. When you write out your file, your fileio routine gets called each time a record is to be written to the output file. You could insert the Wps wrap symbol at the end of the record then write it out. ================================================================ Note 127.3 EVE->WPSPLUS 3 of 3 5 lines 2-MAY-1986 10:31 -< wps+ reformatting >- ---------------------------------------------------------------- If paragraphs are stored the way wps+ likes to see them then selecting at the top and then go to the bottom and gold paragraph. This will rejustify everything, but will take some time as screen reformatting is included in the process. If wps+ 2.1 can turn off screen update (some indication of this) this should be fairly painless. ================================================================ ================================================================ ================================================================ Note 128.0 Cluster w/non-Digital Disks 1 reply 12 lines 1-MAY-1986 11:31 ---------------------------------------------------------------- We currently have a 750 with 3 Fujitsu Eagles using Emulex controllers (CS-21). We would like to implement a cluster by adding a 780, an HSC50, and an RA-81. Has anyone had experience with using non-Digital disks as local disks on a cluster like this? If this will work, what penalties are incurred by using MSCP? VAX-115 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 128.1 Cluster w/non-Digital Disks 1 of 1 26 lines 1-MAY-1986 14:57 -< One user experience OK >- ---------------------------------------------------------------- We currently have a similar (sort of) cluster ... three 785's with two HSC-50's and 15 RA81's, plus massbus controllers from Emulex on all three with Fujitsu Eagles on them. One string of drives is dual ported between two of the 785's; the third processor's Eagles are local only. We mostly do not set the drives /SERVED right now, since we don'thave a particular need for it. But we have tried it previously using CDC 9766 drives and earlier Emulex controllers and it worked fine, no problems in the cluster. Just make sure the ALLOCLASS given tot he CPU's is different from that of the HSC's. We even tried using the drives dual-pathed, and that worked also, although with the earlier Emulex controllers we had to get a firmware upgrade to allow it. I think their Eagle controllers support it without any special upgrade. The overhead from the MSCP server was minimual because we made sure that most of the users accessing those disks were on one of the two CPU's that had hard connections to the drives. The main use via MSCP was when print files from one of the massbus disks got into a print queue on the node to which they had no direct connection. ================================================================ ================================================================ ================================================================ Note 129.0 Help implementing common page/swap file 5 replies 23 lines 1-MAY-1986 11:50 ---------------------------------------------------------------- I need help. I have heard that you may use the pageing file for not only pageing, but for swapping and as the dump file, also. 1) Is this possible? 2) how is this implemented (logicals??, SET FILE ... ???) 3) are there any performance hits I will take by doing this? 4) anything else I should know (where is it documented?) (IDS manual?) VAX-116 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference I have an 11/780 with an RM03 for the system disk running v3.7 and I want to upgrade it to 4.3. I'm worried about not having enough room on the RM03. I'd also like to know about how to do it if there aren't any other hits I will have to take. Oh, yes, it's an 8 Mb system with lots of memory to spare. I DON'T expect to do any swapping, or very little. Most times I have memory to spare, so don't see swapping as a potential problem. Thanks for helping. I'll be reading NOTES a couple of times per day. ================================================================ Note 129.1 Help implementing common page/swap file 1 of 5 14 lines 1-MAY-1986 13:37 -< swap/page/dump >- ---------------------------------------------------------------- Yes this is all possible. If there is no primary swap file, I believe swap file space will be automatically allocated in the primary page file...but you should install a secondary swap file asap. If you want to use the primary page file as a dump file you must you must be sure it is big enough. I don't know if the dump will go to the page file automatically...never tried it since I don't want my primary page file that big. I do plan, however to do away with my primary swap file, in an effort to remove as much swapping as possible off the system disk (on some of my systems) On a common system disk you probably want to do this, since the swapper uses the first swap file that has space, rather that the file that has the most space as the pager does. ================================================================ Note 129.2 Help implementing common page/swap file 2 of 5 8 lines 1-MAY-1986 13:39 -< its easy, but beware... >- ---------------------------------------------------------------- You can do this by deleting the swapping and dump file (DO NOT actually delete them.....rename them, reboot the system, then delete them; otherwise you will trash your disk!). The pagefile will be used for both paging and swapping. The dump will be written to the pagefile. See SYSGEN parameter SAVEDUMP. There may be performance problems with swapping and paging to the same file. Its usually not a good idea. And combining the files won't save you any disk space. You might consider a secondary pagefile on another disk. VAX-117 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 129.3 Help implementing common page/swap file 3 of 5 19 lines 1-MAY-1986 15:04 -< secondary pagefile >- ---------------------------------------------------------------- In case you didn't catch it in those last replies, one of the things you should DEFINITELY consider under V4 is installing a separate pagefile on another disk. In other words, leave your primary page file as small as possible (just big enough for the processes that are assigned to it at SYSTARTUP time before you SYSGEN>INSTALL the secondary page file) and put another pagefile on your data disk. You can do the same with your swap file. This will require that you have a separate (8MB) dump file (if you want dumps) but it will move your paging and swapping activity off the system disk - very, very important to performance. You didn't say what your data disks were, or how big, or anything. But unless you don't have any, you will want to implement what I have described. ================================================================ Note 129.4 Help implementing common page/swap file 4 of 5 17 lines 1-MAY-1986 15:08 -< Some clarification >- ---------------------------------------------------------------- .2 hit right on the head...you CAN swap in the page file, but it's kind of like driving nails with a pair of vise grips, that's not what page files were made for. There can be severe perf. problems because of the disparity in page and swap file allocation sizes; swap slots are big (usually multiples of 96 pages) and page file allocations tend to be much smaller, so over time, it becomes very difficult to find big, virtually contiguous holes in the page file for swap slots. If all the requests are big, as in a file dedicated to swapping, its not a problem. Note also, that regardless of whether you swap a lot or not, each process still needs to be allocated a swap slot, otherwise where would it go if it did have to be swapped? Another tidbit: As your working set size changes over time, your swap slot size changes as well, and it can migrate from file to file, whichever one has a hole big enough to accomodate your WS. On the other hand, you're assigned at process creation time to the page file that at that time, has the most space, and stay there for the life of the process. VAX-118 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 129.5 Help implementing common page/swap file 5 of 5 21 lines 1-MAY-1986 19:42 ---------------------------------------------------------------- To dump to the pagefile, you only need to not have a dump file; as long as SAVEDUMP is set, VMS will dump - to the dumpfile if possible, to the pagefile if necessary. Note that the SIZE of the dumpfile is not relevant: If you leave around a small dumpfile, you will get a truncated - and useless - dump. Whatever file the dump goes to must have room for every page in maim memory, plus 4 pages of overhead. BUT: There is a "gotcha'" here: The space used up in the pagefile for a dump cannot be used for paging at the next system boot until the dump is copied (using the ANALYZE/CRASH COPY command). Hence: Make sure the pagefile is BIGGER than the minimum size needed to store the dump so that some paging can take place, or you'll have to be very, very careful about your startup file; Be ABSOLUTELY SURE that, as early as possible in your startup file, you do an ANALYSE/CRASH SYS$- PAGEFILE.SYS and COPY the dump somewhere. ================================================================ ================================================================ ================================================================ Note 134.0 How'bout BACK/REC'D=IMMEDIATE 8 replies 14 lines 1-MAY-1986 14:01 ---------------------------------------------------------------- Can anyone think of why it would be a bad idea to have a BACKUP qualifier of /RECORD=IMMEDIATE that would allow an incremental (or any) backup to "post" the backup time on each file as soon as it completes the copy of that file rather than waiting til the very end of the BACKUP run? This would be wonderful, especially when I do my nightly incrementals from my micro-VAXs to my central backup disk across the network and the operation fails due to network failure. Then all I would have to do is test the BACKUP condition code for failure and rerun if necessary; thus only backing up those files that were missed in the first pass. This could be DEC's VAX-119 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference solution to request 108. Could this be worked in as an enhancement? ================================================================ Note 134.1 How'bout BACK/REC'D=IMMEDIATE 1 of 8 6 lines 1-MAY-1986 14:07 -< Nice Idea >- ---------------------------------------------------------------- I like it. I hate tieing up my tape drives while the record pass finishes. An equally acceptable implementation would be some means of deallocating the tapes as soon as the dump phase finishes. ================================================================ Note 134.2 How'bout BACK/REC'D=IMMEDIATE 2 of 8 5 lines 1-MAY-1986 14:31 -< I disagree--please don't implement >- ---------------------------------------------------------------- I doubt if you really want the backup date changed until the entire save-set is written so that the backup run is known to have been successful. another user ================================================================ Note 134.3 How'bout BACK/REC'D=IMMEDIATE 3 of 8 13 lines 1-MAY-1986 14:42 -< More backup >- ---------------------------------------------------------------- I'm willing to take responsibility to verifying that the backup completes. I have reloaded partial backup tapes before without any problems except for the last file (which was in progress when the machine crashed). Another equally good solution would be a utility to update the backup dates from a journal file. That way, I could get maximum use from my tapes, and batch out the rather long backup date updates. VAX-120 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 134.4 How'bout BACK/REC'D=IMMEDIATE 4 of 8 3 lines 1-MAY-1986 16:46 -< another disagree vote >- ---------------------------------------------------------------- I think the idea of dismounting/deallocating the tape drive during the record pass is a better idea than /immed ================================================================ Note 134.5 How'bout BACK/REC'D=IMMEDIATE 5 of 8 9 lines 1-MAY-1986 17:08 -< Give me a real good reason >- ---------------------------------------------------------------- Gosh guys, I just want it as an option, not a rewrite of the S/W. I do like the suggestion about using the terminated log file to possibly go out on the disk and update the BACKUP record date on those files. Maybe. The request originator, ================================================================ Note 134.6 How'bout BACK/REC'D=IMMEDIATE 6 of 8 4 lines 1-MAY-1986 17:27 -< dismounting tapes >- ---------------------------------------------------------------- The biggest problem with deallocating the tape is that it is usually mounted via a mount command somewhere earlier. I suppose this could be done with a /dismount/deallocate type structure. ================================================================ Note 134.7 How'bout BACK/REC'D=IMMEDIATE 7 of 8 3 lines 2-MAY-1986 10:43 ---------------------------------------------------------------- I wouldn't use it as it would make my incremental backup incomplete and I like complete full, incremental backup sets. My opinion VAX-121 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 134.8 How'bout BACK/REC'D=IMMEDIATE 8 of 8 9 lines 2-MAY-1986 11:19 -< Options aren't such a bad idea >- ---------------------------------------------------------------- If you really want to go home at night, it is safe to take the tape off the drive and let the console gestate on recording backup dates. Certainly an option wouldn't be bad for recording, but I'd rather teral have an option for dismount/deallocate ing the tape as soon as BACKUP is done. ================================================================ ================================================================ ================================================================ Note 138.0 TTY_DMASIZE 3 replies 9 lines 1-MAY-1986 14:56 ---------------------------------------------------------------- There is a SYSGEN parameter 'TTYDMASIZE' which apparently affects the size of the packet transmitted by a dmf or dmz controller (i think). Does anyone know the performance affects of changing this parameter? ================================================================ Note 138.1 TTY_DMASIZE 1 of 3 9 lines 1-MAY-1986 15:30 -< It's a threshold value. See SYSGEN documentation >- ---------------------------------------------------------------- This parameter really describes the minimum number of bytes that you need to request in a transfer for us to do the transfer as a DMA transfer. The reason this is there is that the initial setup for a DMA transfer is more expensive than other methods. Thus, we want to have some threshold value that we use to determine if it is worth the effort. Do you have a particular performance problem or is this something you were curious about ? If you have more questions on this then seek out John Hallyburton from the VMS performance group. VAX-122 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ Note 138.2 TTY_DMASIZE 2 of 3 12 lines 1-MAY-1986 15:45 -< ... no need to twiddle >- ---------------------------------------------------------------- We did a lot of research on TTYDMASIZE when first offering DMFs. The bottom-line conclusion was that the value of 64 was a reasonable default crossover point for all processors. Small increases up or down do not have much effect. Large increases are probably only going to make things worse. If your terminal controller only has a 1-byte output silo then perhaps you could gain something small by reducing the value to 42 or so. Odds have it that you won't notice any difference, though. ================================================================ ================================================================ ================================================================ Note 146.0 SOURCE LIBRARIES ACCESS 1 reply 10 lines 1-MAY-1986 17:04 ---------------------------------------------------------------- WE ARE HAVING PROBLEMS WITH UPDATING THE SOURCE LIBRARIES AT THE SAME TIME AS USERS ARE ACCESSING THESE LIBRARIES. THIS HAPPENS FOR BOTH SOURCE AND FORMS LIBRARIES. IF THE USERS ONLY NEED READ ACCESS, WHY DO THEY HAVE TO BE LOCKED OUT TO UPDATE THE LIBRARY? ANY COMMENTS ANYONE? ================================================================ Note 146.1 SOURCE LIBRARIES ACCESS 1 of 1 11 lines 1-MAY-1986 17:09 -< lock it up >- ---------------------------------------------------------------- We had a similar problem with updating object libraries. Since everyone was already using procedures to link against and to add modules to the library calls to three simple programs were set up. Each used the lock manager to control access to the libraries as a "resource". One program requested an exclusive write lock (with wait), one requested a read lock and the last released locks held. VAX-123 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference ================================================================ ================================================================ ================================================================ Note 147.0 Printing thru DECNET 4 replies 9 lines 1-MAY-1986 17:07 ---------------------------------------------------------------- I want to know how can I use a printer that is connected to a microvax from another microvax. Can I do this using INIT/QUEUE in both machines? I would like to be able to do this without having to copy files from one machine to the other (many of the users do not have an account in the machine with the printer). ================================================================ Note 147.1 Printing thru DECNET 1 of 4 8 lines 1-MAY-1986 17:11 -< nope >- ---------------------------------------------------------------- The only currently possible way to do this is to implement a custom symbiont with knowlege of the network. Which isn't trivial. The queue manager just can't get a good enough grip on the remote printer to work right. Several outfits (outside of DEC) are working on the symbiont idea. ================================================================ Note 147.2 Printing thru DECNET 2 of 4 43 lines 1-MAY-1986 17:29 -< Simple network symbiont >- ---------------------------------------------------------------- Writing a user-modified print symbiont to handle this is actually quite simple. Mine consists of 3 pages of simple BLISS code for the modified symbiont half of the thing and another 3 pages of BLISS code for the DECnet network object on the node with the printer. The basic idea is that you use PSM$REPLACE to supply your own output routine which opens the DECnet connection to the remote task (mine is called NETSMBSVR and then you simply write each line over the net as your output routine is called. The only difficult part is determining when the print JOB (as opposed to the print file, there may be more than one file/job) is done. The JOBCOMPLETION indicator in the PSM stuff is incorrect and VAX-124 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference really indicates file completion. The answer is to replace the (possibly undocumented) JOBTRAILER routine with your own that sets a flag in your code. You can even call the standard job trailer routine after you set the flag so that you get the trailers. The BLISS code for this looks like: routine netsmb_job_trailer (request_id, work_area, func, funcdesc : ref vector, funcarg)= begin builtin callg, ap; selectoneu ..func of set [PSM$K_CLOSE]: job_completing = true; tes; callg (.ap, PSM$JOB_TRAILER); end; In your main routine, you'll need: PSM$REPLACE (%ref (PSM$K_JOB_TRAILER), netsmb_job_trailer); This requires that the queue with your new symbiont have the attribute /SEPARATE=TRAILER. This isn't so bad... Hopefully there'll be a few of these on the next DECUS SIG tape. If you want mine, just contact me: ================================================================ Note 147.3 Printing thru DECNET 3 of 4 3 lines 1-MAY-1986 17:38 ---------------------------------------------------------------- There was a BOF session today on the subject of user modified symbionts. The gentleman who arranged the BOF had done what you are looking for. His name is David(?) Stone. ================================================================ Note 147.4 Printing thru DECNET 4 of 4 13 lines 2-MAY-1986 11:27 -< the wrong way to print thro DECNET? >- ---------------------------------------------------------------- VAX-125 PAGESWAPPER - August 1986 - Volume 8 Number 1 Dallas Symposium VAXSIG Notes Conference I was surprised to find that this appears to happen on our two microvaxes (that are ethernetted together). It turned out that the command PRINT on one machine is actually calling a DCL thing that COPYs the file to an "empty" directory on the other one which is being continually scanned by a BATCH job that PRINT/DELETES any file it finds. I might have been able to fetch the sources but the link was down as I wrote this. Maybe you can see what to do, as the directory is fully open, and no-one appears to have to have accounts on the other machine.. VAX-126 PAGESWAPPER - August 1986 - Volume 8 Number 1 VAX System SIG Committee List VAX System SIG Committee List As of January 8, 1986 Osman K. Ahmad - Large Systems Integration Working Group Association of American Railroads Technical Center, Research and Test Department 3140 South Federal Street Chicago, IL 60616 Joe Angelico - Assistant Symposium Coordinator US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA 70130 Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660 June Baker - Advisor Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046 Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 Bob Boyd - Commercial Working Group GE Microelectronics Center MS 2P-04 Post Office Box 13409 Research Triangle Park, NC 27709 C. Douglas Brown - Security Sandia Labs Division 2644 P.O. Box 5800 Albuquerque, NM 87185 VAX-127 PAGESWAPPER - August 1986 - Volume 8 Number 1 VAX System SIG Committee List Jim Caddick - VAXcluster General Datacom Strait Turnpike Middlebury, CT 06762-1299 Jack Cundiff - Symposium Coordinator Horry-Georgetown Post Office Box 1966 Conway, SC 29526 Tom Danforth - Handout Editor Woods Hole Oceanographic Institute Woods Hole, MA 02543 Jim Downward - Migration and Host Development, VAXintosh Working Group KMS Fusion Incorporated 3941 Research Park Drive Ann Arbor MI 48106 Jane Furze - Campground 3830 West Cochise Phoenix, AZ 85064 Dennis Frayne - Real Time/Process Control Working Group McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals Working Group In House Systems 165 William Street New York, NY 10038 Don Golden - Communications Committee Representative c/o Shell Oil Company Westhollow Research Center Post Office Box 1380, Room D2132 Houston, TX 77001 Gary Grebus - System Improvement Request Battelle Columbis Labs Room 11-6011 505 King Avenue Columbus, OH 43201-2693 VAX-128 PAGESWAPPER - August 1986 - Volume 8 Number 1 VAX System SIG Committee List B. Hancock - Network Working Group Dimension Data Systems, Incorporated 2510 Limestone Lane Garland, TX 75040 (214) 495-7353 Jeffrey S. Jalbert - Historian J C C Post Office Box 381 Granville, OH 43023 614-587-0157 Ray Kaplan - MicroVAX Working Group Pivotal Incorporated 6892 East Dorado Court Tucson, AZ 85715 Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 Art McClinton - Advisor MITRE 1820 Dolley Madison Boulevard McLean, VA 22102 Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Eugene Pal - Multiprocessor Working Group US Army CAORA (ATOR-CAT-C) Fort Leavenworth, KA Susan Rehse - System Management Working Group Lockheed Missiles 3251 Hanover Street Palo Alto, CA 94301-1187 VAX-129 PAGESWAPPER - August 1986 - Volume 8 Number 1 VAX System SIG Committee List Bob Robbins - Advisor Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Working Group Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA David Schmidt - LUG Coordinator, Hardware Working Group Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 D. Slater - Artificial Intelligence Working Group Institute for Defense Analysis 1801 North Beavregard Street Alexandria, VA 22314 VAX-130 PAGESWAPPER - August 1986 - Volume 8 Number 1 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA For information about on-line submission, dial (in the United States): (617) 262-6830 and log in with the username PAGESWAPPER - August 1986 - Volume 8 Number 1 INPUT/OUTPUT Submission Form PAGESWAPPER. PAGESWAPPER - August 1986 - Volume 8 Number 1 INPUT/OUTPUT Submission Form Tear out or photocopy reverse to submit an I/O item Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA PAGESWAPPER - August 1986 - Volume 8 Number 1 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - August 1986 - Volume 8 Number 1 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA PAGESWAPPER - August 1986 - Volume 8 Number 1 VAX Systems SIG Fall 1986 SIR Ballot VAX Systems SIG Fall 1986 SIR Ballot DECUS membership number __________________ (six digits) Our site uses the following VAX models (check all that apply) 8800 __ 8600/8650 __ 8500 __ 8300/8200 __ MicroVAX __ 11/780,11/782,11/785 __ 11/750 __ 11/730,11/725 __ We use VAX's in the following applications(Check all that apply) Business EDP ____ Software Development ____ Education ____ Computer Science Research ____ Data Acquisition/Control____ CAD/CAM ____ Service Bureau ____ Hardware Development ____ Scientific/Engineering ____ Office Automation ____ Telecommunications _____ Other __________________________ I support the following as the most important System Improvement Requests. (List from zero to fifteen SIR's): -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- I oppose the following SIR's as detrimental. (List from zero to five SIR's): -------- -------- -------- -------- -------- Mail to: Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, OH 43201 To be counted, you ballot must be received by August 29. PAGESWAPPER - August 1986 - Volume 8 Number 1 VAX Systems SIG Fall 1986 SIR Ballot Tear out or photocopy reverse to vote on SIRs Gary L. Grebus Battelle Columbus Division Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA