CHAPTER VAX PAGESWAPPER - July 1987 - Volume 8 Number 12 Editor's Workfile . . . . . . . . . . . . . . . VAX-3 Internals and Data Structures Manual . . . . . . VAX-4 VMS Futures . . . . . . . . . . . . . . . . . . VAX-5 Digital Responds to the Spring 1987 SIR Vote . VAX-16 Fall 1987 VAX System Improvement Request Ballot VAX-23 VAX/VMS Security . . . . . . . . . . . . . . . VAX-55 SDA "FORMAT" Problem Solved . . . . . . . . . VAX-58 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-59 VAX System SIG Committee List . . . . . . . . VAX-124 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-127 Internals and Data Structures Manual Petition VAX-129 System Improvement Request Submission Form . . VAX-131 VAX Systems SIG Fall 1987 SIR Ballot . . . . . VAX-133 PAGESWAPPER - July 1987 - Volume 8 Number 12 To register for 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. Articles for publication in the Pageswapper can 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 of text 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. 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 - July 1987 - Volume 8 Number 12 Editor's Workfile Editor's Workfile (Possible) Future Features in VMS The article entitled "VMS Futures" in this issue is taken from slides provided by Trevor Kempsell of DEC which he used in his presentation by that title at the 1987 US Spring Symposium in Nashville. There is the by now familiar sort of disclaimer at the beginning indicating that what you see very well may not be what you get. This brings to mind a particularly insightful comment made by a user at the DEC SIR response session in Nashville. After some others had indicated they really needed the ability to checkpoint jobs, and complained that it had been "promised" a long time ago, this thoughtful user reminded us all that there was no "promise" at all. When DEC breaks its normal silence to tell us what they are working on, experimenting with, or considering, it is only with the understanding that nothing is guaranteed. If users try later to claim that a particular feature was "promised" for the future, it will only make it even less frequent that DEC will share with us what they are considering for future software releases! SIR Voting Again This issue of the Pageswapper contains the Fall 1987 SIR Ballot. Thanks to Mark Oakley for pulling all the new choices together, so close on the heels of tabulating the previous list. The Ballot form will be repeated in the back of the newsletter for the next couple of months, but the text of the SIR's will only be printed in THIS issue. Likewise, those with accounts to do on-line Pageswapper submissions will again be able to cast their votes electronically, but they will need a copy of this issue in hand since the text is not presented on line (holding time on calls would strain our resources if voters were still contemplating while logged in). VAX-3 PAGESWAPPER - July 1987 - Volume 8 Number 12 Editor's Workfile VMS Notes from Nashville Coming next month, to a Pageswapper near you. Even beyond the goal of limiting this month's page count to maintain cordial relationships with DECUS staff and my fellow editors, there is the matter of information overload. With VMS Futures, SIR Responses and a new SIR Ballot this month, I felt I better delay something for the August issue. Internals and Data Structures Manual Ray Kaplan PIVOTAL, Inc. May 3, 1987 I have recently had the pleasure of working with Mike Mehan of Digital Press to get the part of the VAX/VMS Internals and Data Structures Manual that was done out to folks. He brought 1500 copies of what was done to the Symposia in Nashville. Most of them were sold, and you can be sure that the ones that went back with them will be quickly snapped up by internal DEC folks. So, where to from here? I suggest that you sign the petition provided in the questionnaire section at the back and mail this to me so I can send it on to Mike to help him tell the people at Digital Press that we want to see these publications as soon after the release of the operating system as possible. There is a school of thought that suggests that if you don't do it, it just won't get done. Copy the petition. Pass it around. Who knows, we just might have a V5 IDSM when we need it! Do it today. Tomorrow might be too late. See you! Ray Kaplan PIVOTAL, Inc. VAX-4 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures VMS Futures Disclaimer The purpose of this presentation is to let customers know some features that VMS and Language engineering groups are examining for future releases. This is NOT an announcement or commitment by Digital that any of the items discussed will appear in any Digital product. DECnet-VAX o Enhanced support for network proxies o Improvements to the routing layer o Performance improvements in MOM o Wildcard and multiple command recall support in NCP VAX/VMS kit changes o MicroVMS and VMS become one kit - Tailoring classifications - Kit has three save sets similar to VAX/VMS - All kits have useful MicroVMS files - All VAX/VMS files will be in the kit o New tailoring mechanism VAX-5 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures - Design center is tailor-off - Tailor-on is supported, but not optimal VAX/VMS File System Project O Files-11 ODS-2 file system - Re-worked file highwater marking - Alias file entry to include primary and secondary entries BACKUP o Prevention of accidental initialization of input disk o Lock-down of working set for standalone BACKUP o BACKUP performs its own $MOUNT requests o New qualifier /IGNORE=(TAPE_LABELS) requires VOLPRO o Perform more than one operation per standalone boot ANALYZE/DISK_STRUCTURE (Formerly VERIFY) o Choice of destination for lost files o Correct handling of file aliases and directory backlinks MOUNT o New qualifier /MULTI_VOLUME VAX-6 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures Terminal Fallback Facility (TFF) o What is TFF - TFF translates characters that are written into something the terminal can display. - TFF will translate input characters into their equivalent DEC Multi National Character set character - for the international market place o Includes a management utility - defines which table is to be used. - enable or disable TFF for a terminal or terminals. - shows information about what tables are available, and what is being used CLUSTER o Improve failover on disks and tapes - support failover on DSA disks (UDA, KDA, BDA) to provide more flexibility in high-availability - support dynamic failover and mount verification on HSC tapes o volume shadowing - V4.6 support for more members per shadow set VAX-7 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures o LAVc support integrated into VMS - as of V4.6, no more separate version for LAVc - LAVc key still required and separately licensed o Extensions to LAVc - support CI and Ethernet nodes in the same cluster, boot nodes can connect to HSC disks - support more satellites - volume shadowing is only available on HSC disks - HSC failover, if disks are dual-pathed - server failover, if multiple boot nodes exist - Current and future workstation software will be supported RMS o RMS Journaling Merged - Key to enable o Collated Key Support - User-defined collating sequences (multinational keys) - Support through $XABKEY extensions o Indexed File Sequential $GET speedup o RMS Execution Monitoring VAX-8 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures - SET FILE /STATISTICS to enable - MONITOR RMS to watch o Block-or-Record Access Emulation for RMS-11 Partners - COPY to RMS-11 systems now uses block mode o $XABITM General item-list $XAB Supports: - RMS statistics monitoring - DAP link parameters - DAP extended protection fields AUTOGEN o AUTOGEN feedback - Allows user workload to size the system - Affects most memory and page/swap-file-related parameters - VMS continuously maintains usage information and AUTOGEN grabs snapshot - Valid only after "typical workload" has executed DEBUG o Dynamically reformatting REG display. VAX-9 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures o EXAMINE/OPERANDS o MACRO support enhancements o New predefined windows for screen mode o SET MODULE/CALLS o SET MODE SEPARATE o SET PROMPT/[NO]POP o Spawn /INPUT and /OUTPUT o INCOMPATIBLE CHANGES - EVALUATE command now displays value not address for Macro - Screen mode line wrapping in OUT display now at 255 characters - DEBUG separate window control (SET MODE [NO]SEPARATE; SET PROMPT/[NO]POP) o PROBLEMS CORRECTED/RESTRICTIONS REMOVED - SET IMAGE image,image,... now sets all the images - SET SCOPE Command will automatically set modules for you BATCH/PRINT FACILITY o Significantly improve performance through selective restructuring of system queue file to reduce I/O - Replace master pending job list with queue-specific lists VAX-10 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures - Create job entry vector - Improve print job scheduling algorithm o Support access control lists (ACLs) on queues o Add features and flexibility to DCL interface - For SHOW QUEUE provide better selection criteria - New SHOW ENTRY command - New F$GETQUI lexical function o Enhance corresponding programming interface - Add $SNDJBC item codes - Add $GETQUI item/function codes - New LIB$GETQUI library routine New RTL DATE/TIME features, LIB$ facility. o Specify output formats other than the standard VMS format o Specify input formats other than the standard VMS format o Specify input and output formats using languages other than English o Selection of language and formats through logical names or through routine calls o Multiply delta times VAX-11 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures o Convert a VMS internal time to either an integer or a floating point value, based upon a selected unit of time (seconds, minutes, etc.) o Add and subtract VMS internal times o Convert an integer or floating point value to a VMS internal time, based upon a selected unit of time (seconds, minutes, etc.) o Convert a $NUMTIM 7-word array to a VMS internal time Screen Management o SMG$ Viewports - Portion of a virtual display visible on pasteboard - Provides portal onto virtual display that may be moved or resized. o SMG$ Subprocess Support - Method to control subprocesses and I/O via virtual displays - A way to have several concurrent subprocesses, each with own display o SMG$ Menus - General support for many usage modes Block menus (VT2xx SETUP) Vertical menus (aka pull-down) Horizontal menus (aka strip menus) VAX-12 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures - Renditions Selected items, Unselected items - Options Default items, One-use-only items o SMG$ User Renditions o ANSI has many renditions not on DEC terminals: color text, double underline reduced intensity, rapid blink o Method provided in SMG for up to eight programmer defined renditions o Access via rendition-set parameter to output routines LAT o Support for access to two separate Ethernet LANs o $GETDVI returns terminal server and port name for LTAn: o Support for TT$M_BREAK, generates break at terminal server port (DECserver 200) LAT/VMS V4.6 - Possibilities o Full function LTDRIVER, LATCP, and LATSYM now distributed with VMS o LTDRIVER port QIOs - Solicit Connection to Application Device - Get server and port name for LTAn: VAX-13 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures o Multi-threaded print symbiont (LATSYM) - Up to 32 print streams per process DCL/EDITORS/UTILITIES o DCL - IF-THEN-ELSE construct - RECALL/ERASE (erases the recall buffer) o TPU - avoid section file rebuilds - WPS keypad - /START_POSITION qualifier - improved word wrapping o Utilities - Callable mail Rolling Cluster Upgrade o Mixed version cluster - only between adjacent releases - not all new features available - not optimum performance - not a permanent state VAX-14 PAGESWAPPER - July 1987 - Volume 8 Number 12 VMS Futures o Continuous operation - possible with sufficient redundant resources VMS SYSTEM MANAGEMENT o The breadth of VAX/VMS configurations upward and downward has strained the capabilities of the original VMS system management design. o VMS Development is defining a new internal architecture for system management. This architecture will provide a modular base for all system management efforts over the next several releases of the product. o The initial implementation is intended to provide a cluster-wide view for managing VAXclusters. This implementation provides a standard DCL-command line interface. VAX-15 PAGESWAPPER - July 1987 - Volume 8 Number 12 Digital Responds to the Spring 1987 SIR Vote Digital Responds to the Spring 1987 SIR Vote Mark Oakley SIR Coordinator and Nigel Turner VMS Engineering At the Nashville Symposium, Digital responded to the VAX SIG's most recent Software Improvement Request ballot. The ballot was originally published in the January issue of the Pageswapper and the results can be found in the May issue. 364 ballots were returned, a decrease in participation from the previous ballot. Digital remains very committed to the SIR program. Below is a summary of the top 10 items followed by Digital's response, as presented by Nigel Turner, Jake Vannoy, Keith Walls, Jim Krycka, and Bill Robinson. SIR: S87-26 Position: 1 Points: 215 Abstract: Allow command line editing to work on the entire command. Description: Currently, command line editing is limited to the last line displayed on the scope. Frequently, errors are found in the command prior to the last displayable line, especially on long commands. This can be worked around in some cases by setting the line length to 132 or deleting characters until the error is reached. Both of these work-arounds are cumbersome and inelegant. Some change is needed to the command line editor, to allow the full command to be edited. One possibility would be to provide a mode to return to the beginning of the command and step forward a line at a time through the command. Response: This is the most frequently requested terminal driver enhancement and is a very desirable feature. We have considered adding this capability. However, in order to avoid significant degradation of apparent response time, a redesign of the terminal driver is required. There are no current VMS plans for including this feature. VAX-16 PAGESWAPPER - July 1987 - Volume 8 Number 12 Digital Responds to the Spring 1987 SIR Vote SIR: S87-28 Position: 2 Points: 158 Abstract: Provide a mechanism to require a $SET PASSWORD to be automatically invoked on expiration of a user's password. Description: Sites that enforce password expiration and have users locked into captive command procedures to invoke applications such as ALL-IN-1 have a problem when the screen is cleared automatically and the user misses the critical message that the last login permitted has just been made! This results in very frustrated users and system managers. A simple fix to this and many other instances would be a /DEMAND_NEW switch in the authorize file. This switch if set yes would force a $SET PASSWORD to take place during login in lieu of the warning message that the last login had been used. Response: We believe this is one member of a class of problems concerned with account management. We are currently designing ways in which these problems can be solved with a single style of solution. We therefore do not intend to provide this particular "point" solution but, rather, we intend to solve it by better designing the system management interface. SIR: S87-27 Position: 3 Points: 156 Abstract: Provide remote printing of a LOCAL file. Description: Given the power of DECNET it should be possible to provide the queue manager on a remote node with a print command that contained a node name in the file spec. The print symbiont would then utilize the File Access Listener on the source node to read the file in and send it across the network. For example, a user on node IBIS:: would issue the following command: $PRINT/NODE=HAWK/QUEUE=CP01 IBIS::COLOR_TEST.LIS This would result in a print entry placed in the queue on node HAWK that pointed to COLOR_TEST.LIS on node IBIS. Once the linkage is provided for the queue manager to communicate over DECNET many other possibilities quickly become easy. For example: VAX-17 PAGESWAPPER - July 1987 - Volume 8 Number 12 Digital Responds to the Spring 1987 SIR Vote $PRINT/NODE=HAWK/QUEUE=CP01 JAY::CARTOON.TEST Response: We agree that the ability to submit and control remote print jobs through an extension to the current DCL interface would be very convenient and useful. PRINT/REMOTE is clearly a very limited capability that does not copy files, nor does it allow other job-related qualifiers to be passed to the remote system. It is implemented by opening and closing the selected remote file through RMS calls using the "spool on close" option to enter a remote print job. VMS Engineering has seriously considered enhancing the DCL interface as you suggest. However, the current design of the Batch/Print subsystem does not easily lend itself to solving many of the problems faced in implementing a transparent remote printing capability. Remote printing entails much more than a simple extension to the VMS distributed printing capability found in clusters today where there is a shared file system, distributed lock manager, and a single security domain to rely upon. Digital recognizes the need to continue to develop both the distributed and remote printing capabilities of VMS (as well as batch). To this end, we plan to focus on evolving the current print and batch architecture to address current and future requirements in this area. Thus, while future directions of the VMS Batch/Print facility are being assessed, we have no immediate plans to extend the current DCL interface to provide a limited solution to this remote printing problem. SIR: S87-20 Position: 4 Points: 145 Abstract: Provide a separate file "date last read" from "expiration date". Description: VMS provides the ability to maintain a pseudo "date of last access" for files by using a volume-wide file retention period to update an expiration date. It would be desirable to have the ability to maintain the date that a file was last read, as well as maintain an explicit expiration date for a file. Knowing for certain the date and time a file was last read can be an important security tool. The date the file was last read should be separate from the date the file was last created and the date the file was last modified. VAX-18 PAGESWAPPER - July 1987 - Volume 8 Number 12 Digital Responds to the Spring 1987 SIR Vote Response: We have considered this request many times and rejected it on the basis of the certain performance implications. However, we are now seriously considering how we might do this without adversely impacting performance. Most likely, last access date recording will not be the default but will be enabled at some level (volume, directory, file). SIR: S87-77 Position: 5 Points: 133 Abstract: Enhance AUTHORIZE to report on individual fields in UAF records. Description: Currently, AUTHORIZE provides only "brief" or "full" reports. It would be quite useful if fields could be included and/or omitted. For example: UAF> SHOW USER/PRIVILEGE would display just the privileges for the account "USER". Response: In version 4.4 of VMS, we introduced the SYS$GETUAI and the SYS$SETUAI system services. This is the foundation upon which future system management tools will be built in this area. While we have made no decisions about the nature of the user interface, we are giving every consideration to the ease with which VAX/VMS systems can be managed in the future. SIR: S87-71 Position: 6 Points: 130 Abstract: Support BACKUP over DECnet. Description: It would be very useful if files could be backed up to a tape drive that was on another node in the network. The implementation should be concise, and not require the creation of DCL procedures, network objects, etc. Response: We recognize the need for BACKUP to have network capabilities beyond being able to create and read savesets. We plan to provide BACKUP with full access to remote devices, files, and savesets in a future release of VMS. One of the requirements we recognize is that network BACKUP be robust to DECnet or node failure. Neither solution will be engineered in isolation. VAX-19 PAGESWAPPER - July 1987 - Volume 8 Number 12 Digital Responds to the Spring 1987 SIR Vote SIR: S87-1 Position: 7 Points: 119 Abstract: Provide additional VAXcluster management tools. Description: Digital stresses that a VAXcluster should be managed as a single domain. To do this, more cluster-wide system management tools need to be implemented. For example, SHOW, SET, ACCOUNTING, etc. should be enhanced to work across the entire cluster ( as in MONITOR CLUSTER). Perhaps a DCL TELL command (similar to the DECnet NCP TELL command) should be implemented. Response: Digital recognizes the "systemness" exhibited by VAXclusters to end users has to date not been seen by the system manager as much as we would like. Although at a low enough level, the system manager will always have to deal with individual nodes for installation and configuration purposes, Digital intends to supply utilities to allow most day-to-day system management operations to be effected cluster-wide without the need to login to every node. This capability is being developed for a future release of VMS. SIR: S87-51 Position: 8 Points: 108 Abstract: Ability to stop a running process and store all data to disk so that it could be restarted after a system boot. Description: The following capabilities need to be in VMS: 1. A VMS command to suspend and outswap a process and store any related info (such as open files) 2. A VMS command to restart the process, reopening files etc. 3. A startup procedure to restart outstanding processes on reboot. Response: Digital recognizes the need to provide some mechanism to protect customers' computing investment in long running jobs. The functionality described in this SIR is similar to that proposed some time ago for the Checkpoint/Restart project, one major difference being that the proposed solution would have required some amount of application programming. Unfortunately, that project was not completed. Checkpointing a running job is very hard to do. VAX-20 PAGESWAPPER - July 1987 - Volume 8 Number 12 Digital Responds to the Spring 1987 SIR Vote It is especially hard to do in the general case. The entire process context is much more than memory and register contents. As recognized in the SIR, open files, accounting information, etc. have to be saved, and subsequently restored. It's the "et cetera" that is hard to do, maybe close to impossible in a cluster and network environment. We now feel that with the advent of VAXclusters, our computing model has changed to such an extent that this is no longer the right technical solution to the problem for the majority of our customers in the new environment. Today, we believe that the most pressing need that our customers have is for the ability to build applications in a VAXcluster environment that can survive individual CPU and mass storage subsystem failures. Our policy is therefore to consider the introduction of system features that will allow our customers to design and build highly distributed applications. The needs of customers with very long running jobs will be considered as part of this effort, but any solution will look very different from our previous designs and will require application programming. SIR: S87-57 Position: 9 Points: 104 Abstract: Support ACL's on print and batch queues. Description: ACL's are needed to control the usage of print devices, print queues, and batch queues. The UIC-based protections are now available on queues, but ACL's are not, so the system manager does not have sufficient granularity in granting access to the system queues and print devices. There are some system managers who would like to set up batch or print queues that could only be accessed by users holding a particular identifier. ACL's can be placed on physical devices, but they control only the ability of users to allocate the devices and do not control their ability to use shared devices such as printers. Response: Development is currently under way to support access control lists (ACLs) on batch and print queues. We expect to provide this capability in a future major release of VMS. VAX-21 PAGESWAPPER - July 1987 - Volume 8 Number 12 Digital Responds to the Spring 1987 SIR Vote SIR: S87-56 Position: 10 Points: 99 Abstract: TPU should display all special characters. Description: Most special characters are not appropriately displayed by TPU. It is useful, and sometimes necessary, to know what characters are actually in a file. TPU should be modified to display special characters. Response: TPU deliberately does not provide for the display of characters that aren't available in the terminal. Displaying them as "fat characters", as EDT does, would be a severe performance hit. It would also complicate the cursor movement routines of editors based on TPU, since characters would no longer be a single cell wide. The only exception to this rule is the TAB character. TPU will automatically fill a tab with spaces if the user types "within" a TAB. This would not be possible with a multiple character representation of a special character. VAX-22 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot Fall 1987 VAX System Improvement Request Ballot Mark Oakley HOLD IT! DON'T PUT THIS OFF! THE DEADLINE IS OCTOBER 30. You have an opinion about what is right or wrong with the VAX. Here is your chance to influence the directions of future DEC development. The VAX Systems SIG System Improvement Request (SIR) program is an important method for the VAX user community to provide input to Digital. Your opinion is important, and every ballot adds to the influence of the SIR program. Participation on the Spring 1987 ballot dropped to 365 voters. Pageswapper circulation exceeds 7000 issues, and each issue is read by several users. Please take the time to vote. I really want to hear from you! On the following pages, you will find the current collection of System Improvement Requests. Please take the time to review these SIR's and assess their effect on your use of VAXes. Then indicate your preferences as described below. THE SIR BALLOT FORM APPEARS IN THE "QUESTIONNAIRE" SECTION OF THIS NEWSLETTER. Also, please fill out the questionnaire portion of the ballot. This information is important to DEC, as it points out which requests are important to a particular segment of the VAX community. Occasionally there is some confusion about the ballot. You can only vote for the SIR's that are listed below. Please provide your six-digit DECUS membership number. (If you subscribe to the DECUS U.S. CHAPTER SIG NEWSLETTER, then your membership number is the first six digits of the twelve-digit number on the mailing address.) If you are a non-US DECUS member, please provide your full membership number. The returns from this ballot will be totalled, and Digital will provide a formal response to the 10 items which receive the most votes. The results and DEC's responses will be given at the VAX SYSTEM SIG SYSTEM IMPROVEMENT REQUESTS session of the Fall 1987 DECUS Symposium in Anaheim. Instructions For Voting The ballot form contains two sections, a "support" section and an "oppose" section. To indicate your support for an SIR, enter VAX-23 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot its number in the "support" section of the ballot. You may list from zero to fifteen SIR's in this section. To indicate your opposition to an SIR you consider detrimental, enter its number in the "oppose" section. You may list from zero to five SIR's in this section. Please return your ballot IMMEDIATELY. To allow time for DEC to respond, BALLOTS RECEIVED AFTER OCTOBER 30 CANNOT BE COUNTED. Any ballot not specifying a DECUS membership number will not be counted. Only one ballot per member will be accepted. VAX-24 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot Clusters SIR: F87-1 Abstract: Improve support for VAXclusters with homogenous system disks but heterogeneous user groups. Description: For VAXes booted in a homogenous VAXcluster increased capability and standardization is needed to prevent users from logging in to all VAXes. Because individual VAXes in a cluster may be "owned" by different groups/departments/people, a method is needed to restrict which VAX(s) a user can access. This would dispense with the management problems of heterogenous System Authorization Files and ad-hoc schemes to lockout users from individual VAXcluster nodes. This problem is particularly applicable to Local Area VAXclusters where the cost of ownership is low and the "owner" factor is high. SIR: F87-2 Abstract: Implement cluster-accessible tape drives. Description: Tape drives connected to individual VAXes in a VAXcluster should be usable by all nodes of the cluster. For VAXcluster configurations, the ability to use a tape drive local to another VAX would be very beneficial. Because Local Area VAXclusters cannot have tapes on HSC's, a tape drive has to be configured on every VAXcluster node or the process accessing the tape drive must be on the VAX with the tape drive. Other configurations with only local tape drives would also benefit. VAX-25 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-3 Abstract: Eliminate the requirement for VAX 11/750s to boot from a TU-58. Description: VAX 11/750s in a VAXcluster should be able to boot from a local system disk without using the TU-58 console tape. VAX 11/750s in a VAXcluster must currently boot from the TU-58 console if an HSC disk is used for the system. This is because the CI750.BIN file must be loaded before accessing the CI. This should not be a requirement for VAX 11/750s that are in a VAXcluster and booting from a local system disk. SIR: F87-4 Abstract: Provide high-speed communication services on a VAXcluster using SCS, not DECnet. Description: Communication services between VAXcluster nodes is currently limited to DECnet or file sharing schemes. Digital should implement a communication interface (device driver) that uses the System Communication Services (SCS) to provide high speed data transfer between VAXcluster nodes. This would assist individual sites implementing cluster-shareable devices. Commercial SIR: F87-5 Abstract: Allow Datatrieve to accept abbreviated commands. Description: Datatrieve is a powerful tool which can be difficult to use, because it can not process abbreviated commands, i.e. "SHOW DICTIONARY", instead of "SH DICT". The synonym feature is inadequate because it requires pre-cognition or considerable work to build the synonyms. VAX-26 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-6 Abstract: Increase the completeness, accuracy, and level of detail in VMS accounting records. Description: Examples include the following: 1. Stock name for print jobs 2. Physical device name(s) for virtual and LAT terminal sessions 3. QIO counts, by device, for each ALLOCATED device and each SHARED device. 4. Report the terminal maximum speed (larger of TRANSMIT and RECEIVE) 5. Record the number of logical and physical mounts for each tape and disk drive (if any) 6. Record the name of the queue a job was submitted to as well as the device or specific queue it executed on. 7. Record queue name for subprocesses created by batch jobs. SIR: F87-7 Abstract: Provide support for spooled output to terminal auxiliary printer ports (so that printer output can be interleaved with screen and keyboard I/O). Description: This facility must provide configurability of: 1. Device-independent I/O at driver characteristic level 2. Same level of support as a "normal" printer 3. Terminal driver should know how to "turn on" the printer, and should be able to interleave I/O VAX-27 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot 4. The sphere of influence of this capability is "process-local" as opposed to system-wide SIR: F87-8 Abstract: VMS Mount services should include "For READ" or "For WRITE" or "WITH RING" or "WITHOUT RING" in messages to the operator when requesting a tape be mounted. Description: MOUNT/NOWRITE should generate a request for "WITHOUT RING" or "For READ ONLY" and MOUNT/WRITE the opposite so that operators can quickly determine what is needed. SIR: F87-9 Abstract: Provide a fast file scan. Description: The CONVERT utility can scan through an RMS ISAM file at lightning speed. It would be helpful in many instances to have a utility with a callable interface that would provide a high speed scan capability. This capability would be satisfactory with a random record order, but it must execute quickly. To avoid locking at the record level, the scan could be granted exclusive access to the whole file. This scan capability would be useful for building sub-datafiles from large ones (for Datatrieve) and for standard financial batch jobs such as bill/report generation. SIR: F87-10 Abstract: Provide a callable interface to the operator messaging services that permits query calls to OPCOM or its replacement. VAX-28 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot Description: The current OPCOM interfaces are inadequate for a commercial environment with lots of tape mounts and other requests coming up on cluster consoles. In order to improve on what exists, it would be helpful to have a mechanism to ask OPCOM for outstanding requests of a particular or a subset of operator classes. This would lend to the building of an interactive request management tool which would run on a video or hardcopy terminal. Pending forms should generate requests to PRINTER operators so that this mechanism will cover 99% of the requests an operator needs to handle. Any functionality that crosses the boundaries of SYS$SNDJBC and SYS$SNDOPR should be consistent between them. If this is not possible due to compatability problems, invent a new call that will complement and/or eventually replace these. SIR: F87-11 Abstract: Enhance the ALLOCATE services to allow requests to be queued. Description: Enhance the ALLOCATE services to enable a user optionally to queue the allocation request when all qualifying devices are busy. Device allocation should be handled by a queue manager similar to the VMS V4.0 print queue manager, and the allocation request queues should be made cluster-wide to support cluster-visible devices. User functions should include the ability to specify characteristics required of a generic device, the automatic notification of allocation, the ability to delete an allocation request, the ability to examine the allocation request queue, and the ability to do other interactive processing while waiting for an allocation request to be granted. Operator functions should include the ability to mark failing devices as unavailable and the ability to force a deallocate. Manager functions should include the ability to define device characteristics and specify physical devices as possessing those characteristics. Device allocation and deallocation should place records in the accounting file so that charge back accounting can be done for allocated devices. VAX-29 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot A mechanism for avoiding deadlocks when multiple devices are allocated should be provided. Examples: $ ALLOCATE/QUEUED/WAIT TAPE$CLASS:- /CHARACTERISTICS=(DENSITY:6250) LOGICAL_TAPE (Queue an allocation request for a tape drive with 6250 bpi capability and wait until the allocation has completed.) $ ALLOCATE/QUEUED/NOWAIT/NOTIFY DISK$CLASS:- /CHARACTERISTICS=(RA60) MY_DISK_PACK (Queue an allocation request for an RA60 disk drive and return control to my terminal. Notify me when the allocation has completed.) $ ALLOCATE/NOQUEUED TERMINAL$CLASS:- /CHAR=(AUTODIAL,BAUD:1200) DIAL_OUT_MODEM (Allocate a terminal device with a 1200 baud autodial modem but don't queue the request. Give an error if all such devices are allocated.) The queueing capability might be implemented via a symbiont. The queueing capability should also be provided for the MOUNT services. SIR: F87-12 Abstract: VMS should implement tape automatic volume recognition and provide the security normally associated with volume labeling. Description: VMS should provide a complete implementation of automatic volume recognition (AVR) for tapes, that may be enabled/disabled by the operator on a per drive basis. This means that (with AVR enabled), when a tape is mounted, the system checks possible labels and honors mount requests without operator intervention, if possible. If a job needs 4 tapes, the operator can mount them all if enough drives are available and then forget about them until somebody else needs the tape drives. It should also be possible for a user to request a tape mount based solely on the tape's label and density. The user should not be required to know what physical devices implement a particular tape density VAX-30 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot on a particular system. VMS should also support a "visual id" or "slot number" which is displayed in all operator messages related to the mount. It should be possible to operate a VMS system in a mode where all tapes are under system/operator control. This means that they are pre-initialized and users are not allowed to change the labeling on the tape without special privilege. The BACKUP utility must also conform to such labeling restrictions, thereby insuring that the BACKUP data is written onto the proper reels. VMS should require explicit operator intervention for unlabeled tapes. It is not acceptable that an unlabeled tape which happens to be on a drive be automatically assigned. SIR: F87-13 Abstract: All utilities should use a standard format for printable output. Description: Printable output generated by VAX utilities and compilers comes in a great variety of record formats and carriage control conventions. A particularly awkward convention is the use of embedded ASCII control characters to generate multiple print lines from a single record. There appears to be no standard for this or any other mechanism. As a result it is very difficult to print "printable" output on non-DEC printers or transmit it through heterogeneous networks. Digital should document a standard record format and carriage control convention and modify all facilities to conform to this convention. As an alternative, Digital should provide a utility which converts all currently used formats into a standard format. It seems that this functionality currently exists, distributed between the print symbiont, device driver, and "DEC standard" printers. VAX-31 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-14 Abstract: Provide support for simple project accounting. Description: The Spring 1985 VAX SIR Ballot contained a request for project accounting in VMS. Digital's response was "We also feel that project accounting is very important...We feel that this is a reasonably complex area and, as such, some of the enhancements that we intend to make in this area will appear over time." Project accounting is something that is desperately needed at large sites. In its simplest form, project accounting should provide a SET PROJECT command that would write a process accounting record, and start recording a new record with a new account string specified by the user. The account string should be verified before these actions take place. The system manager should be allowed to set up a file which specifies which UIC's are permitted to use individual account strings. Many sites have immediate government or internal security requirements for "one username per user" level of accountability. DEC should provide this form of project accounting until their full-blown system is available. SIR: F87-15 Abstract: Enhance BACKUP to provide first and last file names logged for each volume of storage media and an incremental restore capability for a directory structure. Description: BACKUP should log the first and last file on each volume to assist in choosing tapes for restoration. Directories or entire directory trees sometimes become unusable. To aid in recovery, BACKUP should support the following procedure: 1. Delete the structure(s) affected. VAX-32 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot 2. Restore that structure from the last image mode backup. 3. Restore the selected structure(s) in incremental mode. DCL and Utilities SIR: F87-16 Abstract: DCL WRITE command needs a method for terminating a write operation without generating a CR/LF sequence. Description: When using the DCL write statement, there currently is no method to terminate the operation and prevent the CR/LF sequence. This would be useful when positioning the cursor on the display to a particular location, such as a default response indicator or fixed response location. Any subsequent read operation performed from the terminal would need to process any type-ahead text properly as well as normal response characters not typed ahead. SIR: F87-17 Abstract: More capabilities for VAX-11 RSX BRU. Description: VAX-11 BRU would be more convenient to use for interchanging files between RSX systems and VMS systems if the VAX-11 BRU were enhanced to know enough of ODS-2 structures to allow access to rooted directories. This feature would permit reading or writing of the rooted portion of the directory tree as if it were the [0,0] directory of the device as BRU sees it. VAX-33 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-18 Abstract: Enhanced command line RECALL capabilities. Description: The functionality of the command line RECALL facility would be greatly increased if users were able to tailor some features to their specific needs. It would be desirable if these (YES FOLKS we are asking for still more SYSGEN parameters) features could be set on a user-by-user basis, but site by site at boot time would be ok. The expansion tailoring would allow sites to set: 1. The size in bytes of the command line recall buffer. 2. The maximum number of commands to be recalled. 3. The size of the DCL command line expansion area. 4. The size of the DCL command input area. This would allow larger commands to be passed to user-written programs by the foreign command interface processor. SIR: F87-19 Abstract: Add more capabilities for manipulating DCLTABLES Description: Many users desire or need to modify DCLTABLES to restrict access to certain commands, command options or add their own or third party software as a DCL command. Some form of support to facilitate this is needed, even an extra cost layered product. A minimal form of support would be a listing program that would produce readable output to allow the user to: 1. Check conflicts in names. 2. Verify options. 3. Determine if the command was added, when it was added, and if it is from VMS. VAX-34 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-20 Abstract: DCL status return enhancements. Description: Programs that are called by DCL should implement some form of expanded status reporting that is testable at the DCL command level. For example if DIFFERENCES were invoked, some indication in $STATUS if the files were the same or differences were found, would permit users to act accordingly. For example: $DIFFERENCE F1.TXT F2.TXT $IF $STATUS .EQ. DCL$DIF_NONE THEN $DELETE F2.TXT Some form of documentation would be needed to allow users to write appropriate tests. The return values could be defined either by numeric returns or reserved symbols known to DCL. SIR: F87-21 Abstract: Enhance SET HOST error reporting. Description: The DCL trapping of CONTROL_Y within the SET HOST command and the current exit processing of a yes response to the question: Are you repeating CONTROL_Y to abort the remote session... fails to indicate that the SET HOST connection was aborted. Some indication of failure to log off normally would aid in processing errors or performing any needed cleanup. SIR: F87-22 Abstract: Add the ability to run a detached process for a specified user name. Description: The ability to run a detached process under a specified user name for a suitably privileged user would provide the ability to do this directly. A technique of putting the run command in a command procedure and doing a SUBMIT/USER= works but may require additional work to get VAX-35 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot the job to the start of a batch queue or even require the creation of a batch queue. SIR: F87-23 Abstract: Make the DCL /LOG qualifier more consistent. Description: Some commands (Backup, Copy, etc.) accept /LOG, others such as (Print, Submit) use /IDENTIFY to produce documentary output. These commands should all support the /LOG or some new qualifier, /DOCUMENT for example, that would produce documentary output. This new qualifier would be consistent across all commands and ignored on commands that can produce documentary output such as SHOW TIME. SIR: F87-24 Abstract: Add the capability to capture an interactive session exactly as it happens. Description: In many cases VMS users need to produce a disk file with the transcript of a terminal session. The need for this is to produce documentation for manuals, turn in as homework for class, or to submit an SPR. The SET HOST/LOG does not completely emulate the terminal output, especially when CR/LF output is suppressed to allow the user to respond to a question on the same line. Also if the SET HOST command has been removed for a user this feature becomes nonexistent. Some command such as SET LOGGING TO is needed to provide this feature. The UNIX script utility would provide a good model for this. Obviously if the captured file contained graphics escape sequences or other non-printable characters it would be the user's responsibility to handle them. The ability to record escape sequences into a file might also be a useful debugging tool for some users. VAX-36 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-25 Abstract: Enhance sysgen parameter readability. Description: SYSGEN would be more useful if it were modified to provide a better organization of parameters, e.g., memory, terminal, timing, security, VMS mystery, etc. Sorting the output into alphabetic order would also make finding the parameter value in the listings easier. SIR: F87-26 Abstract: Enhance VMSMail. Description: VMSMail should be enhanced in the following ways: 1. Allow a user to retract a sent mail message. This could be limited to the last message sent. This would be very useful to retract that nasty undelivered mail message sent to the SYSTEM MANAGER before it is read and you end up with mandatory 32 character one time passwords! 2. Provide a facility to append comments to a received mail message and redistribute it. 3. Provide some form of return receipt when the recipient has read your mail message. 4. Provide a facility to allow users to configure the default printer orientation for printed mail messages. Most mail messages are oriented to portrait mode, and not the default landscape mode found on most programmers' printers. 5. DEFINE/KEY in mail should support /ERASE in the same way that the DCL DEFINE/KEY does. VAX-37 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-27 Abstract: Enhance SET HOST/DTE for more modems including those made by Digital. Description: The Digital DF224 modem is not compatible with SET HOST/DTE/ DIAL=NUMBER. Support is needed for all modern DEC modems. Support for popular third party modems such as HAYES, RACAL-VADIC, etc. would be desired. SIR: F87-28 Abstract: Enhance SHOW PROCESS command to display open files and information about subprocesses. Description: Some form of identification is needed for the SHOW PROCESS command to make tracing subprocess trees easier, possibly of the form SHOW PROCESS/SUBPROCESS/ID=. If a user has two processes running in a batch queue or even from two terminals, and each process has a subprocess it is very difficult to determine which subprocess is owned by which parent. The ability to show the files that a specified process has open is needed. SHOW DEVICE/FILES on one-drive systems with many installed images provides too much output. If this feature could also show the current location within each file, then estimating what portion of a file had been processed by a program would be significantly easier. SIR: F87-29 Abstract: Enhance MOUNT/FOREIGN for uninitialized tapes. Description: The MOUNT/FOREIGN command will time out and not complete properly on a VIRGIN BLANK tape. Some fix to avoid failing on a blank tape is needed. VAX-38 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-30 Abstract: Enhanced DEFINE/KEY capabilities. Description: DEFINE/KEY should support control characters and escape sequences, and allow multiple input lines to be defined with the extra lines being placed into the type-ahead buffer. For example: $! !Customize keyboard $DEFINE/KEY KP2 "^E" !EDT go to end of line $DEFINE/KEY comma "" !EDT delete char at cursor $! !MULTIPLE INPUTS $DEFINE/KEY PF4 "^B^H" !Recall and edit command $DEFINE/KEY KP3 "MAILDIRECTORY NEW MAIL" SIR: F87-31 Abstract: Add a /BELL qualifier to certain DCL commands. Description: The addition of a /BELL=n qualifier command to DCL to cause the terminal bell to ring N times with a discernable pause would be very useful to draw attention to the terminal when a long running command completes in any fashion. SIR: F87-32 Abstract: Restore CONTROL_U behavior to pre-V4 status. Description: The CONTROL_U sequence in V4 fails to provide feedback when the terminal is set /LOCALECHO. This is inconsistent with the other control sequences (^B,^C,^O,^Q,^R,^S,^T,^Y,^Z) all of which provide user feedback. Prior to V4 the ^U sequence both cleared the terminal input buffer and generated a new line/prompt sequence to the terminal. In V4 only the input buffer is cleared which is the expected behavior if the terminal is set /NOECHO/NOLOCAL_ECHO. Given that users of V4 and up may now want this behavior, an additional switch such as /OLD_LOCAL_ECHO would be a way to allow a choice in how the terminal should behave. This request is specifically a request to restore the behavior in /LOCAL_ECHO to what it VAX-39 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot was prior to V4 and make no changes to the /ECHO and /NOECHO/NOLOCAL_ECHO behavior. SIR: F87-33 Abstract: Enhance the DCL DEFINE command. Description: The DEFINE command should be enhanced in the following area: 1. All features of the ASSIGN command should be provided in the DEFINE command. 2. Because there is a DEASSIGN command to negate the effect of the ASSIGN command, there should be an UNDEFINE command to negate the effect of the DEFINE command. 3. In the DCL documentation, related topics should be listed for each command. The DEASSIGN command should be mentioned in the documentation about DEFINE. SIR: F87-34 Abstract: The functionality of the DEFINE and ASSIGN commands should be in a single command. Description: It is confusing to have two DCL commands that perform similar functions. One of the commands should be eliminated and lost functionality transferred to the command that is retained. It would be helpful if some procedure were supplied that would aid with this conversion, as many command procedures would require modification. VAX-40 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot Internals SIR: F87-35 Abstract: Implement a system service equivalent to the lexical function F$FILE_ATTRIBUTES. Description: Although information delivered by F$FILE_ATTRIBUTES can be obtained via System Services, this is tedious since various RMS data structures have to be established. A direct System Service would be valuable and should not be hard to implement since the code is already there. SIR: F87-36 Abstract: Images that are linked on VMS Version "4+n" systems, need to execute on Version 4 systems. Description: Sites that export software to customers are not able to upgrade quickly to new releases of VMS because not all customers have upgraded. There needs to be a way for software that is linked on a "4+n" version of VMS to execute on a version 4. SIR: F87-37 Abstract: Provide "wildcard" support for the SYS$TRNLNM system service. Description: From DCL it is easy to display all of the logical names in one or more logical name tables. This capability does not exist at the programming level. The SYS$TRNLNM system service should be enhanced to provide "wildcard" support to provide this functionality. VAX-41 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-38 Abstract: Provide synonym node names for ACP QIO (non-transparent) DECnet operations. Description: DECnet-RSX provides the ability to define synonyms for actual node names. When such a name is specified in a network connect, that name is translated and the resultant name used as the target of the connection. A synonym node name capability under VMS offering the same functionality as DECnet-RSX is needed. SIR: F87-39 Abstract: Provide explicit control over all caches when a disk is mounted. Description: Disk-cache control is needed to support mounting dual ported disks read/write on one system and read only on another. It would also allow better tailoring of cache sizes to activity on the individual disks. SIR: F87-40 Abstract: "New Mail" notification on login should work for all layered electronic mail systems. Description: VMS should provide a mechanism that allows layered electronic mail systems to notify a user of new mail at login time. Currently, a user has to activate the layered electronic mail system to determine if there is new mail. SIR: F87-41 Abstract: Implement higher speed terminal baud rates (e.g. 38400 and 14400) VAX-42 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot Description: Many graphics applications produce complex images. These application would execute more quickly if higher baud rates were available. Various hardware vendors support higher baud rates, and Digital's DHU-11 supports 38400, but the DCL command SET TERMINAL/SPEED does not. It would be also useful if baud rates between 38400 and 14400 were available. SIR: F87-42 Abstract: SYSGEN should provide a DISCONNECT command to cancel the effect of a CONNECT command. Description: It is very inconvenient to have to reboot the system to get rid of a device. The capability to remove a device should be added to the SYSGEN utility. Languages, Tools, and Editors SIR: F87-43 Abstract: The capability to specify "footers" should be added to RUNOFF. Description: Currently, RUNOFF has the capability to put one or two lines of text at the top of every page, via the .TITLE and .SUBTITLE directives. However, there is no capability to put text at the bottom of every page. It would be useful if such a capability existed. SIR: F87-44 Abstract: Add a sorting capability to VMS text editors. VAX-43 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot Description: It would be useful if a sorting capability was available in the various VMS text editors. Currently, it is necessary to exit the editor to perform a sort. It would be desirable if the syntax of an editor sort command could be similar to the DCL SORT command. SIR: F87-45 Abstract: Provide a routine to return message text corresponding to the Fortran I/O status specifier "IOSTAT". Description: It would be very useful to have a routine that would return the message text that corresponds to the Fortran I/O status specifier "IOSTAT". SIR: F87-46 Abstract: Standardize data-type support for VAX/VMS high-level languages. Description: VAX/VMS high-level languages do not all support the same data types. As a result, access to data is difficult across different languages. For example, a Cobol variable with 10 digits and 2 decimal places can not be manipulated in a BASIC subroutine. A similar problem exists for some record definitions in the Common Data Dictionary. SIR: F87-47 Abstract: Make the "TRUE" value of a Fortran logical variable consistent between Fortran and the debugger. Description: Executing the following Fortran statement causes a value of -1 to be stored in the logical variable: LV = .TRUE. Executing the following debugger statement causes a value of +1 to be stored in the logical variable: VAX-44 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot DEPOSIT LV = .TRUE. The Fortran expression: LV .EQ. .TRUE. will evaluate to false if the debugger is used to deposit a "TRUE" value. Either Fortran or the debugger should be altered to provide consistent results. SIR: F87-48 Abstract: Enhance CMS to support wildcard element-expressions for elements in a group. Description: Currently, CMS supports wildcard element-expressions in the CMS SHOW statement only if the element-expression is not a group name. It would be convenient if wildcards could be used when listing elements of a group. The syntax might look something like: CMS SHOW ELEMENT group:*.typ SIR: F87-49 Abstract: Enhance the alphabet of LIB$TPARSE to recognize high-level-language constants. Description: It would be convenient if high-level-language constants (e.g. floating point, complex, logical, etc.) were recognized by LIB$TPARSE. It would also be desirable if LIB$TPARSE supported user-defined entries in the alphabet. VAX-45 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-50 Abstract: Enhance the symbolic debugger to provide traceback information on COBOL PERFORM statements. Description: Currently, the symbolic debugger provides traceback information about CALL statements, but not PERFORM statements, in COBOL programs. Traceback information about PERFORM statements would be very useful for debugging programs. This traceback information should also be provided when a COBOL program aborts. SIR: F87-51 Abstract: Provide line number support for VAX Macro, that can be used by the symbolic debugger, PCA, LSE, and other utilities. Description: The usefulness of various utilities is limited because VAX Macro does not provide line number support. PCA (Performance Coverage Analyzer) is severely limited because program locations must be specified as virtual addresses. Thus, coverage and other code-related measurements are not useful. Debugging would be made easier if line numbers could be specified, instead of cryptic-looking addresses. SIR: F87-52 Abstract: TPU should display all special characters. Description: Most special characters are not appropriately displayed by TPU. It is useful, and sometimes necessary, to know what characters are actually in a file. TPU should be modified to display special characters. Digital is reluctant to implement this feature, claiming that performance and speed would be sacrificed. If so, then this feature could be an option that could be selected via a switch on TPU or SET directive in TPU, or both. VAX-46 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-53 Abstract: Add a /NOWAIT switch for TPU. Description: If TPU had a /NOWAIT switch that could be set when "DCL" commands were issued to be run by TPU, the user could continue with work in TPU while the "DCL" command continued to run in the sub-process. When the sub-process terminated TPU would inform the user of this in some fashion. No more than one "DCL" command running in this mode would be an acceptable restriction as well as requiring a terminal that could have a reserved scrolling region for the message from the "DCL" command to show up in. Miscellaneous SIR: F87-54 Abstract: There should be more Digital developers at DECUS Symposia. Description: With the enormous increase in VAX software provided by Digital over the years, there is an accompanying complexity. The limited number of software developers who are sent to Symposia try valiantly to "cover" for software which is not their own, but it is difficult. Since DECUS symposia are the only way for the user community to engage in a dialog with Digital software developers, there should be a considerable increase in the number of developers who are sent. This could be done by reducing the number of marketeers who are not able to provide technical details. The Exhibit Hall could also be reduced to exclude "seen-before" hardware. VAX-47 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-55 Abstract: Digital should provide Sales Updates for customers. Description: Digital should provide (even at a price) subscription service to the new product offerings in the "Sales Update". Other vehicles, including waiting for the "Consultants Reference Guide" and the DEC field offices to relay technical information, are unsatisfactory. Security SIR: F87-56 Abstract: Better control over DECnet remote file access. Description: The RMS file protection defines WORLD access to include all those outside the owner's group. It would be useful to define several classes of users as follows: 1. All WORLD users on the local node. 2. All users local to this VAXcluster. 3. All users on nodes within this DECnet area. LOGINOUT currently gives a process the Identifier "NETWORK" if that process is being created in response to a network request. It would be useful to have greater granularity of access control for network processes by having additional identifiers created based on the node, cluster, and area from which the access is being attempted. This capability might possibly be achieved by having the File Access Listener, LOGINOUT, or some other privileged image set up the additional process Identifiers. VAX-48 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-57 Abstract: Support secondary passwords in DECnet access control strings. Description: VMS V4 allows user accounts to have two passwords. However, DECnet does not allow the secondary passwords to be used in access control strings. The only way such accounts can be used through DECnet is via proxy logins. SIR: F87-58 Abstract: Enhance COPY to copy ACL's. Description: The COPY utility does not currently handle ACL's. It should be enhanced to propagate any ACL's from the source file to the destination file. However, there may be many times when a user is copying another user's file in order to modify it for his/her own purpose. It is likely that in such cases the user would not want to propagate ACL's from the original file. Therefore, this capability should be available via an additional qualifier to COPY, e.g., /PROPAGATE. SIR: F87-59 Abstract: A mechanism is needed that allows one user to grant other users access to a file only via a user-defined image. Description: Non-privileged users sometimes need to give other non-privileged users controlled access to data files through a program. Through this facility any user would be able to control who could access his data files and what kind of access they may have. In the current system, in order to allow another user to add a record to a file, that user must be given WRITE access to that file, which means he could alter existing data or delete records from the file. Presently this requires the system manager to install the program with privilege, which is both an administrative nuisance and a security problem, as the privileged image would also have access to other system data files as well VAX-49 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot as the intended files. This mechanism should be under user control, i.e., the user should be able to determine which images could access a file. For example, the UIC of the image and data file could be required to match before access would be permitted. This could be accomplished by an option on the compiler or linker when the image was being created. It could also be implemented by allowing the system manager to install an image with a particular identifier. Then the user could set up the access control list for that file to permit access by that Identifier. This would be less flexible but would permit a user to allow access from images other than his own, e.g., a data base manager. This capability could also be provided by file passwords, since the passwords could be imbedded in the programs that were intended to have access to the files; however, file passwords would be difficult to administer and prone to disclosure. SIR: F87-60 Abstract: Implement mandatory security controls in VMS. Description: Many VAX systems are being operated by government agencies or contractors and either are processing or need to process classified data. Mandatory security controls are needed in VMS to support such classified processing. An operating system that could be evaluated by the National Computer Security Center at the B1 level or higher would encourage more sites to use VAXes for classified processing and make system management much easier for those already doing classified processing on existing systems. The system manager should be able to specify a security level for each user account using the AUTHORIZE utility. When a file is created, it should be given the security level of the creating process, and any subsequent access to the file should be controlled in accordance with the mandatory security policies. If a file is edited or copied, it should retain its classification. A utility should be provided to allow a person with a special (SECURITY) privilege to change the classification of a file. VAX-50 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-61 Abstract: End-to-end encryption of logical connections within DECnet-VAX. Description: The assumption made by DECnet that all nodes and communications paths are trustworthy is not viable in many environments. End-to-end encryption of the data portion of network packets is required in these environments to assure that eavesdropping is fruitless, both in Local Area Networks (broadcast) and Wide Area Networks (multi-hop). This encryption should be implemented so as to be transparent to the application programmer and user. I.e., the mechanism should be located in the NSP (or OSI session) layer. New encryption keys should be generated for each logical connection between cooperating, encryption-capable processors. (Some nodes will not be capable of encryption and should be allowed to participate in the network without performing encryption.) Intermediate nodes should not be required to participate in, or be knowledgeable of, the key distribution/management or the encryption process. The DES algorithm should be utilized in the near term but should be readily replaced as NBS standards change. Provisions should be made for encryption hardware to boost performance where necessary. SIR: F87-62 Abstract: Security alarm messages to a file. Description: Add an option to the Access Control Entries (ACE's) that specifies a file into which security alarms for that file/directory are written. This would allow a user to review security alarms for his own files, rather than depending on the system manager to perform the auditing. Of course, security alarms requested by the system manager via the SET AUDIT command should be written to the system-wide security log. VAX-51 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-63 Abstract: Support DECnet proxy access for SET HOST command Description: When a user logs into a remote host via the SET HOST command and a DECnet proxy exists in the NETUAF on that host, the user should have the option of being automatically logged into that proxy account. This would be extremely helpful to less-advanced users who switch frequently between systems. It would also reduce the chances of disclosing user passwords, since they would not be transmitted across the network if the proxy were used. A /PROXY qualifier could be added to the SET HOST command to allow the user to request proxy access. SIR: F87-64 Abstract: Provide lexical function for getting RIGHTSLIST information Description: An F$RIGHTS lexical function should be provided to return the list of identifiers held by a user (similar to SYS$FIND_HELD). Also, an F$ACCESS should be provided to return a boolean logical value indicating whether access to an object is allowed given an input rights list. SIR: F87-65 Abstract: Allow a general identifier to be the owner of a process. Description: It should be possible to make a general identifier the owner of a process (in place of a UIC), so that: 1. Owner access will be granted via the protection mask to objects owned by that identifier 2. RMS scratch files will be owned by that identifier and charged against its disk quota. VAX-52 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot System Management SIR: F87-66 Abstract: Stand-alone BACKUP should be supported on a greater variety of devices. Description: It would be convenient if Stand-alone BACKUP could be booted from RX02 and tape drive units. RX02 drives are faster than RX01 drives, can hold two floppies, and can operate at double density. Stand-alone BACKUP would boot much faster from the RX02. Currently, Stand-alone BACKUP can be booted from the TK50 and TU58. It seems that this capability could be extended to other non-random access devices (TU78, TU81, etc.). Such a capability might be an attractive alternative to the TU58 and other slow devices. SIR: F87-67 Abstract: Enhance AUTHORIZE to work on a selection or subset of all users according to selection criteria. Subsequent commands should apply to these criteria. Description: It would be useful to construct a subset of all users and have AUTHORIZE operate only on this subset. This feature might look like: UAF> SELECT * /ACCOUNT = PROJECT1 UAF> MODIFY * /SELECTION /WSQUOTA = 1000 UAF> LIST * /SELECTION UAF> . UAF> . UAF> . UAF> SELECT * /((ENQLM < 20) .AND. (ACCOUNT = DATABASE)) UAF> MODIFY * /SELECTION /ENQLM = 50 UAF> LIST * /SELECTION VAX-53 PAGESWAPPER - July 1987 - Volume 8 Number 12 Fall 1987 VAX System Improvement Request Ballot SIR: F87-68 Abstract: There should be a tape-to-tape copy utility on the HSC50 and HSC70. Description: It would be very useful if a tape-to-tape copy utility was available for making copies of tapes. SIR: F87-69 Abstract: Provide the ability to limit the number of disks that are displayed, when using the MONITOR utility. Description: The display that is produced by "MONITOR DISK" includes all of the disks that can be "seen" by the local cpu. This display can be quite long if the local cpu is a member of a cluster with a large disk farm. Frequently, only a few disks need to be monitored. The MONITOR utility should be modified so that particular disks can be included and/or omitted. SIR: F87-70 Abstract: Enhance BACKUP to provide additional attributes for output files. Description: BACKUP should provide the same qualifiers that are available on the SET FILE command (e.g. /PROTECTION, /ACL, etc.). Such qualifiers would facilitate the restoration of files. SIR: F87-71 Abstract: Provide accounting information about terminal servers. Description: Currently, accounting information does not capture the port number and terminal server name for interactive session that login via LAT's. Port number and terminal server name information is extremely useful for trouble-shooting and determining terminal usage. VAX-54 PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX/VMS Security VAX/VMS Security Number next in a series - May, 1987 by Ray Kaplan PIVOTAL, Inc. 6892 E. Dorado Ct. Tucson, Arizona 85715 Hurrumph! I had hoped that this column would become an active interchange of VAX/VMS security information. Since my mailbox has lain fallow for some months, the column has become infrequent. Normally, I put DECUS things at a good relative interrupt level in my life, but not even the highest interrupt priority will help if an actual interrupt never comes in! As it is, this next article just dribbled out of the queue on its own. Buy This Book As I wander around teaching VAX/VMS security and getting involved with people's VAX/VMS security problems and with the larger world of computer security in general, I note that there seems to be a lack of practical literature on the subject. Besides writing my own VAX/VMS security book, I am always on the look out for books and articles on the subject of computer security. While I have had limited success in my search for VAX/VMS specific literature, I have discovered a lot of good general computer security literature recently. Back in October, I attended the Computer Security Institute's security conference in Atlanta, where I found a session on "Hacking and emanations demonstrations". This, in itself, was an eye opener, especially since the NSA prevented the emanations demonstration from being given. More on that interesting topic in a future issue! The chair of the session was one Jerome Lobel, who is the director of computer security for Honeywell, Inc. in Phoenix, Arizona. He has a relatively new book entitled "Foiling the System Breakers, Computer Security and Access Control." Since Jerome is a recognized authority on computer security and an active participant in the international VAX-55 PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX/VMS Security computer security community, finding his book to be well written and articulate came as no surprise. In the first chapter of the Guide to VAX/VMS security that comes with the full VAX/VMS manual set, there is a great, but tiny, taste of some of the security issues that need to be considered outside of the VAX/VMS specific "nuts and bolts" which the VAX/VMS manual rightly concentrates on. What is missing is a complete introduction to understanding the problem in the first place. By the way, if you have a MicroVAX, you did not get this manual with your software. You have to buy it separately, and I would recommend that you buy the complete manual set. In the event that you want to buy only the security manual, its number is AA-Y510B-TE. In my experience, there is too little discussion of the "front end" of this whole security business. Threat analysis, security policy and the like. While that is what Lobel's book does best, I liked his presentation of practical examples. For instance, in the section on trade-secret theft and software privacy there is a good discussion of exactly how large the problem really is. He has structured the book around what he calls a "computer security awareness program", and presents the material in a set of planning phases which are geared to provide you with a template to use for your own security plan implementation. This, in itself, makes the book a worthwhile purchase. In part one of the book, entitled "Understanding the Need for Computer Access Controls", he starts out with a discussion of how to analyze your system's security needs by looking not only at system vulnerabilities but at trends in computer fraud and industrial espionage as well. His discussion of the history of computer fraud is complete with examples of alleged computer crimes and even includes some ideas of what computer crimes will be committed in the future. The discussion of personal privacy and data access is complete with a summary of both the domestic and the international major legal issues. In the "Establishing a System Security Policy" section, he presents information on how to go about classifying and protecting information, risk analysis and technical vulnerability evaluation. If you have ever tried to do this sort of thing at your site, then you know how hard it is to get going without some guidelines. Jerome provides good, practical VAX-56 PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX/VMS Security guidelines. Since most VAX sites that I see do not have a system security plan, this section is perhaps of greatest interest to VAXers, as it provides a step-by-step guide on how to set up a computer security program. His discussion of how to select access control tools and technology includes an overview of operating system security and even though it leaves out VAX/VMS, it will widen your perspective on the problems at hand. Included in this section is a brief introduction to DOD trusted computer systems, database security, network security and data encryption. The discussion of how to complete a secure system design includes introductions to office automation, personal computer protection, and home computer security. He finishes the book with a section on implementing and monitoring access controls and a section on coping with change. What the book lacks in the way of DEC-specific information is more than made up for by its rich collection of introductory material and practical "how-to-do-its" for computer security implementation. If you can't seem to get the time to play with your VAXes' security features, I suggest that you buy this book for your manager. The net result should be a new awareness of the potential security problems around your site, and with a little push from you, you might end up with some more time to spend making sure that your VAX is secure. Priced as a professional book, "Foiling the System Breakers" is not cheap. However, a SIGNIFICANT discount is available on volume purchases. If you decide to buy the book based on my recommendation, drop me a line. I will offer to coordinate a "group buy" if you would like. Foiling the System Breakers McGraw-Hill Book Company Jerome Lobel 1221 Avenue of the Americas ISBN 0-07-038357-X New York, New York 10020 1986, McGraw-Hill till next time, Happy VAXing! Ray VAX-57 PAGESWAPPER - July 1987 - Volume 8 Number 12 SDA "FORMAT" Problem Solved SDA "FORMAT" Problem Solved Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 In the version of SDA that shipped with VMS prior to VMS V4.0, device driver writers could add their own symbols (for UCB extensions and the like) to those used by SDA's FORMAT command. In V4.0, this feature appeared to go away. Though it's still possible to read an object file to define one's own UCB-prefixed symbols, SDA apparently refuses to use them. Seth Stern of Reliance Electric recently called me with the solution. It seems that the V4.x SDA's FORMAT command is a lot smaller than that in old versions. If the TYPE field of the data structure being formatted indicates that it's a UCB, FORMAT looks in the device type and class fields of the UCB, and uses internal tables to determine which UCB symbols to use! This makes sense for DEC standard devices. DEC has defined many, many UCB extensions. With this behavior, when you format (for instance) a terminal UCB, the fields in the extension are interpreted with the symbols relevant to terminals, and those for disks, mag tapes, etc., are suppressed. But it doesn't help those of us who are trying to debug foreign device drivers. The ideal fix would be for DEC to change this behavior so that if the class and type fields indicate that the UCB is a non-DEC device, FORMAT will use none of the device-specific UCB symbols, but will use any other UCB symbols it knows about--including those defined by foreign driver writers. In the meantime, Seth offers the following workaround: Define symbols for your UCB extension that start with something other than UCB--for instance, XYUCB for XYDRIVER. Then use the TYPE qualifier on the FORMAT command: SDA> FORMAT/TYPE=XYUCB address VAX-58 PAGESWAPPER - July 1987 - Volume 8 Number 12 SDA "FORMAT" Problem Solved Of course, now you don't get the standard UCB symbols (unless you expand $UCBDEF and change all the UCB prefixes to your own). But it beats squinting at EXAMINE output. INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. To register for 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. ================================================================ Note 416.2 Journal files created using Backup 2 of 2 "Michael R. Pizolato" 7 lines 29-APR-1987 10:09 -< To all those who inquired... >- ---------------------------------------------------------------- I received a lot of requests for copies of my BACKUP command procedure. But, my company won't let me send any without going through hell for permission. So, I'm going to submit it to DECUS, and you'll be able to get it on tape from them. It's easier for me to get publication permission that way than permission to send tapes the other way. I hope to have it out soon. Sorry about that. Michael R. Pizolato AT&T Technology Systems Dept. 323610 555 Union Blvd. Allentown, PA 18103 215/439-5500 VAX-59 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 548.4 Disc Corruption Problem 4 of 5 "Ray Kaplan" 22 lines 15-MAY-1987 02:55 -< A still later reply >- ---------------------------------------------------------------- On the cluster: A while back (early March) I heard of a serious problem with shared disks. Seems that the XQP on one processor doesn't know how to let other cluster members know that INDEXF.SYS itself has fragmented. This is rumored to trash the disk. The fix that was suggested was (as you might guess) to make INDEXF.SYS bigger that you will ever need it to be. This was reported under V4.5 with HSCs. On the the stand alone disk, I haven't heard anything specific. At the Nashville Symposium, I ran into a fellow that is seeing the contents of random disk blocks come out when his SYS$ANNOUNCE and SYS$WELCOME files are printed out. Might be the same problem. If you want his name (and are still interested in this after all of this time) - please call. Ray Kaplan PIVOTAL, Inc. 6892 E. Dorado Ct. Tucson, Arizona 85715 ================================================================ Note 548.5 Disc Corruption Problem 5 of 5 "Kevin Angley" 14 lines 26-MAY-1987 11:23 -< Index file corruption in clusters does exist >- ---------------------------------------------------------------- There is indeed a problem with the index file on disks shared in a cluster. Telephone support will send you a patch. Naturally, the patch has bugs. It reintroduces the problem with append giving you an error message whenever it uses group privilege to write to a file. Because of this problem, we retreated to the original 4.5 and will take our chances. These problems were reported to TSC, with appropriate expectations for results. VAX-60 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT It is also interesting to note how worthless DSIN is ... neither the index file or the problem we reported with the patch that TSC is sending out is mentioned in this "online database of up to the minute news flashes of problem reports". DSIN is worthless. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 567.8 BACKUP Hints and Questions 8 of 9 "Bruce Bowler" 6 lines 27-APR-1987 13:35 -< 45' cable length >- ---------------------------------------------------------------- Re 567.6. I just talked to my service engineer this morning and he mentioned that he had talked to A DECie from Colorado who confirmed that when dealing with K.STI and TA78 there IS a cable length restriction of 45' (not meters, feet) on the SDI cable. This coupled with the lengths of cables that DEC sells effectively limits you to 12' or 25' cables. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 ================================================================ Note 567.9 BACKUP Hints and Questions 9 of 9 "Ken A L Coar" 6 lines 26-MAY-1987 13:45 -< A DECie [?] says USE /CRC >- ---------------------------------------------------------------- Just a note from Nashville, with no interpretation at all: I overheard a VMS developer tell users NOT TO USE /NOCRC, even if their tape drives do a CRC is hardware. I was passing by, and couldn't stick around to find out more - but there it is. VAX-61 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT #k Ken A L Coar General Dynamics Office Systems 12101 Woodcrest Executive Drive Creve Coeur, MO 63141 (314) 851.4003 (CST) ================================================================ Note 585.5 Anyone use defrag programs? 5 of 7 "Gus Altobello" 33 lines 12-MAY-1987 22:37 -< Is more information available? >- ---------------------------------------------------------------- I've taken note of all the preceding warnings concerning file id's, etc, and held off on procuring a disk defragmenter. But the arrival of our new system and SA482 disk stack have added to my feeling that I must do something about my disk defragmentation problems. Having no one to hang around at odd hours to backup/restore (and also since there's no good time to pull the disks offline on our system) I'm moving in the direction of evaluating one of these products. The best product for our needs appears to be Diskeeper by Executive Software, both because of functionality and minimal size of the manual. I intend to run full offline backups of all disks to be used in the evaluation. But still I fear the entry of a future note here, detailing my demise. Has anyone had any experience with this product, good or bad? How about any others? If the discussions here must remain vague concerning specific companies, could anyone with horror stories contact me directly? I feel a defragmenter would be an asset to our system's performance, but am willing to be warned off if they all seem too dangerous... Gus Altobello PO Box 11274 Hauppauge, NY 11788 516/435-7036 VAX-62 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 590.4 VAX 11/750 Word Processor 4 of 4 "Offline Submission" 14 lines 22-APR-1987 06:44 -< VAX 11/750 Word Processor >- ---------------------------------------------------------------- We are using Mass-11 on our 8 meg 750. Performance is good up to about 15-17 simultaneous users (with 15-20 doing other things). We use it for letters, program documentation, notes, everything. It has an EDT editor so you may have a shorter learning curve. Bradley Sheppard Coast to Coast 1000 16th Street Washington DC 20036 Telephone: 202-293-8000 Date: April 15, 1987 ================================================================ Note 593.8 Memory disk driver going away??? 8 of 8 "George Walrod" 4 lines 4-MAY-1987 08:06 -< Don't Believe Everything You Read >- ---------------------------------------------------------------- Lets clear the rumor up, I talked to VMS development About the PDDRIVER going away. Their reply was an (I quote) "Are you kidding me, If any thing it will be improved". George Walrod 4260-b chain bridge rd fairfax, va 22030 VAX-63 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 599.6 Any PSI users out there? 6 of 6 "RICHARD HARTUNG" 11 lines 26-MAY-1987 15:03 -< A PSI user >- ---------------------------------------------------------------- I use PSI for the classic use - connecting to a public network (TYMNET). We have found it to work very well. We have about 40 sites with up to 8 terminals on a concentrator and many more sites with one terminal and a modem to call a local TYMNET number. The only difference is on character echo, but the users get used to the application and just type away and look later. I am going to try to use this for a DecNet link to some new sites we are putting in and would like to know of the pitfalls of this approach. Thanks. RICHARD HARTUNG AIRCO 575 MOUNTAIN AVE MURRAY HILL NJ 07974 201-771-1246 ================================================================ Note 603.11 Using TK50 for BACKUP 11 of 11 "ROBERT G. SIMPSON" 14 lines 30-APR-1987 12:31 -< TK50's red button/light >- ---------------------------------------------------------------- RE: .8 ... MOUNT gives error message ... "volume is not software enabled" I have seen this problem several times and it was solved by cycling the red button out and back in a few times. I can only remember doing this when mounting the first tape, though, so I don't know if it works in situations as described. RE: .5, etc. It is very important to instruct operators not to touch the handle of the TK50 drive unless the red light is off. Lifting the handle while the tape is rewinding is fatal to the tape cartridge and the drive. ROBERT G. SIMPSON VAX-64 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT DRAVO CORPORATION, 300-12 ONE OLIVER PLAZA PITTSBURGH, PA 15222 ================================================================ Note 607.8 DECserver 200 application ports - how? 8 of 10 "Linwood Ferguson" 27 lines 13-MAY-1987 17:22 -< Accessing Server Ports - We do it >- ---------------------------------------------------------------- We also have Decserver 200 ports working as both incoming and outgoing dialup ports. They are somewhat flakey, however (occasionally hanging), and are not as robust at clearing modem problems as a DHU port (which cycles DTR periodically which for our Microcom modems tends to clear some weird states they occasionally get into). Some notes: It also works on a Decserver 100, though you have to have a modem that can ignore all modem control lines, and you have to be prepared for all the security risks of having it not know when things are hung up. I mention it only to in case you want to test whatever you're doing on a different and simpler box. Do not try async decnet over either a 200 or 100 port. It works, for all of about 2 minutes, then crashes the system. Dec says "no support". Too bad; we want to use Decservers instead of DHU/DMF/DHV's. Other note: we have connected lots of foreign devices (scanners, device control systems) to Decserver ports, both 100 and 200's, and accessed it both with SET HOST/DTE, and directly from QIO's in programs- they all seem to work identically to DHU/DHV ports. No problems. Compliments to Dec on transparency. Now just fix it so I can tell what physical port I'm logged into!!! Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 VAX-65 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 607.9 DECserver 200 application ports - how? 9 of 10 "Gus Altobello" 8 lines 14-MAY-1987 01:28 -< Re: 607.8 -- Async DECnet on a server >- ---------------------------------------------------------------- Linwood, get info from your DEC representative about the DECrouter 200. It's supposed to be specifically for server support of asynchronous DECnet. We've got a couple on order, if there's interest (and it continues past the delivery date) I'll let y'all know how well they do their job. Gus Altobello PO Box 11274 Hauppauge, NY 11788 516/435-7036 ================================================================ Note 609.6 Utility to read/write IBM tapes 6 of 6 "Reece Pollack" 5 lines 18-MAY-1987 17:50 -< More VMS <=> MVS tape exchange >- ---------------------------------------------------------------- DEC published a set of VMS DCL and MVS JCL to do magtape transfer in the DSIN a while back; their JCL is real close, but still has a bug or two in it. One warning though, my MVS Systems Programmer tells me that MVS doesn't like to work with ANSI tapes with a blocksize greater than 2048, which is the ANSI spec maximum. Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 VAX-66 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 611.15 LAVC Performance 15 of 17 "Linwood Ferguson" 98 lines 13-MAY-1987 15:56 -< LAVC Performance - Experiences >- ---------------------------------------------------------------- We've had some experiences, mostly negative, with LAVC's and performance. We still use them, but we've learned some things not to do. We tried using a 750 as a boot node, with a MicroVAX added as a method of getting more performance out of an expensive 750 (i.e. with all the hardware it had on it). It failed miserably, but in a way that many applications will not experience. Our application uses lots of shared files, and we were unable to completely separate users and their files onto separate machines (though we managed it about 80%). The problem is that the lock manager in a cluster assigns the master of the lock to the first use to open a file. Lets say a particular file is used 5% by node A, and 95% by node B. If B opens the file first, everything is good. If A opens it first, ALL lock requests initiated on B must go over the link to A and be serviced there. The behaviour we experienced was that the MicroVAX would run fine, while the 750 would spend anywhere from 10% to 95% (literally) of its time on the interrupt stack servicing the MicroVAX. The MicroVAX, due to its faster speed (including what I understand is a design "feature" of the 750 that when servicing requests over the LAVC link makes it run slower than the .65 MIP machine suppose to be) has the same problem, but to a far less degree. This resulted in overall significantly improved throughput, but completely unpredictable response, especially on the 750. Attempts to "direct" the locks to the right CPU through startup jobs that opened and held the locks worked to a large extent, but pose huge management problems (like what happens during a cluster transition when all locks are randomly reassigned, and what happens when you want exclusive access to a file, e.g. backup). We pulled it out of production. The good news was that the actual transfer of data, when lock activity was at a minimum, was more than acceptable. We expected a drastic difference in performance between jobs accessing local disks and disks on the remote node, and the difference, while significant, was quite acceptable in an interactive environment. VAX-67 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Environments with little file sharing (like our development environment here) work quite well. Here the problem seems to be more actual servicing requests for data, disk files, etc., particularly of the operating system. While Dec may fix this when they allow LAVC's to boot from a separate system disk and join an existing cluster (or if? anyone know when?), you can do something to help now. For people using a few images or libraries a lot, this can make a significant difference: SYS$SYSROOT is already a search list like: MJS$DUA0:[SYS2.],SYS$COMMON: Add to it, at the front (and remember the /SYSTEM/TRANSLATION=(CONCEALED,TERM) qualifiers) a directory on a local disk: MV3$DUA0:[LOCAL.],MJS$DUA0:[SYS2.],SYS$COMMON: Now put frequently used images, libraries, whatever in directories off of [LOCAL.], e.g. [LOCAL.SYSLIB], [LOCAL.SYSEXE], etc. If they are installed before, simply REPLACE them with INSTALL. This makes the access of frequently used images much faster, and more importantly puts a lower load on the boot node. Remember NOT to do this with data files needed to be updated simultaneously on all nodes, like SYSUAF or VMSMAIL. Other performance notes: We changed LOCKDIRWT to try directing SCS directory functions to faster nodes. It probably worked, but we certainly couldn't tell any difference. We cannot find a SYSGEN way to do anything about the locking problem above. We did get better statistics, but no visible improvement by tuning the MSCP parameters for the satellite node, especially increasing the buffers on big MicroVAXes doing lots of work (they seem to be set more for VAXstation type sizes). We'd appreciate any feedback anyone else has on performance Dec's documentation is a bit weak in this area. Footnote: when the interrupt stack time is high, most of the time is in the drivers for the DEQNA/DELUA, not the lock manager code itself. Yet the SCS statistics show little data exchange, and the interrupt stack correlates perfectly with incoming and outgoing Dlock requests. This is definitely not a hardware error (unless its a design problem) as we've observed it at 3 sites (Dec was insistent that it had to be); no one has given a VAX-68 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT good explanation of what it is actually doing, unless it is an error in the SPM reporting itself. Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 ================================================================ Note 611.16 LAVC Performance 16 of 17 "M. Erik Husby" 16 lines 14-MAY-1987 08:59 -< LAVC and DECType >- ---------------------------------------------------------------- Our experience with LAVC is minimal, essentially because we can't get DECType to run on it!! As the boot node has a large number of DECType users, this problem is hampering the production use of the LAVC. DEC's telephone support was more of a hinderance than a help. After 4 weeks of trying their suggestions (we could only run the LAVC night), none of which worked, we finally talked with the DECType Product Manager. Who told us that "DECType is not certified to run under a LAVC and we have no plans to do so". We got him to have some of his programmers to dial-in to our machine which they did the other night. They are now setting up a LAVC at their office to try and figure out what DECType could be doing wrong. The problem seems to be with DECType's handling of print queues. I will post the resolution of this problem as soon as I get it. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 VAX-69 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 611.17 LAVC Performance 17 of 17 "Frank J. Nagy" 6 lines 21-MAY-1987 07:17 -< LAVC locking and VMS V4.6 >- ---------------------------------------------------------------- A Nashville attendee told me that one of the changes in VMS V4.6 is to change the way the lock dictionary is distributed in a cluster to prevent slow nodes from dragging everyone down by essentially weighing the algorithm such that locks will be mastered on faster nodes. This should help (significantly?) the LAVC locking problems when using 750s as reported in 611.15. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 613.11 ACL Problems 11 of 11 "Ken A L Coar" 21 lines 26-MAY-1987 14:12 -< My experiments with VAXnotes protection >- ---------------------------------------------------------------- Back to the problem with VAXnotes conferences: After about an hour of experimenting, I concluded that VAXnotes creates a conference by getting the current default protection, removing DELETE access from all categories, and stuffing the result into a $XABPRO control block. Since this is stating an explicit protection, the DEFAULT_PROTECTION ACE is not applicable - it is only used when no protection code has been specified. If my conclusion is correct (I experimented by changing the server login file to change its default protection, as well as changing my own and creating conferences directly), I think the VAXnotes development people should address this. As it is, the whole sequence of inherited protection features given us in VMS V4 is totally ignored, and the behaviour seen is identical with normal file operations under VMS V3. VAX-70 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT As a side note: CREATE /DIRECTORY propagates the protection correctly, removing DELETE access. Maybe VAXnotes development should examine that code for pointers..? #k Ken A L Coar General Dynamics Office Systems 12101 Woodcrest Executive Drive Creve Coeur, MO 63141 (314) 851.4003 (CST) ================================================================ Note 616.2 Experience w/RDB,RALLY,TEAMDATA? 2 of 4 "ROBERT G. SIMPSON" 8 lines 30-APR-1987 12:16 -< Rdb Runtime/TEAMDATA/Xway >- ---------------------------------------------------------------- We recently installed Rdb Runtime, TEAMDATA, and Xway on our 9MB MicroVAX II. For Rdb, there are 24 pages of known problems in the release notes manual and 27 pages in the online version, most of which did not apply to our runtime version. One user executing TEAMDATA slowed down the system until we adjusted our SYSGEN parameters. Xway provides conversion between various storage formats once you have the files on the VAX. Transfer to and from personal computers is not provided. Rdb/VMS V2.2 requires at least VMS V4.4. ROBERT G. SIMPSON DRAVO CORPORATION, 300-12 ONE OLIVER PLAZA PITTSBURGH, PA 15222 VAX-71 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 616.3 Experience w/RDB,RALLY,TEAMDATA? 3 of 4 "Larry Kilgallen" 2 lines 3-MAY-1987 07:04 -< RE: 616.2 - What is Xway? >- ---------------------------------------------------------------- What is the full name, and if not DEC, who is the vendor? Inquiring minds want to know. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 616.4 Experience w/RDB,RALLY,TEAMDATA? 4 of 4 "Jack Patteeuw" 7 lines 19-MAY-1987 10:29 -< A DEC Product ! >- ---------------------------------------------------------------- The proper name is "VAX Xway". The part number is Q*729 and the SPD is 27.36.00. I have never used the product or read the documentation but if recall the sale blurb it is a package to allow the transfer of Lotus 1-2-3 spread sheet (on your PC) to and from DECalc and DECalc+. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-72 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 619.4 unwanted formfeed 4 of 10 "Richard Herdell" 24 lines 6-MAY-1987 14:27 -< LN03 Extra Page Fix >- ---------------------------------------------------------------- Our LN03 plagued us with a formfeed after every print job was finished until the device control module specified during queue initialization was modified. This module, in our case, PORTRAIT.TXT, had an c in it. I believe this causes a hardware reset of the LN03. This module was modified to c, replaced into SYS$LIBRARY:SYSDEVCTL.TLB and the extra page went away. I'm not sure why this works but it does, at least in this case. The queue set up is as follows: INITIALIZE/QUEUE/DEFAULT=(NOFLAG,NOFEED)/FORM=20 - /SEPARATE=(RESET=PORTRAIT)/START TXXX The form setup is as follows: DEFINE/FORM/NOTRUNCATE/NOWRAP/WIDTH=80 - /STOCK=DEFAULT/LENGTH=66/SETUP=PORTRAIT - /MARGIN=(TOP=0,BOT=0) PORTRAIT 20 Richard Herdell 7000 Hollister Houston, TX 77040 ================================================================ Note 619.5 unwanted formfeed 5 of 10 "Reece Pollack" 10 lines 6-MAY-1987 19:10 -< Print Symbiont Documentation >- ---------------------------------------------------------------- I really hate to scream RTFM, but try reading the VAX/VMS Utility Routines Reference Manual, Chapter 9 -- Print Symbiont Modification (PSM) Routines. It explains in detail why and when the print symbiont issues form feeds. I'm not claiming that this chapter is easy to read, but this stuff is documented. VAX-73 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Basically, the symbiont will issue form feeds anytime it thinks it isn't at the top of a page when it wants to be, and this includes after page and form setup modules which contain what it thinks is printable text. Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 ================================================================ Note 619.6 unwanted formfeed 6 of 10 "Bob Hassinger" 25 lines 7-MAY-1987 09:44 -< Obscure documentation locations... >- ---------------------------------------------------------------- I really hate to scream RTFM, but try reading the VAX/VMS Utility Routines Reference Manual, Chapter 9 -- Print Symbiont Modification (PSM) Routines. It explains in detail why and when the print symbiont issues form feeds. I'm not claiming that this chapter is easy to read, but this stuff is documented. Readability aside, this comment points out a problem that keeps coming up for me in the VMS documentation. Why would the average system manager who is just interested in setting up normal print queues ever think to plow through all the PSM stuff in volume 8A looking for clues. All the device control library references in the master index refer to chapter 9 of the System Manager's Reference Manual which is currently in volume 5A. I would suspect that would be where the average manager discovers there is such a thing as a device control library. I doubt the average person is likely to go off exploring all through more or less obscure material in remote locations on the chance it might turn up something. In the past I have had the same kind of problem with RMS. They used to expect you to muck around in all the macro level FAB and RAB stuff to discover basic things about the file system that have nothing to do with macro level programming. Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 VAX-74 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 619.7 unwanted formfeed 7 of 10 "CHUCK MCMICHAEL" 7 lines 12-MAY-1987 15:55 -< meanwhile, back at the VAX... >- ---------------------------------------------------------------- RE: 619.5 I have read Chapter 9, as a matter of fact. However, as far as I know, I'm not using any page or form setup modules. I'm simply issuing a START/QUEUE command and letting the defaults fall where they may. DEC was unable to come up with anything helpful when I asked around at the DECUS symposium last week. I'm still open to suggestions. CHUCK MCMICHAEL PITTSBURGH CORNING CORP 800 PRESQUE ISLE DR PITTSBURGH PA 15239 412-327-6100 ================================================================ Note 619.8 unwanted formfeed 8 of 10 "Reece Pollack" 17 lines 18-MAY-1987 18:15 -< FormFeed? What FormFeed? >- ---------------------------------------------------------------- If I remember right, we were trying to eliminate the form-feed issued when the queue is first started. This FF is issued so that the flag and/or burst page(s) will be aligned right, since they assume they are already at the top of a page. The correct way to eliminate this FF is to write a customized print symbiont which supplies a modified JOB_SETUP routine which does all of the functions of the DEC-supplied routine, minus the initial form-feed. For a real get-down-and-dirty quick fix, you could make a copy of the standard print symbiont sharable image and patch it, but this means getting a fiche license in order to keep up with the updates. By the way, I agree that a lot of the good tidbits are spread all over the documentation set, mostly buried pretty deeply, but I can't really suggest a better organization. The manuals for our IBM MVS system fill a small room (rather than a small bookcase) and expect even more from the reader than the VAX manuals... VAX-75 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 ================================================================ Note 619.9 unwanted formfeed 9 of 10 "Jamie Hanrahan" 16 lines 18-MAY-1987 20:22 -< before writing a symbiont, try this >- ---------------------------------------------------------------- Here is an easy way to get rid of the unwanted form feed caused by non-DEC-standard escape sequences (or anything else the print symbiont thinks will mess up the top-of-form position) in setup modules: Put an in front of the offending escape sequence(s), and an at the end. is 90 hex; is 9C hex. This effectively encloses your stuff in quotation marks; the print symbiont will pass it through intact (with the and , I believe), and otherwise ignore it. This advice is from one of the DEC folks at the VMS Advanced Q&A in Nashville. (See what you miss by flying out Friday afternoon?) I haven't tried it myself. I don't know what to do if your device does something "interesting" in response to . Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 VAX-76 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 624.1 warning on Monitor Ethernet command 1 of 2 "Keith Roberts" 13 lines 13-MAY-1987 14:09 -< No problem on our 750 or MVII >- ---------------------------------------------------------------- I tried the patching suggested in the April 1987 Pageswapper article "Undocumented Monitor Display Classes" and managed to crash two of my VAXes. I Did the patch to monitor under 4.5 on both my 750 and MicroVAX II...No Problem. Also, I patched it on the MicroVAX boot member at the Digital exhibit hall [Nashville] (running with 5 2000's). I ran it for at least a 45 minutes. It was interesting, the boot member saw a max of 191k bytes/second...average was about 60k bytes. We have ordered hardware/software for a LAVC which should be in in about a month, It was interesting to see how busy the ethernet was. Keith Roberts SASC Technologies Inc 109 Mass Avenue Lexington, Ma 02173 (617) 377-5959 ================================================================ Note 624.2 warning on Monitor Ethernet command 2 of 2 "Kevin Angley" 3 lines 26-MAY-1987 10:56 -< Another vote of confidence >- ---------------------------------------------------------------- Regarding MON ETHERNET patch, I have had no problem with it on a 8300. It is NOT particularly useful in my opinion, but fun to watch. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 VAX-77 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 625.4 Are there TU81+'s that work? 4 of 6 "Stuart Renes" 5 lines 28-APR-1987 18:08 -< proper MOUNT req'd >- ---------------------------------------------------------------- I presume that you ENABLED the tape data cache with the MOUNT command (you can see this with SHO DEVICE/FULL MUA0:) .a simple, but easily overlooked issue.... Stuart Renes AT&T Technologies, Inc. Mail Stop: 2793 3000 Skyline Dr. Mesquite, TX 75149 (214) 288-2286 ================================================================ Note 625.5 Are there TU81+'s that work? 5 of 6 "Linwood Ferguson" 14 lines 13-MAY-1987 16:16 -< Fast-yes, Work-Not often >- ---------------------------------------------------------------- We have TU81+'s installed on 750's, 785's, and an 8500. There is an incredible difference in performance on the 8500, apparently due to CPU speed (though I cannot swear it is not the BI, we have no reason to think our Unibus is overloaded, particular on the 785's). As to the original question "TU81+'s that work", we've had lots of trouble with then, apparently hardware trouble, but I'm beginning to wonder. Out of about 19 of them, over half have had long (2-7 day) downtime, most repeatedly. While Dec usually "finds the problem", it almost always seem to come back. Usually it is in the form of unexplained "fatal controller errors". Anyone have similar experiences? Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 VAX-78 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 625.6 Are there TU81+'s that work? 6 of 6 "Gus Altobello" 23 lines 14-MAY-1987 01:20 -< TU81+: Perhaps not hopeless... >- ---------------------------------------------------------------- Our TU81+ was generating about 300-500 errors per day, most of the vague variety. DEC comes in, pokes around, and often changes the head (yes, we've head the head changed twice, if I recall correctly). Vaxsim complains mightily about this device, and the DEC field tech once suggested we just remove Vaxsim. Other sites with TU81+'s have had the same problem. DEC tells the field guys to install Vaxsim, and when they do, the customer calls constantly because of the high reported error rate. One thing that seemed to help was an adjustment our DEC Tech tried, which he'd never tried before. Seems these drives can be equalized for particular tape types. You put the controller into a special mode, mount your favorite flavor of tape, and it runs for awhile. When done, the drive is equalized to work best with that tape. Since the last head change and equalization (and whatever other pokings the tech did) our errors are down to about 30-50 a day (quite an improvement). Gus Altobello PO Box 11274 Hauppauge, NY 11788 516/435-7036 VAX-79 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 626.5 Backups and Allin1 5 of 6 "Mark Hyde" 4 lines 23-APR-1987 08:13 -< Crucial to ALL-IN-1? I'd start with... >- ---------------------------------------------------------------- All of OA$DATA. All of a user'sUÁö ALL-IN-1 subdirectory structure [.A1...] mark Mark Hyde Digital Equipment Corp 360 Interstate North Parkway Suite 600 IPO1-6/C2 Atlanta, Ga 30339 ================================================================ Note 626.6 Backups and Allin1 6 of 6 "ROBERT G. SIMPSON" 7 lines 30-APR-1987 12:45 -< Re: Crucial to All-in-1 >- ---------------------------------------------------------------- Re: Crucial to All-In-1 In addition to OA$DATA, all of the OA$SHAREn directories. E-mail messages are moved to these directories after they have been sent. We have successfully restored OA$DATA, OA$SHAREn, and all user subdirectory structures [.OA...] from backups taken when All-In-1 was down. ROBERT G. SIMPSON DRAVO CORPORATION, 300-12 ONE OLIVER PLAZA PITTSBURGH, PA 15222 VAX-80 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 634.1 NETSERVERS: a question and a warning 1 of 2 "Jack Patteeuw" 10 lines 28-APR-1987 16:32 -< Another warning >- ---------------------------------------------------------------- A lot of my users have recently discovered the $ SET PROCESS/NAME command and now love to put cute saying out there from their LOGIN.COM file. This however causes an interesting problem. If the user is logged in (BATCH or INTERACTIVE) and a NETWORK session is started, it will abort because the network session will try to set the process name to the same thing which is a "no-no". The solution I used was to put a $ON WARNING THEN CONTINUE at the beginning of the users LOGIN.COM. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 634.2 NETSERVERS: a question and a warning 2 of 2 "Michael R. Pizolato" 14 lines 29-APR-1987 09:57 -< A way around it. >- ---------------------------------------------------------------- I like using "cute" names for my processes. I got around the duplicate name problem using two things: 1. A command procedure that selects, "randomly," one of ten process names, trying again if it picks one that was already picked, and giving up after 10 unsuccessful tries. 2. Using IF F$MODE() .EQS. "INTERACTIVE" THEN @PROC_NAME to only allow the command procedure to run for interactive logins. VAX-81 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT This works fine for me. I did spend a lot of time coming up with good names, though :-). Michael R. Pizolato AT&T Technology Systems Dept. 323610 555 Union Blvd. Allentown, PA 18103 215/439-5500 ================================================================ Note 635.1 CALLABLE EDITORS IN MAIL 1 of 1 "Lorin M. Ricker" 18 lines 21-APR-1987 00:28 -< Callable Editors from almost Anywhere >- ---------------------------------------------------------------- You're right about that trick with MAIL, and it works great and is a big saver. Analogous/similar tricks are now working with other DEC tools; either a logical name (like RDB$EDIT or RDO$EDIT (excuse my flakey memory)) or a command (there's one in the Symbolic Debugger) turn on the CALLABLE_TPU or _EDT interfaces, and you can take advantage of your favorite editor. TPU-hackers, note: by using the TPUSECINI logical name, you can get your own personalized TPU section file fired up, be it EVE, quasi-EDT, or a home-brew. Further note for TPU-hackers: in the case of a home-brew, be aware that, after the first entry into your TPU-section, the TPU$INITIALIZE procedure is NOT called again (on subsequent re-entries from the "parent" program (Debugger, MAIL, RDO...)) -- you must be careful about assumptions pertaining to editor state, global TPU variable values, etc. upon re-entry... usually, you'll need to look at exit-procedures with an eye to TPU's next (potential) call. Lorin M. Ricker EVANS & RICKER, Inc. 7062 N. Cambridge Ave. Portland, OR 97203 (503)289-3709 / (503)682-0179 VAX-82 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 638.1 TK50 Transfer Problem 1 of 1 "Lorin M. Ricker" 11 lines 21-APR-1987 00:18 -< TK50 Transfer Problem >- ---------------------------------------------------------------- hmmm... seems like it should work: have you tried this? Initialize the tape on the 11/23 under RT-11 (creating an RT directory structure), then write files to it (COPY). You should then be able to mount the tape on the MicroVAX (MOUNT/FOREIGN), and then EXCHANGE should be able to get at the files (MOUNT/VIR MUA0:) as logical disks. This has worked for us without problems on console media (CSA1:, with floppies on 780's and TU58's (slowly!) on 750's), but I've not had the opportunity to try it with TK50's. No reason why it won't work tho'... My memory of FILEX isn't very good, so I'll leave it to someone else to suggest a "symmetric" VAX-->RT-11 approach. Lorin M. Ricker EVANS & RICKER, Inc. 7062 N. Cambridge Ave. Portland, OR 97203 (503)289-3709 / (503)682-0179 ================================================================ Note 639.1 TSV05 at 100 ips. 1 of 2 "Mark Hartman" 7 lines 1-MAY-1987 19:52 -< Shoot it... >- ---------------------------------------------------------------- The DEC controller is, as you have noted, simply too slow (as is the Emulex TC02). While I will not advocate (here) any other manufacturer, our experience with the DEC version of the Cipher F880 (that is, a TSV05) leads us to consider it unacceptable. Mark Hartman Jadtec Computer Group 546 W Katella Ave Orange CA 92667 VAX-83 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 639.2 TSV05 at 100 ips. 2 of 2 "Linwood Ferguson" 8 lines 13-MAY-1987 17:02 -< What TSV05 Version? >- ---------------------------------------------------------------- > TSV05 doesn't run at 100ips Have you tried version 1.1 of the TSV05 driver? It had comments that made it sound like it improved performance. Unfortunately, we have not had access to one yet to try it (they are all on client machines). Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 ================================================================ Note 641.0 Anyone Using Cortex Appl. Factory No replies "MICHAEL GRATTAN" 7 lines 21-APR-1987 14:08 ---------------------------------------------------------------- We are converting from an old Datapoint network to Dec. We are going to use the Application Factory from Cortex to rewrite our applications. I am curious to know if there is anyone else who is running the Factory. I would like to know what kind of cpu you are using, how many terminals/users you have and any particular performance problems (and hopefully fixes) you have had. Thank you. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 VAX-84 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 642.0 print&batch complaints 3 replies "John Osudar" 28 lines 22-APR-1987 20:18 ---------------------------------------------------------------- As long as we're complaining about the queue manager/job controller/symbionts (e.g. note 630)... some thoughts, complaints, etc. about how VMS V4 print (and batch) job handling works: Has anyone else found that "page setup modules" (used in defining forms) don't quite work right? I tried defining a form using a page setup module, and found that it (a) caused some of the job setup modules (/SETUP in the form definition) to be skipped, and (b) repeated some page setup modules multiple times per page. Also: does it bother anyone else that you can define "job setup modules" and "page setup modules" ONLY in a form definition, and you can specify "file setup modules" ONLY in a PRINT command? We have a laser printer for which we spent real $$$ to get our letterhead digitized. A typical document would like the letterhead called up on the first page of a file. This can be done just file with PRINT/SETUP, but you can't define a form to do it -- putting the stuff in the form's /SETUP list causes the job flag page to come out on letterhead. Wouldn't it make sense to have the same setup features available both in a form definition and on the PRINT command? While we're talking about forms definitions: why does DEFINE/FORM have defaults such as /MARGIN=(BOTTOM=6) and /TRUNCATE, while the SHOW QUEUE/FORM/FULL command "neglects" to list the MARGIN qualifier if BOTTOM=0, and the TRUNCATE qualifier if it's set /NOtruncate? Seems a little inconsistent... Finally: would anyone else find benefit from enhanced batch job scheduling (we finally got print job scheduling by size in VMS V4, but there isn't much available for batch jobs) -- or, my preference, a "batch symbiont" that would allow similar flexibility in processing batch queues as that presently available with "output" queues? John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-85 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 642.1 print&batch complaints 1 of 3 "Bruce Bowler" 21 lines 27-APR-1987 13:51 -< I agree!! >- ---------------------------------------------------------------- Regarding improved batch handling, you bet we would like to see improved batch handling (even if it only involved a better queue selection scheme based on cpu availability, rather than queue slot availability). There currently is a CPU rating algorithm used by the terminals server products (not all that robust an algorithm but ...). It would seem to me that DEC should develop a uniform and consistent rating system for CPU availability that could/would be used by products that have a reasonable need to know CPU load for scheduling purposes, these products would include terminal servers, batch queues, and I am sure others that will come down the pipe in the future. One of my big complaints about the algorithm currently used by the terminal server is that a large compute-bound job running at lower than normal interactive priority (say 0 or 1 vs. 4) can drive a CPU's rating to 1 very fast, when in reality it should not do so. There for some method for determining what is chewing up the CPU time needs to be added to the algorithm so that it can behave in an intelligent manner. There was a program on a DECUS tape a while ago called ZEUS that attempted to do this (reasonably well I might add) that DEC should scrutinize for ideas on how to proceed. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 VAX-86 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 642.2 print&batch complaints 2 of 3 "Larry Kilgallen" 4 lines 2-MAY-1987 21:51 -< CPU statistics are insufficient >- ---------------------------------------------------------------- At present, VMS does not keep statistics on CPU utilization according to the priority at which the utilizing process was running. Changing that collection would logically not come before the next major release of VMS. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 642.3 print&batch complaints 3 of 3 "Bruce Bowler" 14 lines 4-MAY-1987 07:03 -< Not (necessarily) true >- ---------------------------------------------------------------- Larry, I am aware that VMS does not keep CPU statistics according to priority, and while I must admit I am not a complete guru at internals it would seem to me that one solution would be to have some process (JOBCTL comes to mind) do something at DEFPRI that takes a known number of clock cycles, timing itself while it does this. Then taking some measure of expected clock cycles versus wall time multiplied by some CPU rating factor, a reasonable measure of CPU availability results. It is not my expectation that this would be a constantly running process, but rather an event driven or clock driven action with a user selectable period. I still see that this would not/could not come before the next release but I think that it is a reasonable thing to ask DEC to do for the user. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 VAX-87 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 643.0 Virtual Disks in DecNet-DOS= 1 reply "DEREK FIELDS" 14 lines 24-APR-1987 07:11 ---------------------------------------------------------------- Is anyone doing extensive work with DecNet-DOS. We are installing an Ethernet network using IBM PCs as terminal emulators. We are also looking in the Virtual Disk Utility. It seems that this utility could solve a major corporate headache: We have 100 users (for example) and 20 copies of Lotus 1-2-3. We want to allow all 100 users access, but only 20 at a time to stay within the limits of our license agreement. The solution that occurs to us is to set up either 1 Virtual Disk with 1-2-3 on it and allow 20 (but not 21) users to access it or to set up 20 Virtual Disks and allow only one user at a time to use it. The problem with either solution is how to monitor access to the Virtual Disk, since no task is created on the host when the Virtual Disk is attached to the local PC. Any ideas? DEREK FIELDS NEW JERSEY BOARD OF PUBLIC UTILITIES 1100 RAYMOND BLVD NEWARK, NJ 07102 201-648-2417 ================================================================ Note 643.1 Virtual Disks in DecNet-DOS= 1 of 1 "M. Erik Husby" 8 lines 27-APR-1987 11:41 -< DECnet DOS virtual disks and FAL >- ---------------------------------------------------------------- You will get a task on the host when you access a virtual disk. That task will be running FAL. So that is where you can control your access. You should only need one virtual disk. Study the SYS$SYSTEM:NETSERVER.COM for ideas on how to keep track of how many are accessing the virtual disk. You should be able to do something similar to NETSERVER.COM's permanent servers. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 VAX-88 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 644.0 Wanted: MAIL improvements 9 replies "John Osudar" 43 lines 28-APR-1987 17:47 ---------------------------------------------------------------- Just about every VMS user uses VMS MAIL. VMS MAIL isn't bad; DEC has put some work into "improving" it, especially between V3 and V4, and it works reasonably well as an electronic mail system. (Not bad for an "exercise to learn VAX assembler coding"!) So what am I complaining about? Well, for starters, here's a small list: (1) Return receipts!!! Most reasonable mail systems (and even some unreasonable ones) provide for return receipts. DEC claims "too many users have complained that this would be an invasion of their privacy", so they won't do it. First of all, I'd like to meet those users -- everyone I've ever asked about this feature has liked it. Second, since DEC likes making everything optional, it would be practical, sensible, useful, and entirely acceptable to allow a user to say "SET NORECEIPTS" or something like that, setting a flag in the user's MAIL profile so that the sender gets told "User XXX does not produce return receipts". (Then I can go talk to XXX's supervisor and find out why XXX doesn't want people to know if he read their mail...) My personal opinion is that DEC doesn't want to add this (or too many other useful features) to a product that we get free with VMS, which would make it competitive with (better than?) similar products that cost real bucks. (2) Add other features that "reasonable" mail systems have -- CC: lists, for example. (3) Document and support the foreign protocol interface. This feature is in common use by a number of (free and commercial) products, and some of us could use it to replace our old kludgy code (which makes use of the "Mail-11" network protocol) that talks to non-DECnet networks and various foreign mail systems. VAX-89 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT (4) Fix deficiencies in the "improvements" that came along with VMS V4. For example, provide a way to delete an entire folder, or even all the folders in an entire mail file, along with all the associated MAIL$*.MAI files, without wasting time moving things into wastebaskets, or otherwise shuffling around things that you're really trying to get rid of. I've spent many long hours waiting for MAIL to finish deleting all the messages in each of the folders of a mail file, when all I wanted was to delete the entire file and all associated MAIL$*.MAI files. I'm sure other users have other complaints/requests; I hope those will be added to this note. It seems to me that these are reasonable requests. (Some other things I've heard requested, such as having VMS MAIL do store-and-forward, are more reasonably offered in an extra-cost product. Of course, one of us users might come up with a free version one of these days...) John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 644.1 Wanted: MAIL improvements 1 of 9 "MICHAEL GRATTAN" 11 lines 29-APR-1987 06:18 -< While we're complaining >- ---------------------------------------------------------------- We're converting from a system that doesn't even have anything like MAIL, so we're just thrilled to pieces that we finally a useful tool. However, I agree with you whole heartedly re:return receipts. I know that some of our users will ask why that isn't there when we introduce them to this system. One thing that I would like to see is an 'address list' of valid accounts that you could send mail to. The system manager (or some such person) could flag accounts that shouldn't get mail. In this way you wouldn't have to know that Fred's accountNY is called FOOBAR or whatever bie name it has. MICHAEL GRATTAN VAX-90 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 644.2 Wanted: MAIL improvements 2 of 9 "David Shepperd" 15 lines 29-APR-1987 20:36 -< More on MAIL >- ---------------------------------------------------------------- I agree that MAIL could be "fixed". At our facility it is the most visible VMS product on the cluster, yet it doesn't have the friendliness that such a program should have. Re the CC: lists, you can do that...well sort of. MAIL reads each token on the "To:" line and tries to translate it as a logical name. If that fails, it uses it as it is. If it succeeds, then the text of the translation replaces the text and the process continues. So, if you $DEFINE CC " " for example (note the space), then you can place a CC::STAFF on your "To:" line and MAIL will replace the CC with a space. Likewise, STAFF could be a logical name defined as a list of people ($DEFINE STAFF "TOM,DICK,NODE::HARRY") or as a pointer to a distribution list ($DEFINE STAFF "@SYS_MAIL:STAFF"). This can also bite you if you try to MAIL messages to people who have names that match any of your local or system logicals. David Shepperd Atari Games Inc 675 Sycamore PO BOX 361110 Milpitas, Ca 95035-1110 (408) 434-1711 VAX-91 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 644.3 Wanted: MAIL improvements 3 of 9 "John Osudar" 12 lines 30-APR-1987 15:49 -< ...but I don't want to fix MAIL myself! >- ---------------------------------------------------------------- I agree that there are ways to get "kind-of sort-of" CC-lists. (For that matter, products that sit on top of VMS MAIL, such as Microsystems' Mass-11 MAIL, implement return receipts via a kludge using the subject field!) That, however, is not the issue I wanted to raise. DEC's MAIL-11 protocol includes a flag indicating "whether the system accepts CC-lines" -- so obviously someone thought about including them, and didn't do it. A GOOD mail facility will distinguish between the recipients and the CC-list, so that you can tell if the message was addressed to you, or if you were included only on the CC-list. (For things like meeting notices, this can be important!) The whole point is, DEC could do it, DEC should do it, and we should tell DEC that we WANT them to do it. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 644.4 Wanted: MAIL improvements 4 of 9 "Larry Kilgallen" 10 lines 2-MAY-1987 21:58 -< I disagree >- ---------------------------------------------------------------- I would prefer to keep the more complex mail features like return receipts in the layered products, so that money spent on VMS development will go toward things not presently offered at all, and so DEC will not have to raise the price of base VMS software maintenance so much. I don't want to play silly bureaucratic games with a recipient over whether they have read their mail (given privilege I could always check their unread mail count anyway), what matters to me is whether they have ACTED on it. I think fancy features should be paid for by those who want them, not by all of us. Larry Kilgallen VAX-92 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 644.5 Wanted: MAIL improvements 5 of 9 "John Osudar" 11 lines 2-MAY-1987 23:05 -< I agree and disagree >- ---------------------------------------------------------------- Larry, I agree with you -- up to a point. If it were truly the case that doing without some features would keep prices down, give DEC more time to do REALLY useful things, etc. I would shut up. The only problem is that we still seem to pay for "fancy features" -- only they are ones that DEC cooks up, or a small special interest within the user community demands, and not those that a fairly large number of users really want. An alternative would be to document things well enough so that an enterprising user could implement enhancements (and possibly give them to the Sigtape?) But that doesn't seem to happen too often either. Anyway, that's enough ranting and raving (from me, at least...) John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 644.6 Wanted: MAIL improvements 6 of 9 "Larry Kilgallen" 16 lines 3-MAY-1987 07:12 -< Callable mail would help people "roll their own" >- ---------------------------------------------------------------- Note that Monday's "VMS Futures" presentation at the Spring 1987 (Nashville) Symposium mentioned "callable mail" as a possible feature of a future major release of VMS whose version number could not be mentioned by DEC employees at the symposium. (For those fairly new to reading between the lines, consider that the possibility of having such a feature in a version of VMS which DEC folk are forbidden to name is a lot better than the possibility of having it in a version of VMS so far out that DEC folks couldn't even guess what the name would be.) The clear VAX-93 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT implication was that there would be more information at the Fall 1987 Symposium in Anaheim, so start working on your boss now to get your trip planned (not that the DECUS Symposium Committee really need more people attending). Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 644.7 Wanted: MAIL improvements 7 of 9 "Bob Hassinger" 27 lines 3-MAY-1987 11:18 -< Too much for the wrong features... >- ---------------------------------------------------------------- Larry, I do not think return receipts and maybe automatic copies to the sender of forwarded (and annotated) messages are all that "fancy" for a tool so widely used. In any case, the problem here is that every layered product for VMS tends to cost a minimum of what something like the FORTRAN compiler costs on the same system! A few minimal features added to MAIL simply will not justify such a cost here. Also, the examples I have seen of DEC's ideas in this area are not very good. We end up spending a lot of money for a product that goes far beyond what we need, at a cost much greater than we can pay and in the process we loose the basic flavor of VMS MAIL which is what makes it so popular and usable across a very wide user base. I would have gladly traded many of the "improvements" in V4 MAIL for a couple of these features that have been requested for many years. Judging from everything I have heard on the subject from DEC people and others at Symposia and elsewhere it seems clear this IS a case of DEC protecting layered products at some level. If the layered products where good and affordable for my needs that might be OK but they have yet to get it right as far as I am concerned. I think it is this perception that keeps the requests coming for putting these features in VAX MAIL. Bob H Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 VAX-94 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT 617-435-9061 ================================================================ Note 644.8 Wanted: MAIL improvements 8 of 9 "Larry Kilgallen" 37 lines 4-MAY-1987 06:26 -< Let DEC work on NEW features >- ---------------------------------------------------------------- The trade-off of a finite budget to make only certain changes is exactly what is supposed to be modeled by the SIR process. The last Mail-related SIR I recall to make the big time (top ten) was a laundry list of everything which could be imagined, such that everyone with any feelings about mail would vote in favor of at least one of them. In total, however, DEC would end up re-implementing the message router in VMS, which just HAS to cost money to DEC, which means eventually to us. If VMSmail were to contain a store-and-forward feature, I think it should be the ability to work in better harmony with the Message Router. The message should go directly (read efficiently) ala VMSmail if the target node is up, and go via store-and-forward if the target node is down or if store-and-forward is specifically requested (for a quick return to DCL). This adaptive transmission is not available at all today, the message goes either one way or the other. Since there IS a way (albeit with cost) to get store-and-forward for VMSmail from DEC today, let the VMS developers concentrate on those aspects of mail which a) Only VMS can provide and b) Are not available AT ALL today I think callable mail is a perfect example. Let us presume that I do not like the present user interface (I don't have a complaint right now, but under pressure I could certainly come up with one). I think providing me (and you, and you) with the ability to roll my own is highly preferable to providing full-blown alternate interfaces. Why should DEC work on an ugly FMS-based interface for you when they could be working on a beautiful TDMS-based interface for me (or the other way around). Larry Kilgallen Box 81, MIT Station VAX-95 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Cambridge, MA 02139-0901 ================================================================ Note 644.9 Wanted: MAIL improvements 9 of 9 "John Osudar" 38 lines 5-MAY-1987 17:53 -< Let DEC work on USEFUL new features >- ---------------------------------------------------------------- First: callable MAIL sounds like an excellent idea. I look forward seeing it when my VMS V.0 kit comes... Second: I hate repeating myself, but as I said earlier... - new features whose complexity is at the "message router" level (e.g. store-and-forward) OUGHT to be extra-cost products - certain features that are useful, should not require a great deal of effort to implement, and have been requested by many users (e.g. return receipts, CC-lists) SHOULD be implemented in VMS MAIL. (I have yet to hear anyone from DEC say "return receipts will take too much of our time and effort to implement"; instead they say, in effect, "you don't REALLY want return receipts, so we won't do them". Guess what -- I didn't REALLY want mail folders, but they did them anyway...) - Making the product user-tailorable, and documenting the "back doors" that can be used by user-developed software (e.g. foreign protocol interface) is an acceptable way to give us some of what we need. (Callable MAIL fits in nicely here.) In fact, I am strongly in favor of having user-callable interfaces for as many VMS components as is practical. However, I think we need to be very, VERY careful not to allow DEC to give us software that has too little standard functionality with the excuse that "the user can roll his own" via the callable interface. My implementation of return receipts via callable MAIL may look nothing like, and be totally incompatible with, your implementation -- and if our systems are linked by a common network, that can be a serious problem. There IS room for DEC to enhance existing software, without expending an excessive amount of effort (or development money); but we, the users, must VAX-96 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT agree on the features we need most, and communicate that information to DEC. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 645.0 Errors on RD53 1 reply "MICHAEL GRATTAN" 7 lines 29-APR-1987 08:03 ---------------------------------------------------------------- We have a uVAX II running VMS. Every once in a while I'll get an error on the RD53 disk. When I look in the error log it says something about "SEQUENCE NUMBER RESET - OPERATION SUCCESSFUL". I have asked field service and they are vague although they say not to worry. But still... Does anyone know what this error means? Since this is my system disk, I am concern about having to replace it. Would greatly appreciate ant information. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 645.1 Errors on RD53 1 of 1 "Mark Hartman" 14 lines 1-MAY-1987 19:44 -< Packet hiccups... >- ---------------------------------------------------------------- Sometimes the MSCP protocol gets confused due to noise, imperfections, or cosmic ray hits. Since MSCP is a "packet" protocol, it uses some of the same error-correction algorithms as X.25 or packet radio - including packet sequence numbers. If the drive and controller start to get hopelessly confused, there's generally some kind of "hold everything and start over" signal that either master (controller) or slave (drive) can issue. This probably has the side effect of initializing the packet sequence number, which means that your error is very probably informational only. VAX-97 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT MSCP tends to put out LOTS of "informational" "errors"... I for one wish that they could be excluded from error listings (much as the RSTS /NOTAPE_ERRORS qualifier)... Mark Hartman Jadtec Computer Group 546 W Katella Ave Orange CA 92667 ================================================================ Note 646.0 Multiple Queues on one Printer 5 replies "Pat Murphy" 19 lines 30-APR-1987 11:39 ---------------------------------------------------------------- We have an application for connecting two generic queues to a single printer, with each of the queues having different default forms. We I had thought that by using generic queues sending their output to a single output queue, this would be be possible by using a device control library on the generic queues, each with a different /SEPARATE=RESET=xxx module. When I found out that one cannot attach a device control library to generic queues, I thought "ok, let's attach it to the output queue and just put the /SEPARATE modules on the generic queues" but still no joy. I've currently got a kludge going that involves command procedures on remote nodes but I wonder if anyone else has run into this problem (and no, we can't afford to get another printer!) Pat Murphy National Radio Astronomy Observatory P.O. Box "O" Socorro, NM 87801-0387 (505) 772-4337 VAX-98 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 646.1 Multiple Queues on one Printer 1 of 5 "John Osudar" 13 lines 30-APR-1987 16:15 -< one kludge or another... >- ---------------------------------------------------------------- There are ways to accomplish this, some of which are bigger kludges than others, and none of which (as far as I know) involve just using the standard DEC software. I set up a similar scenario using server queues and my EXECSYMB server symbiont: all of the generic queues feed into a single server queue. The queue processor for that server queue looks at the original (generic) queue name, and based upon that, requeues the job to the real queue with the proper qualifiers (/FORM, /SETUP, or whatever). Costs you one or two process slots (for EXECSYMB and a queue processor) but it works... If you are interested in more details, I can give you examples of what I did. The software itself will be on the Nashville VAX Sigtape (or I can send along an advance copy). [See also note 530.13] John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 646.2 Multiple Queues on one Printer 2 of 5 "Linwood Ferguson" 21 lines 13-MAY-1987 16:39 -< Two queues - One Printer >- ---------------------------------------------------------------- We had the same problem (needing to have two queues serving the same printer), and solved it a way that probably shouldn't work, but does. We simply defined two terminal queues (its an LN03) that reference the same device. We found that you needed to put a WAIT in the startup commands; apparently the first initialize does something that prevents the second from running, but if you wait about 10-30 seconds it seems to work. Once you get them started, we've had no problems. Of course if you want to stop/change forms/anything else it is a real pain (we don't). It is NOT a good solution, but we were limited by the VAX-99 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT application software (which let you specify different queue names, but not form types, and we wanted to print both landscape and portrait on the LN03). Try it (preferably sometime when you can shut down if it all gets hung up). No guarantees, it's probably not suppose to work that way. Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 ================================================================ Note 646.3 Multiple Queues on one Printer 3 of 5 "Reece Pollack" 15 lines 18-MAY-1987 19:03 -< Printer sharing w/ DECservers >- ---------------------------------------------------------------- If you have an Ethernet and a DECserver 200, there is an easy way to do this. The LATSYM print symbiont is designed to share a printer attached to a terminal server with other processors (the server keeps a queue of pending print requests), and I doubt if the server cares whether the competing processor is itself or not. This doesn't require a cluster, but does require the server hardware, etc. RE .2: You are right, this should not work. The print symbiont allocates the printer to prevent other processes from accessing it, but I guess it doesn't object to allocating it twice. The only problem is that I'll bet that if you queue two jobs to be printed on this printer, one through each queue, you end up with mixed output. Also, a print symbiont can handle 16 queues, and if you ever ended up with two print symbiont processes with one process handling one queue and the other handling the other, you'll have problems. Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 VAX-100 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 646.4 Multiple Queues on one Printer 4 of 5 "Frank J. Nagy" 8 lines 21-MAY-1987 07:05 -< Multiple nodes w/DECServer printers >- ---------------------------------------------------------------- We have a couple of Printronix printers attached to DECServer-200s with several nodes having print queues for the printers. In one case there is one queue on a large CI-cluster and two queues on an LAVC for one printer. On the LAVC, if you PRINT two jobs via the generic queue, job #1 goes into execution queue A and starts printing. Job #2 goes into queue B and waits until job #1 is completed! Surprise, no "interleaved" output! Another neat job from Digital! Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 646.5 Multiple Queues on one Printer 5 of 5 "Tony Carter" 17 lines 21-MAY-1987 10:43 -< Symbionts and SHARE privilege >- ---------------------------------------------------------------- Yes, multiple queues on one machine to the same port (or service) on a Decserver 200 will work. As far as why VMS doesn't care if you create two queues to the same printer, it is probably the infamous SHARE privilege. It allows you to do I/O to a device owned by someone else. The description of this privilege in the manuals says that it is normally only granted to things such as print symbionts. We have a dial-out modem connected to our terminal server. When a fully privileged user connected up to it's VAX port (LTAn:) that had already been allocated by another user, we saw the interleaved input and output that you're talking about. Very nasty. Needless to say we do not have SHARE on for anyone but SYSTEM now. Tony Carter P.O. Box 846 Middleton, MA 01949 VAX-101 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT (617) 245-6600 ================================================================ Note 647.0 Mail for RSX-11M+ 5 replies "John P. McGrath" 3 lines 30-APR-1987 18:52 ---------------------------------------------------------------- Does anybody know of a MAIL program that runs under RSX-11M+ and is compatible with VMS MAIL? Unfortunately I do not have a lot of money to spend on this. John P. McGrath Software Consulting Services 3162 Bath Pike Nazareth, PA 18064 (215) 837-8484 ================================================================ Note 647.1 Mail for RSX-11M+ 1 of 5 "John Osudar" 12 lines 30-APR-1987 19:42 -< how about free? >- ---------------------------------------------------------------- A long time ago ("in a galaxy far, far away") someone "accidentally" put a set of VMS MAIL-compatible programs on the RSX Sigtape. Copies of that software have been floating around ever since, and as far as I know, they still work. (They're installed on our RSX systems here, but lately VMS has been keeping me too busy to spend much time on RSX systems, so I haven't tried them under the latest versions of M and M+). I'll find out which tape the stuff was on when our resident RSX guru returns from the DECUS Symposium. If you don't have that particular tape, I'm sure someone can copy what you want onto a tape and send it to you. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-102 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 647.2 Mail for RSX-11M+ 2 of 5 "Mark Hartman" 2 lines 1-MAY-1987 19:39 -< what language? >- ---------------------------------------------------------------- John, do you know what language those programs for 11M were written in? I have some uses for such a MAIL system. Mark Hartman Jadtec Computer Group 546 W Katella Ave Orange CA 92667 ================================================================ Note 647.3 Mail for RSX-11M+ 3 of 5 "John Osudar" 5 lines 2-MAY-1987 22:58 -< you won't like the answer >- ---------------------------------------------------------------- I believe that what was on the RSX Sigtape included ONLY the object modules. (As I recall, someone at DEC wrote it and gave it away to the RSX Sig, then caught hell from his bosses for doing so. But some copies got out anyway. At least that's the legend that's gone around with the software...) John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-103 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 647.4 Mail for RSX-11M+ 4 of 5 "Bruce R. Mitchell" 8 lines 8-MAY-1987 17:14 -< Source for MAIL package >- ---------------------------------------------------------------- The MAIL subsystem for RSX-11M/M+ is written in three languages: Fortran, Basic-Plus-2, and MACRO. It was on the Fall 1981 and Fall 1982 RSX SIG tapes. There were two versions; RSX's mail and DECNET group mail. (The RSX group version is slightly better). Bruce R. Mitchell Machine Intelligence and Ind. Magic PO Box 816 Byron, MN 55920 (507) 284-9202 ================================================================ Note 647.5 Mail for RSX-11M+ 5 of 5 "Mark Hartman" 1 line 8-MAY-1987 20:50 -< Really? >- ---------------------------------------------------------------- Bruce - just confirming that this is the VMS MAIL-compliant package? Mark Hartman Jadtec Computer Group 546 W Katella Ave Orange CA 92667 VAX-104 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 648.0 VAX TDMS vs. FMS 5 replies "Richard Herdell" 24 lines 5-MAY-1987 11:04 ---------------------------------------------------------------- After reviewing the SPDs for VAX FMS & VAX TDMS, these conclusions present themselves: FMS is an early generation, forms control package where TDMS is a more recent 4gl forms control package which is integrated into the VAX Information Architecture. I have been told, rightfully or wrongfully, FMS is still around because it is heavily entrenched in the user community but TDMS is meant to displace it. Any ideas? My application interest is to control screen level data input and I'm interested in any war stories concerning these two sets of routines. Richard Herdell 7000 Hollister Houston, TX 77040 ================================================================ Note 648.1 VAX TDMS vs. FMS 1 of 5 "Larry Kilgallen" 28 lines 5-MAY-1987 11:49 -< TDMS does not replace FMS >- ---------------------------------------------------------------- Some may have seen TDMS as a replacement for FMS, but it never happened. Besides the use of FMS by pre-existing programs, there is the major factor that TDMS does not allow field-level manipulations to the degree that FMS does. In FMS one can easily write a validation routine, for example, to establish some arbitrary standard (e.g., numbers entered must be evenly divisible by 3), and that cannot be done in TDMS. On the other hand, TDMS does provide asynchronous functions, allowing a program to continue processing until input is provided. That capability is not in FMS. VAX-105 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT At the Spring 1987 DECUS US Symposium in Nashville last week, there was also discussion of the possibility of DEC implementing another forms interface, compliant with the forthcoming ANSI (?) standard. Since DEC has played a major part in the standards committee work (having a variety of experience implementing the beasts), it would seem likely that DEC would implement a third choice beyond FMS and TDMS. The nature of the forms interface described in the standard is sufficiently different from either FMS or TDMS is such that an implementation would NOT be an extension of either existing package. While the standards committee has dealt with generic issues such as the separation of form from function, users at the Nashville symposium gave comments to DEC on what they would expect in the way of VMS-specific features for an implementation of the standard (AST routines, etc.). Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 648.2 VAX TDMS vs. FMS 2 of 5 "Bob Hassinger" 20 lines 5-MAY-1987 12:30 -< FMS will not go away anytime soon... >- ---------------------------------------------------------------- One of the interesting pre-existing applications that uses FMS is All-In-1. It is my impression that All-In-1 uses enough of the unique features of FMS that are not available in TDMS so that conversion to TDMS would be "a major pain" if it was possible at all. In my own work I find I always seem to need the lower, field level, functions to make things work the way I want so there is no choice but to keep using FMS. Yes, many at DEC made it quite clear they intended for TDMS to replace FMS but it never happened and, in fact, I wonder if FMS is not the stronger of the two products today. At first we were told FMS would go away or not be developed and the FMS contingent in DECUS made a it clear they did not like the idea, then we were told DEC was going to work to bring the two products together and then we saw new releases of FMS but with no signs of convergence. At the Symposia I still sense more interest and involvement in FMS. VAX-106 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT The story of how we got to this sorry state will have to wait for another day... Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 648.3 VAX TDMS vs. FMS 3 of 5 "Mark Hartman" 4 lines 8-MAY-1987 20:49 -< But you never know... >- ---------------------------------------------------------------- Another interesting note is that DEC is continuing development on FMS from both the PDP-11 and VMS sides. This is not normally done unless the VMS side will be around for awhile. Mark Hartman Jadtec Computer Group 546 W Katella Ave Orange CA 92667 ================================================================ Note 648.4 VAX TDMS vs. FMS 4 of 5 "Linwood Ferguson" 31 lines 13-MAY-1987 16:32 -< FMS - Hated, but best going >- ---------------------------------------------------------------- We evaluated FMS and TDMS about 2+ years ago, after already doing several months of development in FMS. Conclusion (remember, TDMS may have changed a lot by now): 1) We absolutely HATE FMS 2) We use FMS instead of TDMS The reason is primarily those in a previous reply: FMS lets you handle fields as they are typed, rather than later. We do lots of this (for instance, most fields that refer to other files we link to a LOOKUP function through the FIND key; FMS lets you interrupt that screen entry and go off in a UAR (User Action Routine), inquire against that file, and finally return a value VAX-107 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT to the first screen all relatively (as much as anything is) transparent to the programmer that is writing the particular screen in use). It is my understanding that TDMS still does not have these kinds of field validation routines. FMS is a performance hog, poorly integrated, and a pain to program in. But if you take the time, you can do more for the user than you can with TDMS. Now, when we occasionally are lazy and use DISPLAY/ACCEPT or DCL to put something on a screen, spoiled users complain. If we had it to do over, however, we would spend the first few months doing our own version of FMS! Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 ================================================================ Note 648.5 VAX TDMS vs. FMS 5 of 5 "Steve Duff" 22 lines 14-MAY-1987 06:08 -< FMS/TDMS >- ---------------------------------------------------------------- In addition to the field functionality limitations on TDMS, I can attest to the fact that the development cycle with TDMS is a major burden because of the involvement with CDD, building libraries, etc, etc... All this soaks up cycles and man hours during programming, test and Q/A, and your requirements in this regard, I believe, should be considered carefully. On the other hand, TDMS provides essentially complete data mapping (though with limited control), and is easier to work with in a multi-thread transaction environment. TDMS programs are often remarkably short as a result. Having spent considerable time with both products, I tend to prefer FMS. We usually write a data-mapping layer in the code which isn't hard to do, and substitutes for that aspect of TDMS without the involvement of the lugubrious CDD business. At run-time, I haven't seen much difference between the two products (screen management isn't where most programs spend time anyway.) VAX-108 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT FMS and TDMS are really quite different products, about the only thing they share in common is the style of the forms editor. Steve Duff Software Factory 2401 E. 17th St. Suite 190 Santa Ana, Ca. 92701 (714) 752 2972 ================================================================ Note 649.0 Minor problem with NCP HELP\ 3 replies "Jamie Hanrahan" 18 lines 6-MAY-1987 00:16 ---------------------------------------------------------------- In NCP, how does one get HELP on a subtopic that consists of multiple words? For instance.. NCP> HELP SET CIRCUIT works fine, but NCP> HELP SET CIRCUIT MAXIMUM BUFFERS does not, even though the first command shows that `MAXIMUM BUFFERS' is a valid option for `SET BUFFERS' (as, indeed, it is). You can get the information by saying NCP> HELP SET CIRCUIT MAXIMUM but then you get information for *every* option starting with `MAXIMUM' (and there are several of them). Is there a way to make the second command, or something like it, work? Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 VAX-109 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 649.1 Minor problem with NCP HELP\ 1 of 3 "George Walrod" 6 lines 6-MAY-1987 10:03 -< Ambiguous Grammar >- ---------------------------------------------------------------- Sorry Jamie I have the same problem. The problem seem to be with ambiguous grammar in subtopic, submit an SPR, but I don't see a solution as far as help. But a note added to help documentation saying beware of ambiguous grammar when making help topics. George Walrod 4260-b chain bridge rd fairfax, va 22030 ================================================================ Note 649.2 Minor problem with NCP HELP\ 2 of 3 "Reece Pollack" 5 lines 6-MAY-1987 19:55 -< HELP with Multi-word Topics >- ---------------------------------------------------------------- If I'm not mistaken, if you ask for help on the topic just above the multi-word topic, you can then enter the multi-word topic at the "Help topic?" prompt. Give it a try -- I seem to remember this to be the only way to get to subtopics below a multi-word topic as well. Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 VAX-110 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 649.3 Minor problem with NCP HELP\ 3 of 3 "M. Erik Husby" 2 lines 8-MAY-1987 08:47 -< SPR on NCP HELP >- ---------------------------------------------------------------- I submitted an SPR on this problem quite a while ago and never received a response. I have no work arounds either. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 ================================================================ Note 650.0 Heavyweight update! 6 replies "Michael R. Pizolato" 8 lines 8-MAY-1987 10:49 ---------------------------------------------------------------- After a long and arduous struggle, I got my update services started again and just received 436 pounds of software from DEC (I have a lot of layered products). I got VMS up to V4.5, and lots of other goodies, too. Does anyone have any stories about installing some of the more recent versions of VMS? I am now running 4.2, and I want to go all the way to 4.5 in one shot. What about impact on layered products or applications developed using layered products or languages? Anything at all, really. Michael R. Pizolato AT&T Technology Systems Dept. 323610 555 Union Blvd. Allentown, PA 18103 215/439-5500 VAX-111 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 650.1 Heavyweight update! 1 of 6 "Joel Gallun" 6 lines 8-MAY-1987 15:45 -< Update Help >- ---------------------------------------------------------------- I belive you can go directly to 4.4 and then upgrade to 4.5. 4.4 is a complete distribution while 4.3 and 4.5 and all the other odd tenths of a version are just patch kits. (that's what we used to call them in my PDP-11 days, anyway) Joel Joel Gallun oao corp 7500 greenway ctr greenbelt, md 20770 ================================================================ Note 650.2 Heavyweight update! 2 of 6 "Linwood Ferguson" 9 lines 13-MAY-1987 16:23 -< 4.2 --> 4.5 Problems - Runoff >- ---------------------------------------------------------------- > Problems between 4.2 and 4.5? We are mostly on 4.4 and 4.5; both are very solid (we didn't even bother taking most nodes from 4.4 to 4.5). One problem we had around 4.3 was RUNOFF stopped processing lots of .REQUIRE's correctly. All of our documentation was in Runoff, and it all stopped working. We are still using the 4.3 (I think) version of Runoff. Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 VAX-112 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 650.3 Heavyweight update! 3 of 6 "Bruce Bowler" 4 lines 18-MAY-1987 13:07 -< RUNOFF >- ---------------------------------------------------------------- We use .REQUIRE's all the time in our documents and have had NO problems with them on 4.3, .4 or .5. What sort of problems are you experiencing, and what has DEC's response been?? Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 ================================================================ Note 650.4 Heavyweight update! 4 of 6 "Linwood Ferguson" 30 lines 18-MAY-1987 13:58 -< Runoff Error Still Around >- ---------------------------------------------------------------- > We use .REQUIRE's all the time in our documents and have had NO > problems with them on 4.3, .4 or .5. What sort of problems are > you experiencing, and what has DEC's response been?? When doing a file with LOTS of requires, we get: %RUNOFF-W-COR, Can't open required file xxxxxxx "unexpected operating system error" This happens after (pardon my memory) about one or two hundred requires. Once it starts, it never quits. I just did this again with VMS4.5A. We're running a version with a date (in the image header) of 23-Jun-85; the current version is 22-Mar-86. I think that working version was 4.3 or 4.2, though I can't swear to it. Dec said "yes, it does, we'll SPR it". That was so long ago I lost the sequence number, and have never bothered calling again. I guess I should. I never got a followup call from them. I should have sent in the SPR myself, but get tired of them being swallowed by the black hole somewhere between here and New VAX-113 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT England. One other item of note (in regard to big jumps in versions): somewhere along the way, and I don't remember exactly when, runoff changed the way it handled .REQUIRE default/relative file specs. It use to be that it defaulted to the current directory, then it defaulted to the last filespec required. I have not checked to see if they ever changed back (after I put in LOTS of directory specs, I didn't bother to take them out again). Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 ================================================================ Note 650.5 Heavyweight update! 5 of 6 "Reece Pollack" 17 lines 18-MAY-1987 18:38 -< OK to skip V4.3 update... >- ---------------------------------------------------------------- I jumped from V4.2 to V4.4 and then did the V4.5 update, and this works well, but you can't go directly to V4.5. Good luck with the layered products though, I know a few things broke around V4.4/5. COBOL has (had?) a bug introduced to the ACCEPT WITH CONVERT statements, but this may have been fixed in V4.5. A number of our old BASIC applications written under V1.X of BASIC as a result of RTL and/or RMS changes, but I really wasn't surprised by that. The PRINT/PAGES qualifier broke with V4.5 (it's now ignored), but you can use the V4.4 print symbiont if you need this qualifier more than the bug fixes. A good "gotcha" is the introduction of the SUBROUTINE statement -- these are great except that SUB ceases to be an acceptable abbreviation for SUBMIT, but DEC has always said that commands would be unique to 4 chars, not 3... I probably have forgotten a few things (I'm doing this from memory), but the system didn't fall apart. Good luck and try not to get a hernia from lifting all that documentation. Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 VAX-114 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 650.6 Heavyweight update! 6 of 6 "Edward Chan" 1 line 19-MAY-1987 16:38 -< Be sure to upgrade LAT PLUS after vms 4.5 >- ---------------------------------------------------------------- Edward Chan 1501 Harbor Bay Parkway Alameda, CA 94501 ================================================================ Note 651.0 Need VMS TM11 device driver No replies "Offline Submission" 14 lines 9-MAY-1987 12:07 ---------------------------------------------------------------- We are looking for a VMS device driver that supports the old TM11 controller/drives. We must have sources since the hardware is not quite TM11-compatible (one is Unibus, the other is 22-bit Q-bus.) We prefer public domain, but can pay some dollars to avoid doing it ourselves. Lawrence M. Baker US Geological Survey - OEVE 345 Middlefield Road, M/S 977 Menlo Park, CA 94025 Telephone: (415) 329-5608 Date: May 5, 1987 ================================================================ Note 652.0 Termtable definitions for SMG routines. 2 replies "Michael R. Pizolato" 17 lines 11-MAY-1987 13:28 ---------------------------------------------------------------- Does anyone know of any efforts to collect and distribute TERMTABLE definitions for the SMG Run-Time Library routines? Right now I'm looking for definitions for Tektronix terminals in particular, but I feel that a comprehensive collection would benefit everyone and should be put together. VAX-115 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT If no one is doing it yet, I'm willing to do the collecting. I guess the best way to do the distribution would be through DECUS. But, before I get deluged with TERMTABLE definitions, I would like some suggestions on how to collect the stuff without killing myself (for example, I certainly wouldn't want anything on paper). Then I could publish the rules of the game here, so that everyone will know what to do. Any suggestions? :-) :-) :-) Michael R. Pizolato AT&T Technology Systems Dept. 323610 555 Union Blvd. Allentown, PA 18103 215/439-5500 ================================================================ Note 653.0 HSC-50 runs only with 3 phase power?? 4 replies "MIKE SCHOEPKE" 10 lines 13-MAY-1987 11:36 ---------------------------------------------------------------- Is there any way to reconfigure the HSC-50 to work on single phase power? Our computer room is located in an office complex that does not three phase available. Any information would be appreciated. Mike Schoepke Paddock Publications PO Box 280 Arlington Heights, Il 60006 (312) 870-2667 MIKE SCHOEPKE PADDOCK PUBLICATIONS PO BOX 280 ARLINGTON HEIGHTS, IL. 60006 (312) 870-2667 VAX-116 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 653.1 HSC-50 runs only with 3 phase power?? 1 of 4 "MICHAEL GRATTAN" 5 lines 14-MAY-1987 06:23 -< Power equipment >- ---------------------------------------------------------------- Just a thought, while you may not be able to touch the HSC-50, perhaps you could look at some power conditioning/supply equipment. I keep getting all this literature about all the wonderful things they can do with your electrical power. Perhaps there's some kind of conversion equipment to go from single phase to three phase. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 653.2 HSC-50 runs only with 3 phase power?? 2 of 4 "Bob Hassinger" 23 lines 14-MAY-1987 08:08 -< Conversion to three phase possible, but... >- ---------------------------------------------------------------- Are you sure you can not get a version for single phase? I can not understand this for a device like the HSC-50 which is mostly electronics, not large motors and so on. Can you get the disk drives configured for single phase? If you really had to, I think you could make three phase from your single phase with a rotary converter - basically a single phase motor turning a three phase generator. I understand they are available although a lot of people seem to avoid them due to cost and so on. Also, I know of people who use a tricky device, a kind of a transformer I think, that takes 220 three wire single phase and gives "three phase" power that will run things like three phase motors (i.e. motors on larger woodworking machines and the like). This has always seemed to me as though it was being done with mirrors so I am not too confident about it, particularly where you are not dealing with rotating power devices such as motors. VAX-117 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Based on what I have seen I would say to try hard to get real three phase power or else try VERY hard to eliminate the need (like by getting DEC to sell you a single phase model). Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 653.3 HSC-50 runs only with 3 phase power?? 3 of 4 "Bruce Bowler" 12 lines 18-MAY-1987 13:15 -< Check again >- ---------------------------------------------------------------- Your in an office complex that doesn't support 3Phase power? sure sounds to me like someone is handing you a line. Most large A/C units like those found in office complexes use 3 phase, most (if not all) of the power into the complex will be three phase. In short, I can't believe that 3 phase is not available. I can believe that the building manager doesn't know it's available. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 ================================================================ Note 653.4 HSC-50 runs only with 3 phase power?? 4 of 4 "Jack Patteeuw" 12 lines 19-MAY-1987 10:53 -< Too much for just one phase >- ---------------------------------------------------------------- The HSC50 "probably" requires 3 phases because it would draw too much over just one phase ! This is the case of the 4-high RA81 cabinet requiring three phases where the three high only required one phase. VAX-118 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT re: .3 Bruce is correct. Almost ALL commercial building of even modest size have three phase brought into them because the cost of running the HVAC blowers is much less. As a matter of fact, it is impossible in our building to get 220v 1-phase!! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 654.0 Mail, Networks, Slaves, and Dist Lists No replies "Linwood Ferguson" 63 lines 13-MAY-1987 16:56 ---------------------------------------------------------------- We have an unusual mail problem that Colorado Springs hasn't been much help with. We have a medium size network (20 nodes), slow (lots of busy multipoint nodes), and send lots of mail, most to distribution lists involving at least 2-3 nodes each. This takes relatively forever (sometimes 3-5 minutes) between the TO: and the SUBJ:. Originally we defined distribution lists as logicals which in turn were files: GROUPA is "@SYS$MANAGER:GROUPA.DIS" contains: A::FRED B::HARVY C::JUDY Works. To keep updating to a minimum (these change a lot), we put the list on one node, so GROUPA might be only on A::, and on D:: its definition is GROUPA is "A::@SYS$MANGER:GROUPA.DIS" Works. Real slow as it creates a FAL process to read the file, then a MAIL process on each destination node. Next we tried this: VAX-119 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT GROUPA (on D::) is "A::GROUPA" GROUPA (on A::) is "@SYS$MANAGER:GROUPA.DIS" Rationale was that D:: would ship the "address" to A:: who would recognize it as a distribution list, and the slave process would read the .DIS file and send the mail. Guess what: it worked. Much faster. Except. Once in a while, the mail didn't go through. The NETSERVER.LOG process shows a Link Abort (in the example it would be on A:: when sending to GROUP from D::). No explanation, no further error. No identifiable Decnet problems (everything else works). It is repeatable, but intermittent. It seems a little related to load, but not in any firm way. DEC's response: Mail group says "You're using Decnet, don't talk to us". Decnet group says "lets check your parameters, ...."; no problem found, but also no knowledge of how the mail master/slave process really work. Anyone doing this (passing "addresses" that translate to address lists on the salve)? Is it working? Any ideas? My pet idea is that the master treats it as one "user", but the slave treats it as lots. The slave sends an acknowledgement to the master, who drops the link. The slave then aborts. Since all this takes time, and is not synchronous, sometime the slave finishes and sometime it doesn't. Dec listens politely to this and then asks me to check INCOMING or OUTGOING again for the 10th time. Help? Anything appreciated. Linwood Ferguson MJ Systems, Inc. P.O. Box 5223 2564 Ivy Road (22901) Charlottesville, Va. 22905-0223 804/977-2732 VAX-120 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 656.0 Replacement of BNT No replies "George Walrod" 2 lines 18-MAY-1987 11:05 ---------------------------------------------------------------- Has anyone heard of a replacement for BNT called the BNA on the 8xxx BI CPUs? George Walrod 4260-b chain bridge rd fairfax, va 22030 ================================================================ Note 657.0 Memory disk driver efficiency questions 1 reply "John Osudar" 30 lines 19-MAY-1987 14:18 ---------------------------------------------------------------- There's been some discussion in previous Pageswappers about the VMS "memory disk" driver (written by Jay Olson) that comes in your VMS kit as PDDRIVER, and is used to enable stand-alone backup to boot from TK50's. A "RAM disk" can be useful in a number of applications where a fast-access "disk" would improve performance (frequently-accessed files, temporary "work" files, etc.) Comments have been made (at DECUS and in other forums) that PDDRIVER is bad for your system, because it does its data transfers with a MOVB instruction at IPL 8. If you read the fiche, you'll find that this is true; PDDRIVER uses IOC$MOVTOUSER and IOC$MOVFRUSER to do its data transfers. These routines contain code that looks like: BITW to see if at end of page; BNEQ to skip end-of-page code; MOVB one byte of data; SOBGTR on the byte count to the top of the loop. Since I used to be an RSX driver hacker, I recall a thing called BLXIO that RSX used to speed up memory-to-memory data transfers. This was a sequence of MOV instructions; you computed an offset into the list and branched there, and it did the transfers at one instruction per word. My question is: has anybody who uses PDDRIVER thought about (or actually implemented) a similar scheme to improved PDDRIVER's performance? I've looked at the code, and it appears to be relatively simple to replace the IOC$MOVxxUSER calls with equivalent code that could, for example, do a short table of byte moves and a long table of quadword-aligned quadword moves. VAX-121 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Before I'd attempt to implement such a thing myself, I'd like to know (a) if someone has tried it and found it isn't worth doing; (b) if there's some reason why it shouldn't be done; or, preferably (c) that someone has done it, is using it, and is willing to give it away for free. (I'm always willing to run someone else's debugged, useful, and free software!) John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 657.1 Memory disk driver efficiency questions 1 of 1 "Jamie Hanrahan" 19 lines 19-MAY-1987 17:54 -< don't use MOVWs, use MOVC3 instead >- ---------------------------------------------------------------- I have used the BLXIO technique in a driver that accessed a shared memory device on a MicroVAX I. It was necessary because the shared memory had to be mapped in "non-cached mode" (obviously), and MOVC won't work to/from non-cached locations. An early version of the driver allocated a number of SPTEs (not just one) and mapped the entire user buffer into system space (at start I/O time; naturally the buffer was probed and locked at FDT time). The final version just did buffered I/O; the code was cleaner and the speed difference for buffers under 4Kbytes was negligible. Anyway, we did a BLXIO-type move between the user's data and the desired part of the shared memory. We tried doing it that way on the uVAX II, but MOVC3 was considerably faster. If anyone is planning to improve PDDRIVER I would suggest opting for dynamically mapping the entire user buffer (or at least more than one page; four or eight pages would probably handle most transfers) and using MOVC3. Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 VAX-122 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT ================================================================ Note 658.0 Berkeley UNIX on uVAXen No replies "Tony Carter" 8 lines 22-MAY-1987 15:10 ---------------------------------------------------------------- Does anyone out there run standard Berkeley Unix on a MicroVAX or a Vaxstation? We are looking to do just this, but the main problem is the bootstrap. No one seems to have it for the uVAXen. Ultrix is not really a solution that we want to go to. Tony Carter P.O. Box 846 Middleton, MA 01949 (617) 245-6600 ================================================================ Note 659.0 Logicraft on VAX? No replies "MICHAEL GRATTAN" 4 lines 26-MAY-1987 12:02 ---------------------------------------------------------------- I am wondering if anyone has had any experience using Logicraft products that run MS-DOS software on a VAX. I am interested in any comments you might have. Thanks. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 * * VAX-123 PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX System SIG Committee List VAX System SIG Committee List As of April 28, 1987 Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660 Joe L. Bingham - Librarian (core) 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 David Cossey - Assistant Symposium Coordinator Computer Center Union College Schenectady, NY 12308 Jack Cundiff - Symposium Coordinator (core) Horry-Georgetown Post Office Box 1966 Conway, SC 29526 Barbara Dow-Pleines - MicroVAX Working Group Magic One 1971 Mount Pleasant Road San Jose, CA 95148 (408) 238-0861 VAX-124 PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX System SIG Committee List Jim Downward - Migration and Host Development, VAXintosh Working Group KMS Fusion Incorporated 3941 Research Park Drive Ann Arbor MI 48106 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 - Publications Coordinator (core) c/o Shell Oil Company Westhollow Research Center Post Office Box 1380, Room D2158 Houston, TX 77251-1380 B. Hancock - Network Working Group Dimension Data Systems, Incorporated Post Office Box 13557 Arlington, TX 76094-0557 Ken Johnson - Handout Coordinator Meridian Technology Corporation Post Office Box 2006 St. Louis, MO 63011 Ray Kaplan - MicroVAX Working Group Pivotal, Incorporated Post Office Box 32647 Tucson, AZ 85715-32647 (602) 886-5563 Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Thomas Linscomb - VAXcluster Working Group Computation Center University of Texas Austin, TX 78712 VAX-125 PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX System SIG Committee List Leslie Maltz - Large Systems Integration Working Group Stevens Institute of Technology Computer Center Hoboken, NJ 07030 Ross W. Miller - Vice Chair and Working Group Coordinator (core) Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Mark D. Oakley - System Improvement Request (core) Battelle Columbus Labs Room 11-6-008 505 King Avenue Columbus, OH 43201-2669 Eugene Pal - Multiprocessor Working Group US Army CAORA (ATOR-CAT-C) Fort Leavenworth, KA Susan Rehse - Chair, PSS Coordinator (core) Lockheed Missiles and Space Building 101, Org 19-50 Post Office Box 3504 Sunnyvale, CA 94088-3504 Bob Robbins - VAXeln Working Group Array Computer Consultants 539 Timberridge Drive Longwood, FL 32779-2646 Larry Robertson - Real Time/Process Control Working Group Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA David Schmidt - LUG Coordinator, Store Representative (core) Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 D. Slater - Field Service Working Group Institute for Defense Analysis 1801 North Beauregard Street Alexandria, VA 22314 PAGESWAPPER - July 1987 - Volume 8 Number 12 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA To register for on-line submission, dial (in the United States): (617) 262-6830 and log in with the username PAGESWAPPER. PAGESWAPPER - July 1987 - Volume 8 Number 12 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 - July 1987 - Volume 8 Number 12 Internals and Data Structures Manual Petition Internals and Data Structures Manual Petition Dear Digital Press, Thank you for bringing the portion of the VAX/VMS Internals and Data Structures manual that was done with you to the Nashville Symposium. As a VAX/VMS practitioner I would ask you to speed the production of the completed version so that we can buy it from you. The timely production of a detailed, up-to-date internals manual is of major importance to me in my VAX/VMS related work. IN ADDITION, we would like to see a Version 5 VAX/VMS Internals and Data Structures manual published as close to the release date of the operating system as possible. Thank you for your consideration in this matter. --------------------- Tape shut, please don't staple ----------- Name Organization Signature ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ ____________________ ______________________ ________________ PAGESWAPPER - July 1987 - Volume 8 Number 12 Internals and Data Structures Manual Petition --------------------- Tape shut, please don't staple ----------- ------------------------------- Fold Here ---------------------- Please Don't Forget Postage From: Ray Kaplan PIVOTAL, Inc. 6892 E. Dorado Ct. Tucson, AZ 85715 To: Ray Kaplan PIVOTAL, Inc. 6892 E. Dorado Ct. Tucson, AZ 85715 ------------------------------- Fold Here ---------------------- PAGESWAPPER - July 1987 - Volume 8 Number 12 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - July 1987 - Volume 8 Number 12 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Mark D. Oakley Battelle Columbus Division Room 11-6-008 505 King Avenue Columbus, Ohio 43201-2369 USA PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX Systems SIG Fall 1987 SIR Ballot VAX Systems SIG Fall 1987 SIR Ballot DECUS membership number __________________ (six digits) Our site uses the following VAX cpus (check all that apply) 8700/8800 ___ 8600/8650 ____ 8500/8550 ____ 8300/8200 ____ 11/780,11/782,11/785 ____ 11/750 ____ 11/730,11/725 ____ MicroVAX I,II ____ MicroVAX 2000, VAXstation 2000 ____ We use VAXes 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: Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, OH 43201-2693 USA To be counted, your ballot must be received by October 30. PAGESWAPPER - July 1987 - Volume 8 Number 12 VAX Systems SIG Fall 1987 SIR Ballot Tear out or photocopy reverse to vote on SIRs Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, Ohio 43201-2693 USA