May, 1988 Table of Contents From the Chair. . . . . . . . . . . . . . . . RST-2 From the Editor . . . . . . . . . . . . . . . RST-2 Cincinnati Symposium Session List . . . . . . RST-3 1987 RSTS SIG Tape Copy now Available . . . . RST-4 Fall 1987 RSTS Wish List Responses. . . . . . RST-5 Why You Can't Manipulate DCL SYmbols. . . . . RST-15 Hardware Update Bulletin. . . . . . . . . . . RST-16 Software Performance Report (SPR) Log . . . . RST-16 =============================================================== From the Chair Charles W. Mustain RSTS SIG Chairman A new generation of RSTS managers are meeting the challenges of their new jobs without benefit of the rich RSTS culture we "old timers" enjoyed. Gone are the RSTS Professional magazine and the CACHE BUFFER newsletter which was once sent to every DECUS member expressing an interest in RSTS. Both publications were filled with how-to articles, technical tips, letter columns, new utilities, and discussions about what's new in RSTS. Our SIG Editor, Terry Kennedy, is bringing to the RSTS pages of this newsletter all those "cultural" benefits for the RSTS community. There is, however, a small problem (pun intended). Only a very small part of the RSTS community in DECUS receive the SIGs NEWSLETTERs. This is no doubt in some part due to our SIG's past record of not publishing regularly. We believe that Terry has resolved this problem. We now need your help in spreading the word to the RSTS community. When you speak to other RSTS users, at LUG meetings, at Symposia, or to consulting clients, wherever, please make them aware of the revitalized newsletter. Carry the message that it is available to them as a source of information and as a place for sharing problems, solutions, neat bits of code, and general RSTS hints and kinks. We know from surveys that there is a large RSTS community. We know that this includes many people new to RSTS using versions ranging from 5c to 9.5. With your help in spreading the word, your help in contributing articles and sharing insights, this newsletter can provide a meaningful service to all of us who use RSTS, DEC's friendliest operating system. NEXT MONTH: Why upgrade to the latest version of RSTS? =============================================================== From the Editor Terry Kennedy It's Spring again (or will be by the time you read this), and that means it's time for another Symposium - this time in Cincinnati. As usual, the SIG has a full set of sessions scheduled. As I've mentioned before, a Symposium is an event not to be missed - if you can get your company to send you, great - if not, you might seriously consider taking the time as vacation and going anyway. However, if you can't make it, we'll be bringing you coverage of the high points in the RSTS Newsletter. This month, we have a condensed abstract of the combined Spring/Fall 1987 RSTS SIG Tape Copy tape. This tape contains submissions from users like yourself. If you have some handy programs or information related to RSTS, feel free to submit it to our Tape Copy Coordinator, Franklin Mitchell (See the article itself for more details). The entire tape is on-line on the RSTS Newsletter system at (201) 915-9361. We also have Digital's responses to the Fall 1987 RSTS wishlist items in this issue. Special thanks to Ginger Landry, RSTS/E Product Manager, and the entire RSTS development team for their time in preparing these responses and agreeing to share them with us. Since the how-to form has been removed, here is how to contact me for submissions, etc.: Via US Mail: Via UPS, FedEx, etc.: Terence M. Kennedy Terence M. Kennedy St. Peter's College St. Peter's College Department of Comp. Science Department of Comp. Science 2641 Kennedy Blvd. 121 Glenwood Avenue Jersey City, N.J. 07306 Jersey City, N.J. 07306 (201) 435-1890 (201) 435-1890 You may electronically submit material by calling the RSTS SIG bulletin board system at (201) 915-9361, or you may reach me as user KENNEDY on both DCS and DECUServe, if you have access to either of those systems. You may submit material on RX50's or RX33's (in RSTS or RT11 format), on 800, 1600, 3200, or 6250 BPI 9-track tape (in DOS, ANSI, BRU, RSTS BACKUP or VMS BACKUP format), or on PC-DOS floppies (54 or 32 inch format). If you are really desperate, I can also accept RSTS or RT11 format RL02 and RK07 disks. You may also submit hardcopy documents, but these will take longer to get into print. =============================================================== Cincinnati Symposium Session List Session Day Time Title RS016 Mon 9:00 AM RSTS Roadmap RS002 Mon 9:30 AM RSTS Announcements RS003 Mon 12:00 PM RSTS V9.6 Tech Changes RS028 Mon 12:30 PM EMT calls from BP2 RS005 Mon 1:30 PM What is RSTS/E LAT? RS022 Mon 2:00 PM RSTS/VMS Compatibility Manual RS006 Mon 3:30 PM PBS Overview RS004 Mon 8:00 PM Intro to RSTS Optimization RS019 Mon 9:00 PM RSTS Performance Tuning RS029 Tue 11:00 AM RSTS V8 Q&A RS010 Tue 12:00 PM Resident Libraries RS025 Tue 2:30 PM RSTS Tech Tips I RS011 Tue 3:30 PM VMS System Mgt. for RSTS Sys. Mgrs. RS012 Tue 5:00 PM File transfer RSTS to VMS RS020 Wed 9:00 AM RSTS Internals Update RS017 Wed 10:00 AM RSTS SIG tape / library RS001 Wed 10:30 AM RSTS System Modifications RS015 Thu 9:00 AM DECnet/E Programming RS007 Thu 10:00 AM Terminal Services RS009 Thu 11:00 AM RSTS RMS-11 RS030 Thu 12:00 PM Security for RSTS/E systems RS026 Thu 1:00 PM RSTS Tech Tips II RS013 Thu 3:00 PM RSTS/VMS BASIC Conversion RS014 Thu 5:00 PM RSTS/VMS Q&A RS018 Thu 9:00 PM Asynch I/O from BP2 RS021 Thu 10:00 PM RSTS/E Interprocessor Link RS008 Fri 11:00 AM BACKUP for System Managers RS023 Fri 12:00 PM RSTS Wish List RS027 Fri 1:30 PM RSTS SIG Wrap-up Related Sessions of Interest: Session Day Time Title LT031 Mon 11:15 AM PDP-11 Language Status/Futures RX004 Mon 4:30 PM PDP-11 Futures - User's View RX003 Mon 6:00 PM MSD Meets DECUS [Ed. Note: MSD is the organization within Digital re- sponsible for the current PDP-11 product line.] =============================================================== 1987 RSTS SIG Tape Copy now Available * * * * * * 1987 Nashville/Anaheim RSTS SIG Tape. * * * * * * Please share your RSTS "goodies" with the RSTS SIG. Please send your 1988 RSTS SIG Tape submissions to Franklin Mitchell (DCS MITCHELLF) RSTS SIG Tape Copy Erskine College 1 Washington Street Due West, SC 29639-0086 Preferred tape density/format is 1600 BPI mag tape in DOS format. V9 BACKUP format is also accepted but please no V8 BACKUP tapes. Other media can be accepted with some delay for conversion. Please enclose a DECUS "Tape Copy Release Form" with your submission. A "Tape Copy Release Form" is in each Fall/Spring DECUS Symposia announcement or you can get one from me at the address above. What to submit? See the examples included on this tape! Submit only your work. I.E., if you have modified a DEC CUSP, submit only the changes, not the whole CUSP. This tape contains the following: Account Who What ------- --- ---- 87, 0 RSTS SIG This file+MT.LST directory 87, 1 DEC RSTS Development Example .COM files, etc. 87, 2 Erskine College Goodies 87, 3 Mike Mayfield Goodies 87, 4 Brian Nelson, Univ of Toledo CLE 87, 5 Brian Nelson New CLE 87, 6 The Univ. of Toledo Kermit 11 87, 7 The Univ. of Toledo Kermit for various PC's 87, 8 Ed Moran, Horace Mann School Pascal library routines 87, 9 James B. Wilkinson TYPE 87,10 Terry Kennedy, St Peter's DECUS C 87,11 Terry Kennedy College Fortune Cookie program 87,12 Terry Kennedy Cookie data 87,13 Terry Kennedy Cookie data 87,14 Terry Kennedy Back issues of newsletter 87,15 Terry Kennedy System utilities 87,16 Terry Kennedy DEC MAIL utilities 87,17 Terry Kennedy MS DOS Kermit 2.30 87,18 Terry Kennedy Games 87,19 Gene Alpern Directory of all past RSTS SIG tapes. Most accounts contain a README.TXT document with additional information. =============================================================== Fall 1987 RSTS Wish List Responses [Ed. note - this is a transcription of the supplied wishlist forms, combined with Digital's written responses. I apologize for any typographical errors which may creep in... Also, I have added some information (in brackets) where I thought it might prove useful.] W1) DECnet/E - Add a VMS-compatible proxy login to DECnet/E. Reason: Many RSTS/DECnet sites are managed by a common staff (multiple systems, 1 manager). The day-to-day copying of files currently requires the account and password to be supplied each time. This is a lot of typing and is also a security opening. A1) This is an excellent idea. We are currently investigating many different options in this area. Technically, this is a difficult problem (Tech. 3). While the actual implementation may be relatively small, a lot of effort must be expended researching and resolving the myriad security issues that a proxy login feature implies. Providing this feature would be very valuable to RSTS/E and DECnet/E, for exactly the reasons that were already stated with submission of this wish (Prod. 1). W2) DECnet/E - Add support for the NFT /BL qualifier to the DCL copy command, or better still, to have DCL append it automatically. Reason: Many files require the /BL switch to successfully transfer across the net. DCL does not generate or support this switch. Therefore, users must know both the DCL and NFT commands. A2) We are looking at ways with the architecture committee to remove the need for /BL entirely. (Tech. 1, Prod. 2) W3) Asynch DECnet! Reason: Good idea! A3) We hope to be able to commit to provide this feature in some future release of DECnet/E. (Tech. 3, Prod. 1) W4A) RMS-11 - Asynchronous I/O capability for RMS, especially with the "get next key" directive. Reason: Would improve performance of typical RMS processing for report generation or similar applications. W4B) RMS-11 - Asynch I/O as in RSX A4) This capability would require more than minimal effort. Hence we do not expect it will happen in the near future. (Tech. 2, Prod. 2) W5) Executive - Add supervisor mode library support, as in M & M-plus. For user built libraries + system libraries such as RMS. A5) This is a good idea and has been requested in the past. We are investigating this feature. (Tech. 2, Prod. 2) W6) Executive - More than 65536 disk clusters. Reason: Less waste. A6) This is also a good idea, however it would require a major re-write of FIP therefore it is very low on our priority list. (Tech. 3, Prod. 3) W7) Executive - Allow a default disk to be defined for each account. Reason: Continually specifying a disk name is tedious and prone to error; using multiple disks for the public structure significantly degrades performance. A7) Although this is a good idea, it is technically hard to implement. (Tech. 3, Prod. 2) W8) Executive - Ability to specify a KB using the new interface style designation like KBG12: in all those SYS() calls that ask for an integer KB number. At least give us a simple SYS() call that would take the string "KBG12:" and return the integer KB number. Reason: I bought a new terminal interface and had to modify and recompile seven million programs. A8) Done in FSS - SYS(CHR$(6%)+CHR$(-10%)+...) (Tech. 0, Prod. 0) W9) Executive - In FSS, allow the '*' character to complete a name or type field for wildcard lookup. The exec could simply convert the '*' to multiple '?'s. Leading *'s could be disallowed for ease of implementation. Reason: DIR A*.BAS is easier than DIR A?????.BAS A9) We will take this into consideration in the future. (Tech. 1, Prod. 1) W10) Executive - Would like a system service to get/put DCL symbol definitions like VMS LIB$GETSYMBOL and LIB$PUTSYMBOL. Also, LIB$DOCOMMAND (hope, hope!) Reason: Many user applications are being done in DCL and more and more higher level languages need to interface with DCL. Reading and writing intermediate files to communicate is a hack! A10) We consider this difficult to do therefore it is currently a low priority item. (Tech. 3, Prod. 2) [Ed. note - with enough spare time, it *is* possible to figure out how to read symbols from a program. Writing them is substantially more difficult. One of the major problems is that since the method involved is undocumented, it changes from revision to revision (radically!). I had it figured out for 9.1, but never updated it for later versions.] W11) Executive - Allow large files to be accessed without excessive window turning. Reason: Files that require several retrieval windows, even at cluster size 256, could be optimized. Suggest a cluster number/block count double word type of retrieval entry similar to ODS format. A11) Good idea - we've had this one on our list, but with a method that won't change on-disk structure. (Tech. 3, Prod. 1) W12) Executive - Improved performance from the scheduler. Reason: Scheduler overhead has become a significant overhead on large memory, heavily loaded systems. A12) We are looking at ways to further optimize it. (Tech. 3, Prod. 2) W13) INIT - Allow INIT to format and place a RSTS file structure on an RX33 diskette as a 1-step operation. Reason: 1) This will prevent users from wiping out the RDxx with the diagnostics! 2) This collects all the preparation steps for RX33 media (which DEC supplies only in unformatted mode) in one convenient location. A13) We are investigating the possibility of enhancing the DSKINT option of INIT to allow for the formatting and initialization of RX33 diskettes for some future release of RSTS. W14) DCL - Faster DCL Reason: It's too S L O W A14) This is an ongoing process. (Tech. 3, Prod. 1) W15) DCL - Use symbols as in VMS: $ DOIT=="$FOO.EXE" $ DOIT param1 param2 (almost like user CCL) Reason: User defined CCL's / VMS compatibility A15) Good idea, but we couldn't make it VMS compatible and compatible with current DCL. (Tech. 3, Prod. 1) W16) DCL - Wildcard like VMS Reason: VMS compatibility A16) We are investigating this to see what can be done, if anything. (Tech. 3, Prod. 3) W17) Define values for escape, linefeed, return, etc. within DCL. Reason: We use several "bold" prompts on video terminals and are forever defining escape of one form or other, using it once and clearing it out. A17) It is better that only the people who need it, define it themselves rather than increase everyone's symbol table overhead. (Tech. 2, Prod. 3) [Ed. note - We have a program called 'spit' which checks the terminal attributes first, and then performs the necessary prompting, for example: SPIT BOLD,"Enter option",NORM] W18) DCL - Help more like VMS, where one can enter the subtopic at "press RETURN to continue..." Reason: VMS compatibility A18) Good idea. Not as easy as it sounds. (Tech. 2, Prod. 2) W19A) DCL - Here's a little one - how about being able to repeat the last line input (to DCL) with minimal editing? W19B) DCL - Allow interactive cmd. editing & retrieval of the last 10 (or 20) cmnds. W19C) DCL - Command line editing in DCL. (This is more important to me than LAT support). W19D) DCL - It seems to me that it would be nice if you could recall the last few commands you had typed. I've seen it in VMS. A19) This is a very nice feature. It would be hard to do and require major work in TERSER. Also potential large increase in memory usage. (Tech. 3, Prod. 2) [Ed. note - This is available in the CLE package in the '87 SIG tape. Be sure to get the one that doesn't require elevated privileges (That's the one in the [87,5] account). W20) DCL - REMOVE/JOB=9/QUERY would print a SYSTAT-like line and ask "Really remove?" Reason: I don't want to kill the wrong job. A20) Good idea. We will look into this sometime in the future. (Tech. 2, Prod. 1) W21) DCL - Exit with no prompt Reason: Same uses as Basic-Plus's exit with no prompt. A21) At some point in the future, we will look into this. (Tech. 2, Prod. 2) W22) Enhance the SET command by giving the /QUERY capability to more of the SET commands. A22) Good idea. We will consider this sometime in the future. (Tech. 2, Prod. 1) W23) For SHOW QUOTA, the ability to specify at least: a PPN, better: a wildcard PPN, best: A PPN range. A23) Good idea. We will commit to this in a future release. (Tech. 1, Prod. 2) W24) DCL - New DCL command: SET SYSTEM/NOBULL[DOG] A24) We like /BULL_DOG but not /NOBULL_DOG! How about /NO_CHESHIRE_CAT? (Tech. 1, Prod. 1) W25) DCL - Please provide documentation/examples of more complicated DCL procedures - currently each function is detailed but very little attention is given to how to actually use them. A25) Good idea. We will consider this sometime in the future. [Ed. Note - RSTS Engineering usually gives a talk on 'Advanced DCL' at Symposia. You could order the audio tape (see the Symposium information packet). Also, the examples from that presentation (and others) are on the '87 SIG tape in account [87,1].] W26) DCL - Pass substituted symbols to programs (like VMS). Reason: 1) VMS compatibility 2) Eliminate generation of temporary command files by "main" .COM files. A26) Highly desirable, but very hard to do. (Tech. 3, Prod. 1) [Ed. note - See my article "Why you can't manipulate DCL symbols" right after this wishlist article.] W27) DCL - Don't charge the (sometimes large) DCL .TMP workfile to a user's disk quota. Reason: I'm tired of explaining several times a day to students why they can't log out even though DIR says they are below quota. A27) We are considering ways of resolving this issue. One method under consideration is placing all DCL .TMP files into one account, therefore the user is not charged for the disk space being taken up by that file. W28) DCL - Copy was /RETAIN Reason: The way it was (V8). Why did it change? A28) Changes was made for VMS compatibility. You are creating a new file, so the default should be /NORETAIN. (Tech. 1, Prod. 3) W29) PBS - Add an /APPEND switch to a /LOG_FILE= so we can append batch logs together. Reason: Reruns of batch jobs erase the previous log file and often fail because of other than the original problem. A29) This is a good wish and we will consider it for some future release of RSTS/E. (Tech. 2, Prod. 2) W30) PBS - Support PBS over DECnet Reason: To be able to print to a device on another node. A30) This has been a long-standing wish for PBS. We continue to keep it in the list and at some point will consider this when planning updates. (Tech. 3, Prod. 1) W31) PBS - Remove words like "entry" etc. from a show queue command and put in the form name instead. Reason: There is all sorts of information we need about the queue without having header info repeated on each line! A31) We have had a wish in the past for a selected SHOW ENTRY/BRIEF=( ) command. This would be more useful to a wide variety of customers. (Tech. 3, Prod. 2) W32) PBS - A way to initialize/set-up a printer before and/or after printing a job. A32) We are looking at it. In the meantime, you may want to try: Allocate device, PIP setup-file to it, Allocate device to PBS. (Tech. 3, Prod. 2) W33) RSX emulator - Allow RSX-style binary I/O (IO.RNE...) to KB: A33) Thank you for your suggestion. We will look at it (already have MODE 1% in RSTS-style I/O). (Tech. 2, Prod. 3) W34) RSX emulator - Memory-resident overlays Reason: Execution speed A34) It's in the manuals - TKB and MAKSIL explain how to create code only (read-only data) memory-resident overlays. (Tech. 0, Prod. 0) [Ed. note - You could also build a normally-overlaid task and run it from the virtual disk] W35) Backup package - Backup to handle command lines longer than 1024 characters. Reason: So we can include/exclude a sufficient number of files. A35) We will look at a way for you to select more files. (Tech. 1, Prod. 1) W36) Backup package - Have Backup create a bootable medium, or make SAVRES go faster on TK50's! A36) No future development in SAVRES. Use RECOVR.COM (Tech. 3, Prod. 1) [Ed. note - RECOVR.COM is documented only in the V9.0 Release Notes - it allows you to make a bootable tape which can then be used to restore BACKUP savesets. Also see the 1987 SIG tape, which has a routine to make combined DOS/ANSI (Bootable BACKUP) tapes.] W37) Backup package - Backup should produce some stats such as # tape errors/tape, last file written to each tape, elapsed time, etc. A37) We will look at this sometime in the future. (Tech. 2, Prod. 2) W38) Backup package - Backup should be able to use the same account wildcarding as ACTMGR: BACKUP DU0:[100-200,*]*.* FOO.BCK A38) At some point we will look at a way to select more files, maybe using ACTMGR's wildcarding. (Tech. 3, Prod. 3) W39) All - Don't let RSTS/E die! Reason: It's the best OS around! A39) RSTS has proven itself over the years and has a large dedicated customer base. Thank You for your investment... W40) All - Keep up the good work! A40) Keeping up the good work is a hard task. RSTS Engineering always tries to do what is best for the product and most of the time it is fun to do. Your job, which is also hard to do, is to keep us on the right track... W41) All - It appears we must convert or coexist with VMS if we are to tap any of the new products. RSTS/E has been and is a fine product meeting most of our needs in a very easy, friendly, secure way. My wish: Please so everything possible, with high priority to facilitate co-existence and conversion. A41) Digital is very concerned about continuing to meet the needs of its customers. For the RSTS customer, this need may mean coexisting with VMS or it may mean an eventual migration to VAXes. We are currently planning tools (i.e., RSTS/E - VMS Compatibility Guide) to assist our customers with the process of either coexisting or migration. Digital is actively supporting RSTS/E and will continue to provide quality releases with emphasis placed on features that provide improved compatibility with VMS. (Tech. 3, Prod. 1) W42) Other - LOGIN should have the ability to record all login attempts that fail to the "access denied" point. Reason: Security A42) Thank you for your suggestion. We will look at it. (Tech. 1, Prod. 1) [Ed. note - If you are running V9.x and not running OPSER, if you declare a message receiver named OPSER, it will receive all LOGIN/OUT console message traffic, which you may then store in a file and analyze. You may also have to modify LOGIN/OUT slightly to force logging for the job classes (local, dialup, net, etc.) you are interested in.] W43) Other - LOGIN.COM should be moved off [0,1] and onto an account which is smaller and can be REORDRed. A43) We do realize there is a performance problem with logging into the system and we are looking at ways to improve the performance. Until then, you can continue to use PIP's /MODE:1536 to put LOGIN.COM at the top of [0,1]. We have not heard why that would not be sufficient. (Tech. 2, Prod. 2) W44) Other - TERMGR should allow wildcards for KB #'s in the SET TERMINAL command. For example, SET TER KBG*:/AUTOBAUD /DIALUP. Reason: System startup is extended by having many (possibly) identical SET TER commands, reloading DCL & TERMGR for each one. This would speed up system startup. A44) Because TERMGR would have to go through all KB's, it is not certain if this would speed up system startup. Put a "RUN $TERMGR" command before the first SET TERM command. [Ed. note - The 1987 SIG tape has a utility which creates a patch file containing most system defaults. Once applied, you will not need to specify the defaults again.] W45) Add a /SORT=(NAME|TYPE|SIZE|DATE) switch to the DIRECTORY command. Combinations should be allowed: /SORT=(NAME,TYPE) would sort by name as primary and then by type. This would be the default if only /SORT was specified. Reason: It would make locating files in the directory easier. A45) Do a DIRECTORY/OUTPUT=file and then SORT the output file using the SORT command. (Tech. 3, Prod. 3) W46) Other: Facilities to help the visually impaired - SET DOUBLEHIGH/DOUBLEWIDE - Hooks and utilities for DECtalk. A46) This is a very reasonable request and it would be a nice feature. Thank you for your suggestion and we will keep it on file for future consideration. W47) Other - Ability to read the VAX CD disks - A handler or conversion program or both. (Tech. 3, Prod. 2) A47) You can hook up the CD disk to your VAX and copy the data across the network. (Tech. 0, Prod. 0) W48) Other - Directory should have the ability to get a list of files with only certain characteristics - in particular a public protection code, a priv protection code, and marked for caching. Reason: System tuning and security. A48) This is a good idea. We consider it difficult to do. (Tech. 3, Prod. 2) W49) Other - Is it possible to make SYSLIB.OLB (or reasonable parts thereof) into a resident library? A49) Too many layered products that are task-built would have to be changed to warrant making this change. (Tech. 3, Prod. 2) W50) Other - I would like to get the source for HELP so that I could customize it. It could be in SOURCE$: like SYSTAT and others. A50) You can do this by purchasing the source kit. [Ed. note - I think there was a small slip-up here. HELP was included in SOURCE$: for V9.0, but when it was updated (in 9.3) it was left off the update kit SOURCE$: account. According to a SPR answer I received, this will be corrected in the next release.] W51) Other - System callable routines for the creation / changing / deletion of symbols. A51) This is also technically difficult and falls low on our long priority list. (Tech. 3, Prod. 2) W52) Other - To have a class of terminals between local and dialup, for purposes of who can log in, and for whether LOGIN logs the attempts. A52) We hope to look at this for a future release. (Tech. 2, Prod. 2) [Ed. note - You can modify LOGIN/OUT to change the classes for which information is logged.] W53) Other - How about some way to quickly copy a tape to a TK50 and the other way too! A53) We do not understand this wish item. Please submit again with additional explanation. =============================================================== Why You Can't Manipulate DCL Symbols Recently there has been a good deal of discussion about why you can't manipulate DCL symbols from with a (non-DCL) program. The following is a somewhat technical summary of the problems involved, as well as a pointer to some references if you really want to try it. Please remember that the opinions stated in it are my own, and don't hold DEC responsible for any errors. RSTS DCL attempts to emulate VAX/VMS DCL in dealing with symbols. For applications coded entirely within DCL, it does admirably well in this emulation. However, users familiar with the VMS library routines for DCL symbol manipulation frequently wonder why RSTS/E doesn't support such routines. T H E R E A S O N: VMS supports a vastly larger address space for user programs. Therefore, giving up 'N' K for DCL symbols has utterly no effect. Similarly, the routines to manipulate the symbols can be contained in user address space without constraining the size of a user's program. However, on RSTS, users are squeezed against the hardware limit of 32Kw of instructions. Therefore, a design decision was made to place the DCL symbol table (and other context) in a workfile when DCL was not the current run-time system. There were significant technical hurdles involved, mainly centered around not wanting to force the user to give up a channel for the workfile. The end result was to create a new set of 16 channels *just* for DCL' use. This is where the .COM file nesting depth limit comes from, and also explains why you give up a nesting level when using a logfile. These new channels can be opened, closed, read & written to, and SPEC'd just like normal channels. The only difference is where the channel information is kept. A new system call (UUO.PFB) was created to swap these channels back and forth between 'user context' and 'system context'. Now that you know where it is and how to access it, you might be tempted to try looking for symbols in the workfile. The next problem you will have is 'what is the format of all this stuff?' If you define some text symbols, you may discern some sense of the format. The easiest thing to do would be to use the DCL symbol manipulation routines, no? Unfortunately, you would have to switch run-time systems to get to these routines. Currently there exists no mechanism for preserving program context across such a switch (ever type HELP from within BASIC-Plus and lose your program?). So, the next idea you get is to incorporate these routines into your program. Unfortunately, your program is now too big to fit in the 32Kw limit! And that, in a nutshell, is why you can't manipulate DCL symbols from within application programs. =============================================================== Hardware Update Bulletin This section covers hardware updates pertaining to RSTS/E systems. The only news this month is that various type of power controllers may have incorrectly rated power cords. Apparently, the problem only manifests itself in fully-loaded RA81 cabinets. A quick way to tell if you have the problem is to look for 12 gauge wire (20 Amp rating) with a 30 Amp power plug. =============================================================== Software Problem Report (SPR) Log Please send the newsletter editor copies of any SPR's (and Digital's answer) on RSTS/E, DECNET/E, or RSTS layered products. We will print any that are of general interest. The reason for this is that many SPR's are answered with a patch or a notice of restriction, but due to space considerations, they are not published in the Software Dispatch. Since we're desperate for material, this should be useful information and we will print it. The Newsletter system will be expanded in the near future to allow bulletin-board style messages to be posted for users to exchange this information, which should make it much more timely.