CHAPTER VAX PAGESWAPPER - December 1985 - Volume 7 Number 5 Editor's Workfile . . . . . . . . . . . . . . . VAX-3 Letters . . . . . . . . . . . . . . . . . . . . VAX-4 Some Suggested System Changes . . . . . . . . . VAX-5 MicroVAX vs PDP11 Performance . . . . . . . . . VAX-8 Defending Against Trojan Horses . . . . . . . . VAX-9 DEC Responses to 1985 European VAX SIG SIRs . VAX-13 1985 European VAX SIG SIR Full Results . . . . VAX-17 Spring 1985 VAX SIG Symposium Tape . . . . . . VAX-22 VAX System SIG Committee List . . . . . . . . VAX-31 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-34 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-39 System Improvement Request Submission Form . . VAX-41 PAGESWAPPER - December 1985 - Volume 7 Number 5 General material for publication in the Pageswapper should be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters. Please do not submit program source, as that is better distributed on the VAX SIG tape. 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 - December 1985 - Volume 7 Number 5 Editor's Workfile Editor's Workfile by Larry Kilgallen, Pageswapper Editor No rest for the weary - Having finished a week of upgrading various systems to VMS V4.2, I thought I would settle down to some quiet word-processing (it being Pageswapper deadline time) away from the cares and woes of the world. Was I ever in for a surprise. It turns out that Runoff under VMS V4.2 introduced an "undocumented and undesired feature" (hereinafter abbreviated as "bug") which caused it to apply sticky filespecs to include files. Bookstore reincarnation - As soon as I got a flyer in the mail saying that the DEC Bookstore in Bedford was back in business, I hot-footed it out there (hot-car?, no that has a different meaning in Massachusetts) to try for a VMS V4.2 documentation update. They had one right there, and they still take credit cards (the Pageswapper does not mention prices, but the set cost more than I generally carry in cash), so I was in business. Their hours are considerably restricted (only open three mornings a week), but consider the alternative: Not obtaining documentation from the DEC Electronic Store - The day after last month's Pageswapper went to production, I got a reply from the DEC Electronic Store regarding the Pascal documentation set I had ordered on July 10. It seems my order for computer documentation had been lost "due to communication problems between order processing systems", but if I was still interested in obtaining what I ordered I should contact them. I have replied that I am interested in obtaining what I ordered (that is generally why I order things). As yet I have not gotten it, but stay tuned during coming months as the saga unfolds (you might want to make sure your Pageswapper subscription is renewed for another year; we make no guarantee as to when the final episode will be published). VAX-3 PAGESWAPPER - December 1985 - Volume 7 Number 5 Letters Letters John B. Ferguson S.A.I. Corporation 505 Marquette Avenue, N.W. Albuquerque, NM 87102 October 4, 1985 Mr. Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139 - 0901 Dear Larry, Let me begin by offering some flattery. Your continued support of the VAX SIG by editing the newsletter is most appreciated by the rest of us in DECUS. Most of us are too lazy to volunteer. I have just finished my SIR ballot and noticed that many entries involved changes to DCL which would increase its usage as a poor substitute for a programming language. Perhaps it is again time to remind the VMS community (or perhaps just the new users): 1. DCL is slow because of image activation (among other reasons). 2. DCL is not a programming language, despite the IF-THEN construct and the GOTO statement (Egad!). 3. An appropriate high-level language will always be faster, better structured, more versatile and easier to modify than DCL command procedures (at least for bit-twiddling applications and number crunching). 4. DCL is meant to handle I/O at the file level, not at the record level. Go write a COBOL program. I use DCL command procedures extensively, and I like them. But I do not expect them to replace applications programs written in high-level or assembly languages. Yours truly, John B. Ferguson VAX-4 PAGESWAPPER - December 1985 - Volume 7 Number 5 Some Suggested System Changes Some Suggested System Changes Roger Jenkins Wycliffe Bible Translators 19891 Beach Blvd. Huntington Beach, CA 92648 (714) 536-9346 In the May 1985 PAGESWAPPER, Allen Watson published an article entitled, "A VMS Version 5 Wish List" and in June, Larry Kilgallen published an article entitled "Labeled Tape Shops in New Orleans". This article is my contribution to the ongoing effort of DECUS to try to tell DEC just what we want in an operating system. Since these suggestions cover a much broader scope than the two original articles, I thought it might be best to publish them in the PAGESWAPPER where they might generate additional ideas from other people. Then later they could be formulated into SIRs. FILE CATALOGS As Larry suggested in his article on labeled tape shops, almost everyone wants a computerized list of what all the tapes are. I would like to see two lists. One list would keep track of the tapes volumes themselves: The internal label, storage location, owner, last date cleaned, scratch date, etc. This list might contain a general entry regarding contents and maybe even format (BACKUP, ANSII, DOS, RT-11, etc) but no detailed file list. The second list would be a file catalog, which - given a file name - would return the volume label of the tape that contained the file. But why limit this catalog to tapes? Why not generalize it to be a catalog of any file anywhere on the system? This concept is not that different from a directory. A direcory is a file that contains a list of file names and where those files can be found. However the files listed in a directory must reside on the same volume as the directory. Furthermore, the volume must be accessible in order to read the directory in order to find out what files are on the volume. Files listed in the catalog could reside on volumes other than the volume that contained the catalog. A file so cataloged could reside on tape, offline disk pack, or online disk. Since one would probably want to use both directories and a catalog, cataloged files would first have to be listed in a directory or VAX-5 PAGESWAPPER - December 1985 - Volume 7 Number 5 Some Suggested System Changes the system would have to allow for cataloged files to reside on a disk without the file being listed in a directory and without being considered "lost". Perhaps a flag in the header could note a file as being a cataloged file. The user wishing to use such a cataloged file would simply open the file as something like "SYS$CATALOG:FOO.BAR". The system would find the file, request that an operator mount any necessary volume(s), and make the file available to the user. If a device was not available on which to mount the volume, the user would receive a suitable message. Those of you who have worked on "I've Been Misled" computers will recognize the concept. When creating cataloged files, the system could be allowed to place the file on the most empty disk. The user could even specify that particular files are not to reside on the same disk. On the other hand, the user could create a file in his own directory - then later catalog it. This would be similar to a volume set, except that the volumes would not be tightly bound as in a volume set. For management and performance purposes, the catalog could be subdivided. For example: SYS$CATALOG:[JENKINS.PAYROLL]FOO.BAR would refer to a file in the payroll section of Jenkins' section of the catalog. Disk space quota management is an area that needs some discussion. We have mentioned that the system could be allowed to control file placement of cataloged files. Would this require that the poor system manager create a disk quota entry for every user on every disk that has disk quota enabled? This would put the burden on the system manager, but might be the most straight forward way to do things. However, if the system is restricted to placing files only on disks where the user has sufficient quota, what do you do when a file grows too big for a quota on one disk, but the user has sufficient quota on another disk and the user doesn't care where the file goes? Move it? Probably not. Another option would be to give users a "total quota" that would limit their total disk space usage (not the usage on any particular volume). This total quota could be specified in a system-wide location such as the authorize file or a system wide quota file. Disk volumes could merely be flagged as having quota enabled or disabled. If quota on a disk was disabled, then the quota system would not restrict the amount of data a user could store on the disk. If a volume had quotas enabled, the total quota would limit the amount of data he could store on all such disks. VAX-6 PAGESWAPPER - December 1985 - Volume 7 Number 5 Some Suggested System Changes But what would one do if there was a total quota for each user and a particular disk had a QUOTA.SYS, and a user had no entry in QUOTA.SYS? Would he be allowed to use the disk based on his total quota or would he be restricted from using the disk? I tend to favor the latter, but what do others think? There might also be a need to limit the number of files a particular user could catalog in the system catalog. This would prevent obnoxious users from filling the system catalog with thousands of versions of FOO.BAR or some other such nonsense. DEVICE ALLOCATION If an interactive user wants to use a tape drive they either walk down to the computer room to see if a tape drive is available or call the operators or just allocate the drive and see if they get it. Some of these activities are difficult for batch jobs to perform. I am sure that many of us have written batch procedures that attempt to allocate a tape drive and if it is not available, the job either waits 10 minutes and tries again or resubmits itself to run later. However this is far from optimal. Ideally, one would like for all of the resources that a batch job needs to be guaranteed as available before the job even begins execution. I would suggest that a facility be implemented in VMS that would allow the submitter of a batch job to specify certain resources (tape drives) that will be needed during the execution of that job. The system would not release the job for execution until those resources were available. The system should even "pre-allocate" the resources prior to releasing the job to prevent another user from allocating the resource between the time the job was released and the time it actually began using the resource. Obviously "resource" as used here could refer to more than just a tape drive. Why not expand the concept to any non-shareable resource such as private disk drives, non-spooled printers, card readers and punches (perish the thought) and even resources like physical memory ("Don't run this job unless it can get at least a 3000 page working set.") If this feature were implemented along with a file cataloging system, the submitter could specify the files needed, and if any of them were on tape, the job would not be run until enough tape drives were available. It would be nice if DEC could also implement a "Don't run this job unless the system will be up for at least 45 hours without crashing" feature, but I won't hold my breath while waiting for it. VAX-7 PAGESWAPPER - December 1985 - Volume 7 Number 5 Some Suggested System Changes BATCH JOB CHAINING There are situations where multiple batch jobs need to run in a specified sequence. My suggestion is that DEC implement a /PARENT=jobnumber switch to the SUBMIT command that would cause the new job to be held until the parent job finished execution. There should be no limit to the length of the job chain and multiple offspring jobs should be able to chain to a single parent job. A facility should also be included that would cause a child job to be deleted from the batch queue if the parent job either does not finish normally or is deleted. Eg., /PARENT=(jobnumber,[NO]DELETE). In order for a command file to submit a chain of jobs, it is necessary for the command file to somehow be able to retrieve the job number of the parent job when it is submitted. That way the parent's job number could be used in the /PARENT= switch when the offspring jobs are submitted. CONCLUSION I am sure that I am not the first one to think of these ideas. I would encourage others to submit their ideas to the PAGESWAPPER and find out what others see as their needs. Perhaps then we can zero in on some more specific suggestions to DEC. MicroVAX vs PDP11 Performance At the PDP-11 Performance Panel in Anaheim on Wednesday, December 11, 1985, we will be comparing the PDP-11s with MicroVAXen for performance in various applications and configurations. Anyone with performance data comparing these processors is invited to bring that material to the session. You can be prepared to present it yourself, or we can present it for you. If there are any questions, call Tom Provost at (617) 245-6600. VAX-8 PAGESWAPPER - December 1985 - Volume 7 Number 5 Defending Against Trojan Horses Defending Against Trojan Horses by Larry Kilgallen Trojan Horse A computer program with an apparently or actually useful function that contains additional (hidden) functions that surreptitiously exploit the legitimate authorizations of the invoking process to the detriment of security. For example, making a "blind copy" of a sensitive file for the creator of the Trojan horse. - US Government Computer Security Glossary NCSC-WA-001-85 Some months ago I was preparing a list of computer security threats for a client along with recommendations as to what steps should or could be taken. For some items I listed exotic hardware devices which I knew were not practical in the situation, but which indicated to the client how far away from practicality the nearest solution was to be found. Then on Trojan horses, I got stuck. I just could not come up with anything for this typical commercial firm (no security classifications here) other than "train your users", and relying on that certainly didn't make me happy. At a government-sponsored computer security conference in October, one talk described a technique which seems to me to offer great hope in the area of defense against Trojan horses. The paper was prepared by W. E. Boebert and C. T. Ferguson of the Honeywell Secure Computing Technology Center in Minneapolis, and was entitled "A Partial Solution to the Discretionary Trojan horse Problem". VAX-9 PAGESWAPPER - December 1985 - Volume 7 Number 5 Defending Against Trojan Horses The Non-discretionary Access Control Solution For organizations like the military which have divided their data into security levels (secret, top secret, confidential, etc.) and categories (atomic, crypto, etc.) a computer system which enforces non-discretionary access controls will naturally prevent data from being copied outside permitted classifications by a Trojan horse. But the use of the non-discretionary security mechanism called "integrity levels" can guard against a Trojan horse scrambling data even within a single classification. Running in the opposite direction from security levels (secret, confidential and the like) which are designed to quantify the sensitivity of data, integrity levels are designed to quantify the trustworthiness of data. While with security levels the rule is that data cannot be copied from a more-secure level to a less-secure level, the handling of integrity levels is the opposite. Copying information from a set of data which are judged "more accurate" to a set judged "less accurate" harms nothing, but copying in the other direction would pollute what had been trustworthy data, so such action is not permitted. The integrity level approach to Trojan horse defense involves ascribing various integrity levels to PROGRAMS which are run (and are, after all, just a particular sort of input data to the CPU). Consider defining VMS software itself as having the highest integrity level. In fact, you more-or-less HAVE TO define VMS as having the highest integrity level, since it is used to modify all other files on the system. You could then define DEC layered products at the same level or a lower one. Then your user files. If all your user files were at a lower integrity level than VMS, and if you had your operators log in at the VMS integrity level, then operators could not run a user-supplied Trojan horse from their privileged account. C. Douglas Brown of Sandia Laboratories (VAX SIG Security Working Group Chair) has done some experimentation with latent non-discretionary access control support in VMS version 4, and last year at the Fall Symposium in Anaheim he described his experience with using integrity levels. Doug was concentrating on how one avoids painting oneself into a corner doing everyday things like booting VMS. Consider how much more complicated it must be trying to accomplish your organization's business in such an environment. Above we were considering protecting against Trojan horse attacks directed at privileged users. That may be most common, but it is not the only such attack possible. Do you run accounts payable inhouse? Would the accounts payable manager like a nice spreadsheet package? FREE? To protect against the possibility that the accounts payable manager would like such a package, are you prepared to divide all of your organization's VAX-10 PAGESWAPPER - December 1985 - Volume 7 Number 5 Defending Against Trojan Horses computing activities into 256 integrity levels in such a way to make sure that accounts payable is at a higher level than any would-be "spreadsheet" provider? Well, the VMS data structures also allow for 64 integrity "categories", so maybe you can divide your business that way. In my opinion though, the non-discretionary access control approach to Trojan horse defense promises to be quite difficult for protecting privileged users and impossible for protecting general users at typical commercial sites. Boebert and Ferguson's Discretionary Access Control Technique The environment used by Boebert and Ferguson is a "Secure Ada Target" (SAT) machine that Honeywell is working on in cooperation with the US military. While Honeywell was the first vendor to reach the highest possible ("A1") US government security rating for an entire computer system, the SAT team at Honeywell is interested in seeing if they can go beyond the A1 criteria far enough to force the government to declare an "A2" category. So this operating system in which they work has been designed from the ground up with security in mind. (In contrast, they don't have a lot of layered products, and they only have one customer lined up, albeit a big one.) The SAT environment has some security features not present in VMS, but I think the basic approach they propose might be worth considering in a VMS context. It would not be so bulletproof, but might be considerably better than the Trojan horse defense we have today. In the talk (which differed somewhat from the paper) Mr Boebert described a sort of "access control list" that one would attach to data for the purposes of Trojan horse defense. That list would restrict what PROGRAMS were permitted to access the data. (It would be in addition to the normal controls as to which USERS were permitted access.) The list of programs would call them out not by name, but by PROGRAMMER IDENTITY. In the SAT environment library modules are handled much as shareable images are in VMS, retaining their individual identity at run time. In the scheme outlined, then, all such modules as well as the main program must be from "acceptable" authors as specified in the list associated with the data. VAX-11 PAGESWAPPER - December 1985 - Volume 7 Number 5 Defending Against Trojan Horses Could this approach be used in VMS? The description given of the SAT environment indicates a much stronger concept of file ownership than VMS; there is no possibility for an owner to mistakenly protect a program world-write to allow someone else to modify it. If DEC were to attempt such support in the VMS linker, how could one be sure that an executable image had not been modified to misrepresent the source of certain subroutines? According to the description, SAT maintains an audit trail of every instance of their version of SET FILE/OWNER. Still, there may be some approach possible along this line under VMS for defense against Trojan horses. The philosophical basis which makes a similar approach difficult is that VMS presumes programs are inherently untrustworthy and carries out critical operations (like image activation and fixup) with no assumption made that the image is other than a synthesized bit pattern devised by a malevolent individual to take over the machine. Given that approach, the concept of protecting programs so that even their owner cannot modify them (ala SAT) is obviously quite foreign to VMS. There is support for "trusted" programs provided in the installation mechanism, but providing Trojan horse defenses only against installed programs certainly would address the wrong end of the spectrum. Information embedded in the file system at first blush seems a possible approach. The attributes of file owner and File ID are examples of data which users cannot modify at will even for their own files. But the file system only receives its information from user-mode programs, and whatever calls are made by compilers and the linker could be made by less honorable programs as well. Potentially the "authorship" attributes of a file could be such that they could only be set with privilege, and then trusted utilities and language processors could be installed with that privilege. Is there anything which can be done using encryption techniques? Is there a way by which authorship information could be included in executable images in a manner which defied forgery, perhaps like digital signatures? I am not a mathematician, but I hope those who are will realize that even imperfect algorithms have the potential of giving us considerably better protection than the nothing we have today. That is my call to action, contributions to a continuing discussion are welcome. VAX-12 PAGESWAPPER - December 1985 - Volume 7 Number 5 DEC Responses to 1985 European VAX SIG SIRs DEC Responses to 1985 European VAX SIG SIRs by Alan Silverman CERN, European Organization for Nuclear Research CH-1211, Geneva 23 Switzerland 1. FIRST CHOICE: 2402 points. (Also choice voted for most.) Appeared 53 times as first choice. 30. EDITING should support split screen editing. When editing, it is extremely useful to be able to see different screen windows simultaneously. This simplifies the moving of text between windows and makes the comparison of two versions quite simple. This facility is available on some other operating systems (not specified in suggestion) and there editing is speeded up very greatly. At least if EDT used windows, it would be extremely practical to be able to display two files or two buffers in separate windows. ANSWER: This feature is available in the new VMS editor VAXTPU. VAXTPU is programmable and can be used to form the basis of other product interfaces. VAXTPU provides two interfaces, EDT and EVE. The EDT interface does NOT utilize multiple editing windows (it is an EDT emulator), but does provide EDT-like multiple buffers. EVE was specifically designed to be used in either a single editing window or double editing window environment. 2. SECOND CHOICE: 2335 points. (Also choice voted for second most often.) Was MOST POPULAR FIRST CHOICE - It appeared 85 times as first choice. 50. On-line Disk Compression. The increasing use of single Winchester disks as system devices with different disk sizes and types for subsidiary storage makes it increasingly impractical to use BACKUP to consolidate the free blocks on a disk. As disks get larger, using tape as an intermediary to store a disk's contents before restoring it begins to take too long. VAX-13 PAGESWAPPER - December 1985 - Volume 7 Number 5 DEC Responses to 1985 European VAX SIG SIRs A utility is needed that will allow disk compression and consolidation of free blocks. If this can be provided just for non-system disks only at present this would be preferable to no utility at all. ANSWER: While the importance of an on-line disk compression is obvious in retrospect, this is a new request for us in that it has never appeared this prominently in past SIR ballots. We do not have any current plans to build such a facility. However we understand its importance, and we understand that its importance will increase as time goes on. There are a number of difficult problems to deal with, including coordinating ongoing file activity with compression, and solving the performance problem on large disks, since disk reorganization is inherently an n-squared order problem. We will investigate this for future VMS development. 3. THIRD CHOICE: 2167 points. (Also choice voted for third most often.) Was 5th most often placed as first choice - It appeared 49 times. 30. Supported timeout and automatic logging out of inactive terminals. It would be desirable from a security point of view if terminals which were not running any specific image and had had no I/O for a settable period were to be logged out by the system. The request suggests that this is effective against uncooperative users and has security advantages since unattended terminals will not be left logged on for longer than the few minutes. It will also be able to release lines with some types of terminal concentrator unit where modem control signals are used to clear lines. ANSWER: On the face of it, this appears to be a fairly simple problem. However, when one starts to investigate the details of how to ascertain that a terminal is inactive, the problem becomes increasingly complex. Because of the difficulty in establishing a reasonable general model of inactivity, and the fact that this sort of facility can be added to VMS by users with VAX-14 PAGESWAPPER - December 1985 - Volume 7 Number 5 DEC Responses to 1985 European VAX SIG SIRs systems programming expertise, we have so far not provided it with VMS. We are interested in discussing the details with users in an attempt to develop a model that would be suitable for implementation as part of VMS. 4. FOURTH CHOICE: 1785 points. Was SECOND most often placed as first choice - it appeared 74 times. 30. BATCH Checkpointing. It is requested that BATCH jobs could be stopped in some way that they can be held during a bootstrap or similar shutdown and restarted afterwards. Some installations need to shutdown to run disk to disk backups. Often a possible risk of a crash or power fail may be known in advance. If a batch job has a life of more than a few days it may have to be restarted a number of times before it can finally complete. A simple checkpoint command which places the process in a state similar to a swap-out but with all necessary registers and headers saved as well, would be adequate. ANSWER: This is a much requested feature, and is also one of the most difficult to provide in VMS. There are many aspects of the state of a general purpose batch job that we do not yet understand how to save and restore successfully, foremost among them being open files and I/O in progress. We have had under development a checkpoint facility that allows jobs to declare explicitly checkpoints at which they can be restarted. The non-transparency of these checkpoints greatly simplifies the I/O problems. We expect this facility to be available in the future. We will continue to investigate the feasibility of a more general checkpoint mechanism. 5. FIFTH CHOICE: 1722 points. (Was also choice voted for 5th most often.) 30. DISK QUOTA by groups. It should be possible to allocate disk quota by GROUP UIC as well as by individual UIC. This is a common request. System managers have reported that between 30% and 100% of USER accounts have VAX-15 PAGESWAPPER - December 1985 - Volume 7 Number 5 DEC Responses to 1985 European VAX SIG SIRs to share disk space and that the current solutions are to set many accounts to the same UIC or to switch off quota completely. It is more convenient to allow [project1,*] to occupy a certain number of blocks on a disk than to have all programmers of "project1" using the same UIC. ANSWER: We believe that the identifier mechanism provided in VMS V4, and the ability to charge resources to identifiers, should provide most of what is desired. This mechanism allows users to set up project libraries under which files are charged to the project instead of the individual contributors. If there are situations that this mechanism does not handle adequately, we would be interested in discussing them. VAX-16 PAGESWAPPER - December 1985 - Volume 7 Number 5 1985 European VAX SIG SIR Full Results 1985 European VAX SIG SIR Full Results by Alan Silverman CERN, European Organization for Nuclear Research CH-1211, Geneva 23 Switzerland This is a summary of the votes cast by members of the European DECUS VAX Special Interest Groups in the 1985 "System Improvement Request" (SIR) ballot. Only a simple title is given for each SIR; the full description appeared in the ballot paper sent to all VAX SIG members in Europe. Number of voting papers returned - 766 ---------------------------------------------------------------- SIR number Votes Cast ---------------------------------------------------------------- 30 2402 EDITING should support split screen editing. 50 2335 On line Disk Compression. 76 2167 Supported Timeout and automatic logging out of inactive terminals. 5 1785 BATCH Checkpointing. 26 1722 DISK QUOTA by groups. 2 1671 BACKUP should be able to copy save-set to save-set, both locall and over DECnet. 15 1467 SHOW SYMBOL should have the same wildcards as DIR etc. 44 1402 PRINT should be supported fully across networks. 31 1337 EXCHANGE should be able to read and write IBM formatted tapes (also EBCDIC) and to make ASCII copies of EBCDIC tapes and the reverse. 49 1259 Escape to DCL to create a subprocess without losing the running process. 58 1007 There should be an EBCDIC magtape ACP to allow writing and reading of IBM Tapes 71 995 VAX-17 PAGESWAPPER - December 1985 - Volume 7 Number 5 1985 European VAX SIG SIR Full Results Support some limitations of CPU intensive, interactive jobs. 61 960 Two Terminals in software parallel mode. (Tops-20 "Advise mode") 75 927 Temporary Files, Temporary Directories. 12 877 Sysgen Parameter for a timeout for DCL 63 792 Pipes for VMS 8 717 It should be possible to CALL all file manipulating utilities via DCL from any running process. 3 706 BACKUP should be able to copy BACKUP formatted tapes to another drive as savesets. 16 631 SHOW TERM /TTCn should show the current speed of a terminal, even if the terminal is allocated to another user. 45 592 PRINT should be able to reject files with non printing attributes. 41 584 MOUNT /FOREIGN with labels. 70 559 Improved Scheduler. 29 558 EDT (or new Editor) SORT ability. 42 541 MOUNT /HOLD command to queue a mount until a drive is free. 56 527 A method of entering at high priority to stop looping realtime processes. 17 519 Cluster Wide SHOW USER 62 519 Ability to OPEN a Logical Unit to more than one output device. 40 508 MAIL to Non-VAX and Non-DEC systems 57 501 I/O redirection in one line, UNIX fashion. 1 462 BACKUP /CLUSTERSIZE and other switches for initialising disks 22 412 DEBUG: Set Scope /FOLLOW, Set Module VAX-18 PAGESWAPPER - December 1985 - Volume 7 Number 5 1985 European VAX SIG SIR Full Results /FOLLOW 59 404 SYS$USERNAME, SYS$PASSWORD 53 402 File OPEN for READ should also update the Revision date 25 390 Provide DIR option for a user to select UIC in numerical form. 32 385 Fortran variables should be allocated from STACK storage at run time instead of statically. 11 341 DCL: READ Switch /TIMEOUT=deltatime 64 338 Authorized privileges should be inherited by Sub-Processes 36 336 INSTALL should be able to set a WSEXTENT that is greater than the user's process WSEXTENT 24 301 Make DEC-SLIDE and DEC-GRAPH device independent and not restricted to REGIS terminals. GKS support is suggested. 18 294 Full support for Pseudonyms, files entered in more than one directory. 43 282 PRINT /DEVICE= to select routing from a Generic Print Symbiont 10 269 DCL should have a function which allows it to get the full "device + directory + filename" of the command file that it is currently executing. 10 261 VAX BASIC source should be viewable from the debugger. 37 241 All DEC languages should do I/O via the SMG package. 13 241 RUN /Commandline = "text" in DCL 33 236 GETDVI should be able to return all devices of a given class. 14 228 SET TERMINAL /INQUIRE should use the "device attributes" capabilities defined in TERMTABLES.EXE by the SMG routines 7 212 VAX-19 PAGESWAPPER - December 1985 - Volume 7 Number 5 1985 European VAX SIG SIR Full Results SUBMIT /PASSWORD=xxxx to submit jobs by proxy 20 212 Debug should support SET EventFlag (number), SHOW Eventflag 69 204 Run a job from a mailbox 47 195 VAX-11 RSX to support RSX11M-PLUS 68 178 Complete the support of RIGHTS for project work. 73 177 Daylight-Saving-Time and The Time of Year Clock. 4 162 VAX BASIC should support the datatype DATE (8 bytes) to be consistent with CDD 39 160 Include a "plain" version of LSE with VMS and add language elements as "optional" products 9 More ways of sorting within F$SEARCH 23 158 DEBUG SYMBOLS within shareable libraries. 28 157 DSR should include MACROs as in NROFF, etc. 6 156 BATCH deadlock avoidance. 51 152 Directory Errors should be distinguished from other File Errors. 55 149 $GETSYI should be able to supply more executive data items 60 143 MAXDETACH limit of ZERO should mean no detached processes rather than unlimited. 67 124 Restriction of a Username to one or more hosts of a Heterogenous Cluster. 38 121 LINK /IDENTIFIER = xxxx so as to indicate that users of an image should be granted one or more identifiers that are held by the owner of the image file. 48 105 Document the package used for command qualifier support. VAX-20 PAGESWAPPER - December 1985 - Volume 7 Number 5 1985 European VAX SIG SIR Full Results 21 99 Documented interface to allow integration of third party compilers into DEBUG. Possible DEC integration for standard languages such as RTL/2. 66 91 Overdrafts for more VMS quotas 27 80 DSR .FIGURE DEFERRED should take a parameter, FIGURECAPTION 72 79 SETSYI and SETJPI system services 35 78 A documented ability to call the same module several places within a help file. 54 73 $GETJPI should be able to read the event flag cluster being used in an LEF wait. 34 55 HELP should print a user defined message when HELP is entered without a topic 78 51 A new modifier for the terminal driver WRITEVBLK function which causes the output (or prompt?) string to be placed in the typeahead buffer. 74 51 System support of Time Zones / Zone time. 77 50 System Update Option, no new functionality. 52 34 The error message generated from the implicit purge caused by exceeding a file's version limit should indicate that the limit was exceeded. 46 25 VAX-11 RSX, calling native mode code from RSX code. ---------------------------------------------------------------- VAX-21 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape Spring 1985 VAX SIG Symposium Tape by Joseph L. Bingham Mantech International 2320 Mill Road Alexandria, VA 22314 Distribution was started on the Spring 1985 VAX SIG Symposium tape in August. The package contains material submitted for the Tapecopy Project at the Spring 1985, New Orleans, DECUS symposium. It consists of two tapes organized as follows: The first tape has two save-sets, VAX000 and VAX85A. The second tape has one save-set, VAX85B. [VAX000] contains general information about the tape and concatenated copies of all the AAAREADME.TXT files. [VAX000.INDEX] contains an index of this tape and a consolidated index of all of the VAX SIG Symposium tapes. (The index was missing from the Fall 1984 tape but is back with this tape. In order to save space we have not generated an index of just the Fall 1984 tape and have not redistributed individual indexes of the preceding tapes.) [VAX85A...] contains all of the submissions except the largest ones which are in [VAX85B...]. Thanks go to Glenn Everhart, RCA, for doing most of the editing work on this tape and and generating the summary printed below and to Tom Gerhard for producing the indexes. The tape is available from the Decus Program Library and is being distributed to LUG Chairmen/Librarians by the NLO. Some of the material on this tape is specific to VMS version 3.x and some of it is specific to VMS version 4.x. The tape can be loaded on to a version 3 system - file names do not conatin "$" or "_" and are no longer than 9 characters and the sub-directory level does not exceed eight. However, the sub-directroy level is at the maximum for a version 3 system in [VAX85B.PRAXIS]. For that reason it is recommended that the sub-directory level not be increased when you unload the tape. i.e., the unloading command should be something like $BACKUP/LOG MTA0: [*...]. Following is a brief description of the submissions to the tape. All of the subdirectories are in [VAX85A...] unless otherwise noted. [.AMBY] By Don Amby Large collection of utilities. Includes DM which allows screen examination of directories/files and moving within a directory tree; revised SD; archiver commands; personal log maintain; Pascal pretty-printer; do DCL command to all files in a specification; VAX-22 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape whereami; whoami; convert stream to standard text file; remove control characters from file;UNIX like tools like cat, cd, ls, od, echo,wc. [.ARIZONA] By Joel Snyder EDT able to spawn DCL; break key daemon for VMS V4; editor for Fortran character arrays in memory. [.BATTELLE] By Gary Grebus Cleandisk, to remove old files of given types FAST; Handlesmb, modified print symbiont for special burst pages; Haspsmb, HASP symbiont for Comboard RJE link; Monitorjob, system use monitor; SETNODEID to make an ID corresponding to nodename; program to let nonprivileged users install shared images; DTR definition of UAF records; VARY to mark devices offline; symbiont for Xerox laser printer. [.CLEMENT] By John Clement Latest Bonner Lab Runoff, large superset of DSR. Learn it and use it. Much better than DSR. Still compatibility mode but a native mode version is coming. [.DFWLUG] Dallas/Fort Worth LUG Macros supporting V4 SMG$ calls from Macro-32; cross checker to check directories on disks and cross reference to UAF; output of space left on mounted disks. [.DWIM] By Karl Johnson Partial DO WHAT I MEAN for VMS V4. Keeps track of context of your commands and remembers files you're working on. [.ERI] By Bob Goldstein, Daniel Smith Command files for VMS usage; MACSnVAX file transfer between Macintosh running MacTerminal and VMS. [.EROS] By Thomas Bodoh BOUNCER, Idle terminal killer with variable time limit and also keeps a report of idle but nonkilled terminals. [.FINGER] By Richard Garland This is Finger for VMS V4. Note the readmes. Many new features have been added and DECnet support is now supplemented by support for some other networks too. VAX-23 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape [.GRAY] By Thomas Gray Advanced Users' LOGIN allowing DCL symbols to be defined within a single image and with easy mods. For VMS V4. [.HUGHESSCG] By Kevin Caruso and Gordon Howell PTYDRIVER - Pseudo terminal driver for VMS V4. Implements ALL VMS terminal I/O functions. UUCPMAIL - sample foreign mail protocol for vaxmail. Interfaces to locally done VMS-UUCP (available to UNIX source licensees free from K.C.) Stratego - resubmittal of 2 terminal STRATEGO game for VMS V4. OPERATOR - captive operator procedure. [.KERMIT] is in [VAX85B...] Tree [.KERMIT] By Nick Bush and Brian Nelson New VMS Kermit for V3 or V4 fixing some bugs. New PDP11 (RSX/RSTS/POS/RT11) Kermit. [.KMSKIT] is in [VAX85B...] Tree [.KMSKIT] By J. Downward Numerous system management aids, graphics packages, TVG sources. The famous Vax Professional Workstation, an office automation toolkit which does what All-In-One does, just better, faster, and more cheaply. Now supports more graphics, windows, etc. and has full VMS V4 support. [.LILUG] By John Hasstedt and Al Scholldorf Program to dump retrographics graphics to a laserprinter. Program for making custom VT100 characters. Magtape to magtape format-independent copy. TEX sources for handling QMS Laserprinter. Tape utilities. [.LJK] By Larry Kilgallen Pageswappers since the Fall '84 symposium. [.MACPRINT] By Bob Wilson Converts MacIntosh printer output to VAX printer compatible form. [.MILLER] by Robin Miller Two major submissions: VAXNET revised for V4 and supporting several new modem types, and a new version of VTL which is a super file lister. VAXNET currently supports VAXNET and XMODEM file protocols; Kermit will be added later. Script mode operation has also been added. This has been used for sending via Easylink. VAX-24 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape [.MORSE] By Kathy Morse Slides for some of the sessions given by the VAX/VMS developers at Spring DECUS in New Orleans. [.NSWC] By Alan Zirkle Better queue delete command; another SD command; LET as a replacement for ASSIGN and DEFINE; Reminder utility with source (NOTE: AT+T Reminder from VAX84 fall tapes will break soon! It has a timebomb in it. Get into a replacement like this ASAP!) Documentation on SMG$. [.NU] By Rand Hall Fast login.com and tuning statistics gatherer; utility to allow non-privileged users to do many things in a controlled way. [.OAKLEY] By Mark Oakley Files: quickly find files based on ownership and size, revised for VMS V4. GRANTID: software to grant and revoke system rightslist IDs. [.PANEL] By Brian Lockrey Utility to make it easy to make menu systems under VMS using DCL and FMS. [.POTTER] By Andrew Potter VMS V4 utilities. NEWS, alternative to sys$welcome. CD - fast change directory. GMAIL - general purpose public bulletin board facility. NETCOPY - preprocessor for copy that asks (without echo) for password. NETUSERS - shows user and batch jobs on up to 5 nodes on VT125 or GIGI (or use VT100 version also supplied). NODESHOW allows users to look at other DECnet nodes without actually logging onto them. TRMPRNT allows print to VT102 printers similar to VMS PRINT. EDTSPN allows spawning DCL inside EDT. USERSET - allow user to change his name, UIC, acct name, etc. (but not process JOB logical name table). [.PRAXIS] is in [VAX85B...] Tree [.PRAXIS] By LLNL This tree contains full source and executable distribution of compilers for the PRAXIS language, native VMS, native RSX, and VMS cross to RSX. Also included are a number of tools including an automatic translator of PASCAL to PRAXIS. Praxis is a structured language somewhat similar to Pascal or Ada but with realtime, multitasking, and information VAX-25 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape hiding primitives along Ada lines but more cleanly done and more comprehensive (and slightly lower level for the multitasking). The compiler is said to produce good VAX native mode code. This kit was released to the DECUS library also. [.PRC] By Jim Noble BACKUP - commands for doing backups consistently. KERMIT - Fixes for VAX Kermit 3.0.052 (obsoleted by V3.1.066 in [.KERMIT] distribution). Documentation on terminal driver parity flags fields. [.QUEST] By Owen Anthony The game QUEST, a dungeons-and-dragons type game. [.RCA] By Glenn Everhart, Rick Eesley, and Brian Griffin BBASE - small DBMS for RSX or VMS CPMRSX - Utility to read/write CP/M disks on RX01 or RX02 DTC - souped up DTC from C. Garman. VERY nice now for all kinds of calendar maintenance and much more flexible. Superior in some ways to VPW version (inferior in others). General area has DDT, BGL2 super banner builder for printer, FIGEDT figure drawer, FGE.ARC figure editor archive plus LXY11 postprocessor (both use ordinary VT100), misc. BASIC programs for PERT chart, critical path method, etc., extended LISTRS multicolumn printer utility. Figure editors are contributed by others in the area, not GCE. PortaCalc object libraries (if you don't have a usable Fortran). Portacalc for PDP11 or VAX, VAX version in [pccpdp] has DTR-32 interface. PortaCalc spreadsheet for VAX without DTR interface, but faster than last time's (and faster on VMS than most commercial spreadsheets). Some IBM PC and generic 8088 codes including PCVT, a VT100/VT102/VT52 emulator for IBM PC clones, small C, and a FORTH for MSDOS, and a Z80 Focal. A super squeeze/unsqueeze that works better than the SQ/USQ presented last time, using a more sophisticated algorithm, by Martin Minow and others. A mod of a TAR floppy read/write utility that gives access to TAR format RX01, RX02, and RX50 floppies. WINDOW, a VMS V4 window system that allows you to have up to 10 "glass TTY" windows simultaneously on an ordinary VT100 and control sizes, positions, which is "in front", etc. complete with full VAX-26 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape sources. WINDOW is by Rick Eesley. YASS, a souped up continuous system status monitor. Yass is by Brian Griffin. [.SASLAM] By Sohail Aslam A plotting program that works as a picture editor. A DCL preprocessor that allows one to write structured DCL. [.SCREEN] By Jeff Burch EDT-LIKE screen editing from Fortran. Complete sources present; requires VT100. Can be used for FMS type applications also. [.SENDNET] By J. Dutertre SENDNET - aid to keeping VAX network under control by simplifying software updates across a net. Does store/forward for propagating updates. For VMS V4.X. [.SKUNK] By Dennis Jensen SETDEF for VMS V3 or V4; EDT able to spawn DCL. [.STREAMCVT] By Thomas Danforth Convert stream-LF or Stream-CR files into normal implied carriage control files. [.SZEP] By Steven Szep Homebrew account manager for managing user accounts in an academic environment. [.VEVLE] By Mark Vevle RMDEMO - dynamic user display GRADE - class grading program, with screen graphics SMAUG - CPU hog cutter-down. If n users, none gets over 1/n of the CPU without having his priority lowered. [.WATCHDOG] By George Walrod. An idle terminal killer. Tested in VMS V3.X only. [.WATSON] By Allen Watson COM - many command procedures used in DECUS talks VAXDOC - word processing system using Runoff and EDT including spell checking, archiving, source control, automatic indexing etc. TALKS - notes from several talks including Adjusting work set parameters Nifty Things with DCL Comparison of 2 versions of EMACS VAX-27 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape Intro to TECO plus other items. [.WENDY] By Wendy Koenig VMS version 4 update of SD a set default program. [.WENTZ] By Eric Wentz Interface between DCL and FMS to allow command procedures to be menu driven. [.XLISP] By David Betz Experimental object oriented LISP. Full sources of V1.4 are here. SIZES: VAX000: 2 Directories, 23 Files, 10340 Blocks VAX85A: 168 Directories, 3717 Files, 51557 Blocks VAX85B: 128 Directories, 4824 Files, 63190 Blocks FUTURE TAPES Your submissions keep the Tapecopy Project a valuable source of public domain software. Please keep the following in mind when you are preparing them: 1. Help people find things of interest. a. Provide an AAAREADME.TXT in the top level directory with a very short description of the submission. A few words should be sufficient - the AAAREADME.TXT is only to let users know that there is something in the submission in which they might be interested. If you do not provide an AAAREADME.TXT or if we consider yours too long we will insert one and we probably will not describe your submission as well as you can. b. Come to the Tapecopy User's Forum and describe your submission. People want to know what is coming out on the next tape. Here is your chance to tell the audience - and the buyers of the audio tape - about your submission. c. Include similar information on the Tapecopy Release Form. If you do not show up at the Tapecopy User's Forum the information on the release form is usually all I can tell people about your submission at that time. VAX-28 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape 2. Help people use your package. a. Your audience ranges from novice to guru. Try to provide documentation with useful information for the entire range. b. Include your address and/or phone number. Nobody expects you to provide extensive support for public domain software but it is nice to know that you care enough about your submission to make yourself available for questions. Also you might get some useful feedback from users. 3. What should you submit? Basically anything which you think others would find useful which you have a. developed or b. improved. If feasible consult with the original author - he may be working on similar changes, may offer help and almost certainly is interested in what you are doing. Give the original author credit for his part of the work. 4. How should you organize your submission? a. Large submissions should be in a directory tree with an AAAREADME.TXT on the top level directory and documentation in appropriate sub-directories. b. Sources. Users are frequently as interested in how you did something as they are in what you did. There are security issues also. Please include sources. c. You may include a copyright notice but it must not restrict distribution of the material by Decus or Decus members. 5. What should you not submit? a. Do not submit non-public domain software. You may submit patches to VMS or layered products but do not include the original or modified versions of the products. b. Do not submit "Freeware". That is, do not ask for a contribution from users of the software. Do not submit packages with a "Time Bomb" in them. The VAX SIG tape is for public domain software. VAX-29 PAGESWAPPER - December 1985 - Volume 7 Number 5 Spring 1985 VAX SIG Symposium Tape c. Do not feed back large amounts of material which is readily available from previous SIG tapes. We may have to trim material which appears superfluous to keep the tape size within reasonable bounds. 6. Turn in your tapecopy submission at the Library Booth in the Exhibit Hall at the next Decus Symposium on Monday or Tuesday. You may at the same time submit it to the Decus Library. Pick up your tape at the Library Booth on Thursday or Friday. Your comments and suggestions are welcome. Joe Bingham VAX SIG Librarian ManTech Services Corporation 2320 Mill Road Alexandria, VA 22314 (703) 838-5600 VAX-30 PAGESWAPPER - December 1985 - Volume 7 Number 5 VAX System SIG Committee List VAX System SIG Committee List As of October 28, 1985 Osman K. Ahmad - TOPS-VAX Association of American Railroads Technical Center, Research and Test Department 3140 South Federal Street Chicago, IL 60616 Joe Angelico - Assistant Symposium Coordinator US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA 70130 Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660 June Baker - Planning Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046 Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 Bob Boyd - Commercial 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 Jack Cundiff - Assistant Symposium Coordinator Horry-Georgetown Post Office Box 1966 Conway, SC 29526 Tom Danforth - Handout Editor Woods Hole Oceanographic Institute Woods Hole, MA 02543 VAX-31 PAGESWAPPER - December 1985 - Volume 7 Number 5 VAX System SIG Committee List Jim Downward - Migration and Host Development, VAXintosh KMS Fusion Incorporated 3941 Research Park Drive Ann Arbor MI 48106 Jane Furze - Campground 3830 West Cochise Phoenix, AZ 85064 Dennis Frayne - Real Time/Process Control McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals In House Systems 165 William Street New York, NY 10038 Don Golden - Publications Coordinator c/o Shell Development Company, D-2132 Westhollow Research Center Post Office Box 13480 Houston, TX 77001 Gary Grebus - System Improvement Request Battelle Columbis Labs Room 11-6011 505 King Avenue Columbus, OH 43201-2693 B. Hancock - Network Dimension Data Systems, Incorporated 2510 Limestone Lane Garland, TX 75040 Jeffrey S. Jalbert - Historian J C C Post Office Box 381 Granville, OH 43023 614-587-0157 Ken Johnson - VAXcluster Working Group Meridian Technology Corporation Post Office Box 2006 St. Louis, MO 63011 Ray Kaplan - VAXeln Pivotal Incorporated 6892 East Dorado Court Ticson, AZ 85715 VAX-32 PAGESWAPPER - December 1985 - Volume 7 Number 5 VAX System SIG Committee List Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Eugene Pal - Multiprocessor US Army CAORA (ATOR-CAT-C) Fort Leavenworth, KA Thomas Provost - Hardware MIT/LNS Bates Linac Facility Post Office Box 846 Middleton, MA 01949 Susan Rehse - System Management Lockheed Missiles 3251 Hanover Street Palo Alto, CA 94301-1187 Bob Robbins - Advisor Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA David Schmidt - LUG Coordinator Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 D. Slater - Artificial Intelligence Institute for Defense Analysis 1801 North Beavregard Street Alexandria, VA 22314 VAX-33 PAGESWAPPER - December 1985 - Volume 7 Number 5 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 469 Caption: UNIVAC 1100 Level 5 COBOL to VAX 11/750 COBOL Message: We are looking for a COBOL translator. We have a package written in UNIVAC 1100 COBOL with DBS level 8 for schema and subschema (DMU record type), and would very much like to convert it to VAX format. We do not have DBMS on our system but we do have DTR. This package is very important to our company, please help us!!!! Contact: Maria Pop The Hamilton Street Railway Company 18 Wentworth Street North Hamilton, Ontario L8L 5V1 Canada Telephone (416) 527-4441 ext. 225 Date: September 10, 1985 Pageswapper editor's comment If you get no takers and decide to write your own translator, you might consider the SCAN language just released by DEC. It is designed for writing translators. VAX-34 PAGESWAPPER - December 1985 - Volume 7 Number 5 INPUT/OUTPUT INPUT/OUTPUT 470 Caption: RT11 tape support on VAX -- Reply to I/O # 423 Message: I have routines that will read and write RT11 format tapes on a VAX. They work fine for ASCII files provided the filename is exactly six characters long. For binary data we write using non-file structured mode on RT11, and a special input routine on the VAX. Contact: Dr. P. A. Elcombe The Cavendish Laboratory (HEP group) Madingley Road Cambridge CB3 OHE England Telephone 0223-66 77 Date: September 12, 1985 INPUT/OUTPUT 471 Caption: Remote printing on a VAX network -- Reply to I/O # 428 Message: We have written some stuff to do this. We use a DCL command to get the file and node name with a subset of the PRINT command qualifiers allowed (/QUEUE, /FEED, etc.). The function is implemented as a command procedure spawned by an installed image which provides NETMBX privilege. This image also gives us privileged procedures with execute-only access to the world. We use it to run interactive EDT sessions at priority 5, and to ship DCL SHOW commands for execution on other nodes, amongst others. Contact: Phillip Gaisford Swiss Institute for Nuclear Research CH-5234 Villigen Switzerland Telephone +41 99 36 17 Date: September 25, 1985 VAX-35 PAGESWAPPER - December 1985 - Volume 7 Number 5 INPUT/OUTPUT INPUT/OUTPUT 472 Caption: I/O redirection and STR$MATCH Message: 1. How can I input SYS$QIO from a file instead of the keyboard to support automatic testing of FORTRAN programs? 2. VMS V4 RTL function STR$MATCH does not seem to work with asterisk (*), although percentage sign is interpreted correctly. Is this a VMS bug? If not, could someone please provide an example of correct usage in a FORTRAN program. (I receive the Pageswapper with a considerable delay. I would appreciate it if any answers could be airmailed). Contact: Ben Livson Israel Aircraft Industries, Limited Department 4526 Ben-Gurion International Airport Israel 70100 Telephone (03) 9713111 Date: October 2, 1985 INPUT/OUTPUT 473 Caption: EDT on foreign terminals with TERMTABLE Message: I would like to talk to anyone who has used TERMTABLE to set up foreign terminals so they can run screen mode EDIT/EDT. I am interested in knowing what foreign terminals can use the TERMTABLE to support the screen mode EDIT/EDT and which terminals can not. Contact: Qingzhou Wang Sakowitz Computer Laboratory 6535 Fannin, M/S B409 Houston, TX 77030 Telephone (713) 790-3285 Date: October 10, 1985 Pageswapper Editor's comment I was under the impression that EDT does not use VMS foreign terminal support. Your best bet might be to hope that the TPU editor gets upgraded to do so, since if that were done you could use the EDT emulator in TPU. VAX-36 PAGESWAPPER - December 1985 - Volume 7 Number 5 INPUT/OUTPUT INPUT/OUTPUT 474 Caption: DRV11-JP driver for MicroVAX Message: I am interested in obtaining a device driver for the DRV11-JP module in a MicroVAX II running MicroVMS. Contact: Jeffrey A. Mathews, D450B The Goodyear Tire and Rubber Company 1144 East Market Street Akron, OH 44316 Telephone (216) 796-6617 Date: October 11, 1985 INPUT/OUTPUT 475 Caption: Determining physical CPU on a homogeneous cluster Message: At the Spring 1985 DECUS Symposium, I asked a Q/A panel how one could determine on which physical CPU of a homogeneous cluster he was executing. This is helpful for hardware error detection, mounting devices remotely, etc. Nodename is not the answer on our cluster because we may reshuffle software systems (nodes) on the cluster at any time. No really satisfactory answer was given at the Q/A session. Several people expressed the same interest to me, but I have since lost their cards. I have written a simple command procedure which accomplishes this very nicely by capturing the CI Port Number. If you would like a copy, let me know. Contact: Robert Benner Lukens Steel Company ARC Building Section A700 Modena Road Coatesville, PA 19320 Telephone (215) 383-3010 Date: October 14, 1985 VAX-37 PAGESWAPPER - December 1985 - Volume 7 Number 5 INPUT/OUTPUT INPUT/OUTPUT 476 Caption: VMS 4.2 Upgrade Problem Message: We have an 11/750 with 2.75 Mb and an RA80. We are currently running VMS V4.1 and had no problems at all upgrading to 4.1. We have tried many times now to upgrade to V4.2, and every time the upgrade procedure hangs in Phase I at the point where it says: "Working on files in [SYS0.SYSLIB]. HELP! Contact: Allied Corporation Bendix Kansas City Division Attention: Brad Gault, D/922, MC45 Post Office Box 1159 Kansas City, Missouri 64141 Telephone (816) 997-2037 Date: October 21, 1985 VAX-38 PAGESWAPPER - December 1985 - Volume 7 Number 5 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 PAGESWAPPER - December 1985 - Volume 7 Number 5 INPUT/OUTPUT Submission Form Tear out to submit an I/O item Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA PAGESWAPPER - December 1985 - Volume 7 Number 5 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 - December 1985 - Volume 7 Number 5 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA