Table of Contents From the Editor . . . . . . . . . . . . . . . RST-2 Letters to the Editor . . . . . . . . . . . . RST-3 Terminal Interface Tips . . . . . . . . . . . RST-10 Hardware Update Bulletin. . . . . . . . . . . RST-11 Software Update Bulletin. . . . . . . . . . . RST-11 Software Performance Report (SPR) Log . . . . RST-11 =============================================================== From the Editor Terry Kennedy This is a monthly newsletter, honest! It's just that sometimes Murphy gets in the way. Last month we had some real zingers - more on that later. I've collected a backlog of articles now, so I will have an 'emergency' newsletter ready to go if it is needed. Therefore, you should see us in these pages every month from now on. (Oh no, now I've done it - I wonder what will happen next month!...) Anyway, normally I wouldn't go into what sort of computer problems I may have here, but this past month's problems affected many of you by making me miss the newsletter deadline, and also by causing me to be late sending my contribution to the Tape Copy project. Well, the tape has been sent, so you should hear more about it soon - I'll try to print the directory in the next issue or two. So, here's what happened: I had been noticing assorted console error messages on my main 11/44 system, little things like (uStep CP) and (Halted). So, I called my field service rep (whose name and company will remain nameless). He came out with a replacement board and installed it. The new board gave the message (CP didn't start), which indicates a hung bus. Oh well, time to order another spare. Next day, the spare arrived and was installed. Things looked good, and the rep left. Meanwhile, I commenced editing the material for the tape copy project. When I returned from dinner, one of our users said the system was running very slowly. A quick look at the DISPLY output showed over 2000 errors logged. Upon trying to log in, I was greeted with the error message '??Fatal system I/O failure'. Oh no, I thought - something is *really* wrong now. Called field service again, and was told 'that incident is closed - you'll have to wait till tomorrow for service'. Oh well, we closed up shop early and went home. The next day, another rep arrived with a replacement board. Changed board, got (CP didn't start) again. Rep said problem wasn't in that board, would have to pull all cards from bus and try again. I replied that that was silly, and pulled the same board from another '44 and he tried that. System ran, but wouldn't boot the disk. Rep mumbled something about a run of bad boards and left to find another one. This went on until the original board had been replaced seven times, over a period of a week. Repeated calls to the company's corporate complaint line were answered with comments that the local branch was doing the best they could, and why was I so upset. No-one seemed to consider seven bad boards in a row an unusual occurrence. The seventh board was also defective, but I convinced the rep that ordering another one was equally useless, and I replaced the defective switch on it. After all that was done and the rep ejected, I discovered that the failed board had wiped the format off my disk drive. A not-so-quick reformat of my 500Mb drive and a restore from my backup tapes got us back in business, except for the tape copy work in progress. We immediately canceled our service agreement with the vendor and initiated a contract with another. As an academic institution with no 'business' users and a redundant 11/44 system, it did not have a major impact on our site. If you are a small business user, though, you should consider carefully the impact a week of no computer use would have on your business, and make appropriate contingency arrangements. These could be as simple as an agreement with another site to share systems in the event of a failure, all the way to contracting with a commercial disaster recovery firm for a dedicated system. 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. =============================================================== Letters to the Editor This month we have two articles from the same reader! (Hint, hint...) Paul Flaherty has supplied two routines which should be helpful to RSTS DIBOL users, and can be modified for other tasks as well. Paul writes: In my account is a file REQUE.COM, a DCL command file which other RSTS users may find useful. [Ed. note - this file is now in the download area (account [49,1]) on the Newsletter System.] Some sites (particularly RSTS/DIBOL sites, like us) are still locked into using the OPSER package for printer spooling for some applications. This routine, which runs under PBS control at a preset interval (or on demand for users with WACNT privilege), can eliminate the need for SPOOL to be running in most instances. (OPSER and QUEMAN still have to run, however). It takes a full queue listing (Q/L) and extracts the appropriate information to submit the print jobs to PBS. The current restrictions are: 1. It only looks at the LP0: queue. A loop could easily be "wrapped around" this routine, however, to process queues LP0: through LP7:. 2. It does not honor the "status" of the queue entry, i.e., if the entry is on "hold", it will not be held by PBS. However, if SPOOL is not running and this routine is only used in conjunction with applications which submit print jobs to OPSER, and users only use PBS for direct submission of print jobs, it's unlikely that an entry would be "on hold". 3. If a job is submitted to OPSER with a form name that is not defined in PBS$:FORMS.SYS, it will cause problems, and entries in the queue after it will not be processed until it is removed or modified, or the form is defined in PBS$:FORMS.SYS. The advantages are: 1. Saves memory and at least one job slot. 2. Prevents most opportunities for jobs to print on the wrong form, since only one spooler is in control of the output device. I hope this is helpful to some newsletter readers. - Paul $ ! REQUE.COM - requeues OPSER print entries to PBS. Runs under $ ! batch control (in which case it resubmits itself $ ! to run an hour later ) or on $ ! demand for a user with WREAD privilege (to insure $ ! that the user has read access to all files to be $ ! printed). $ ! Author: Paul F. Flaherty, Jr. $ ! DANIELS AND CRONIN $ ! Three Center Plaza $ ! Penthouse Mezzanine $ ! Boston, Massachusetts 02108 USA $ ! Check for WREAD privilege. If not present then exit. $ _if f$priv("WREAD") .nes. "" then _goto PRIVS_OK $ _write 0 "?WREAD privilege required" $ _exit $ ! Close the initial log, if any. Open a new log called Q.DAT, and make $ ! it contain a full listing of the contents of LP0: queue. Initialize $ ! a couple of integer symbols. Close Q.DAT, then reopen it for reading. $ ! Set an simple error/warning trap. $PRIVS_OK: $ _close/log_file $ _open/log_file/replace Q.DAT $ _ccl Q/L $ _close/log_file $ POS = 0 $ POS1 = 0 $ _open/read 1 Q.DAT $ _on warning then _goto ABBY_NORMAL $ ! Read records from Q.DAT until either "IS EMPTY" or "/SE:" is found. $ ! The former indicates nothing to do, the later indicates we've found $ ! the first record in which we're interested. $CHECK_FOR_NO_DATA: $ _gosub READ_RECORD $ POS = f$instr(1,QUE_DATA,"IS EMPTY") $ _if POS .ne. 0 then _goto NO_MORE $ POS = f$instr(1,QUE_DATA,"/SE:") $ _if POS .ne. 0 then _goto GOT_ONE $ _goto CHECK_FOR_NO_DATA $ ! This is the main processing loop. The first time through we've already $ ! got a record so we skip to the GOT_ONE routine, but after the first $ ! we go through here each time. There are at least three records we $ ! have to read for each queue entry. We are interested in entry name, $ ! owner and form name from the first record, nothing from the second $ ! record, and from the third and possibly succeeding records, file names, $ ! number of copies, and the delete switch. Also, we check to see if the $ ! file to be printed still exists, and if it doesn't we simply remov $ ! OPSER queue entry and continue. $MAIN_LOOP: $ _gosub READ_RECORD $ POS = f$instr(1,QUE_DATA,"/SE:") $ _if POS .eq. 0 then _goto MAIN_LOOP $GOT_ONE: $ ENTRY = f$mid(QUE_DATA,3,POS-3) $ POS = f$instr(1,QUE_DATA,"/FO:") $ _if POS .eq. 0 then _goto ABBY_NORMAL $ FORM_NAME = f$right(QUE_DATA,POS+4) $ POS = f$instr(1,QUE_DATA,"[") $ POS1 = f$instr(POS,QUE_DATA,"]") $ OWNER = f$mid(QUE_DATA,POS,(POS1-POS)+1) $ _read 1 QUE_DATA $GET_FILE_NAMES: $ _gosub READ_RECORD $ QUE_DATA = f$edit(QUE_DATA,2) $ _if QUE_DATA .eqs. "" then _goto MAIN_LOOP $ COPIES = "1" $ DELETE = "" $ POS = f$instr(1,QUE_DATA,"/C:") $ POS1 = f$instr(1,QUE_DATA,"/D") $ _if POS1 .ne. 0 then DELETE = "/DELETE" $ _if POS .eq. 0 then _goto DO_NAME_NOW $ _if POS1 .ne. 0 then COPIES = f$mid(QUE_DATA,POS+3,((POS1-1)-(POS+2))) $ _if POS1 .eq. 0 then COPIES = f$right(QUE_DATA,POS+3) $DO_NAME_NOW: $ _if POS .eq. 0 .and. POS1 .eq. 0 then FILE_NAME = QUE_DATA $ _if POS1 .ne. 0 then FILE_NAME = f$left(QUE_DATA,POS1-1) $ _if POS .ne. 0 then FILE_NAME = f$left(QUE_DATA,POS-1) $ _if f$search(FILE_NAME) .eqs. "" then _goto FILE_NOT_FOUND $ _print/form='FORM_NAME'/copies='COPIES'/owner='OWNER''DELETE' 'FILE_NAME' $FILE_NOT_FOUND: $ _ccl q/k 'ENTRY' $ _goto GET_FILE_NAMES $ ! Here is the subroutine where we do the actual read and reformat $ ! of the records. $READ_RECORD: $ _read/end_of_file=NO_MORE 1 QUE_DATA $ QUE_DATA = f$edit(QUE_DATA,444) $ _return $ ! General error trap. Notify humans that an error occurred and append $ ! Q.DAT to the message. By comparing Q.DAT to the current state of the $ ! LP0: queue, a good guess can be made as to where the error occurred $ ! and how to recover. $ABBY_NORMAL: $ _on warning then _exit $ _close/all $ _open/write/replace 1 REQUE.ERR $ _write 1 "" $ _write 1 "==============> R E Q U E . C O M E R R O R L O G" $ _write 1 " ===================================" $ _write 1 "" $ _write 1 "An error or warning occurred while processing the following" $ _write 1 "QUEUE listing in REQUE.COM. Please have the system manager" $ _write 1 "compare this listing with the current queue to determine" $ _write 1 "recovery procedures." $ _write 1 "" $ _write 1 "" $ _close 1 $ _append Q.DAT REQUE.ERR $ _print REQUE.ERR $ ! If running under PBS control resubmit to run again later, close file(s), $ ! get rid of Q.DAT, and exit. $NO_MORE: $ _if f$access() .eqs. "BATCH" then _submit/after=+1HOUR PBS$:REQUE.COM $ _close/all $ _delete/noconfirm/nolog Q.DAT $ _exit ========================= In my account is a file called CNAME.MAC. [Ed. note - this file is now in the download area (account [49,1]) on the Newsletter System.] It is a Macro-11 subroutine callable from DIBOL (version 5) under RSTS/E, which allows a running DIBOL program to change its SYSTAT name. I find it particularly useful in keeping track of large programs with lots of overlaid subroutines. It may be useful to some of the other newsletter readers. Feel free to make it available. - Paul ;+ ; ; File CNAME.MAC ; ;- .include /SY:[1,2]COMMON.MAC/ .title CNAME .ident /1.0.0/ .psect $CNAME ;+ ; ; Author: Paul F. Flaherty, Jr. ; DANIELS & CRONIN ; Three Center Plaza ; Penthouse Mezzanine ; Boston, Massachusetts 02108 USA ; (617) 227-5570 ; ; Date: June 29, 1987. ; ;- ;+ ; ; Program description ; ======= =========== ; ; This is a MACRO-11 subroutine written in conformance with the Digital ; Equipment Corporation document entitled "Writing MACRO Subroutines for ; RSTS/E DIBOL V5.1." It is used to change the program name of a running ; job, with .FSS used to load the FIRQB with the appropriate RAD-50 characters, ; and .NAME used to do the actual change. It is called from a DIBOL program in ; the format: ; ; | alpha record | ; XCALL CNAME (| alpha field |) ; | alpha literal | ; ; where the argument passed is the desired program name. ; ; Passing more or less than one argument will cause a fatal DIBOL error 6. ; Passing a null string will cause no change in the name. Only the first ; six characters of the passed argument are used. ; ;- ;+ ; ; Restrictions ; ============ ; ; Since we use .FSS to load the FIRQB, we cannot include things like ; dollar signs and periods in the name, e.g., a name like ...EDT won't ; work. The load of the FIRQB could, however, be recoded to handle such ; names. ; ;- ;+ ; ; N.B. The same functionality is available to DIBOL programs by using the ; Digital supplied (unsupported) subroutines FSS and EXEMT located in ; LB:UNSUPP.OLB in the form: ; ; | alpha record | ; XCALL FSS (| alpha field |,dfield) ; | alpha literal | ; ; XCALL EXEMT (dfield,104044) ; ; where the alpha argument is the desired program name, as above, dfield is ; a three character decimal field for the return of any possible error code, ; and 104044 is the Octal EMT for a .NAME directive. ; ;- ;+ ; ; Revision History ; ======== ======= ; ; When Who What ; ---------------------------------------------------------------------------- ; 29-June-1987 PFFJr Initial source ; 23-July-1987 PFFJr Added description of the use of XCALL FSS and ; XCALL EXEMT to achieve the same functionality ; ;- top9=177600 ;used to clear nine high order bits cname:: cmp (r4)+, #2 ;one argument? beq 10$ ;yes, continue trap 6.+200 ;no, trap to DIBOL with fatal error 6 10$: mov #2, r1 ;argument read only, for literals trap 0 ;pop it off the DIBOL stack cmp r0, #0 ;size gt 0? bgt 20$ ;yes, continue rts pc ;no, so just return to DIBOL 20$: clr r3 ;clear for use in 30$ mov r1, -(sp) ;save r1 cmp r0, #6 ;size le 6? blos 30$ ;yes, continue mov #6, r0 ;no, so make it 6 30$: inc r3 ;check for blanks (legal but useless) cmp r3, r0 ;beyond size of argument? bgt end ;yes, therefore it's all blanks movb (r1)+, r2 ;no, so check for space bic #top9, r2 ;clear all but 7 low order bits cmp r2, #40 ;is it a space? beq 30$ ;yes, check next mov (sp)+, r1 ;restore r1 (location pointer) mov #xrb, r3 ;now clear the xrb, first point to it 40$: clr (r3)+ ;clear a word cmp r3, #xrb+14 ;see if done blos 40$ ;not yet, try again mov r0, xrb+xrlen ;load string length into the xrb mov r0, xrb+xrbc ;ditto mov r1, xrb+xrloc ;load string location into the xrb mov #firqb, r0 ;now clear the firqb, first point to it 50$: clr (r0)+ ;clear a word cmp r0, #firqb+36 ;see if done blos 50$ ;not yet, try again .fss ;do the .fss (which loads the firqb) .name ;do the name change end: rts pc ;return to DIBOL .end =============================================================== Terminal Interface Tips A frequently asked RSTS question at Symposia is "Why do we occasionally get LOGIN looping on a terminal, and how can we kill it - simply killing the job doesn't seem to help?" There are several causes of this problem. The first is the case where a user turns off the terminal before BYE has completed typing the logoff message. The second comes from running cables longer than the specified maximum length, or from using poor-quality cables. The third possibility is marginal or defective hardware (the terminal interface in the CPU). Because of the way the RS-232 interface works, the data line from a powered-off terminal is neither at a 0 level or a 1 level. It is at an undefined middle ground. On long cable runs, or in electrically noisy environments, this line may pick up enough noise from either the other data line in the cable or from outside noise to trigger LOGIN on the system. LOGIN then prints the user prompt, which is reflected back to the system as more noise, and the problem loops forever. There are several ways to attack the problem. The easiest is simply to set all terminal lines to /PERM/AUTOBAUD under RSTS V9. Since autobaud requires two carriage returns in a row to start LOGIN, it is unlikely for noisy lines to cause problems, because the noise almost never appears as valid data. The next way is a hardware solution. Note that it will certainly void any warranty you have, and should only be approached as a last resort. From the discussion above, we saw that the problem stems from noise induced in the terminal cables. If we apply a small 'bias voltage' on the receive data lines on the terminal interface (such as a DZ11), we can prevent the noise from triggering LOGIN. We need to use a part which will put the required voltage on the input data line, but not enough to cause valid data from the terminal to be ignored. I have used 5.1K 1/8W resistors in the past with good results, soldered directly to the 1489 RS-232 receivers on the DZ11. If this means anything to you, you might want to try it. On the other hand, if this makes no sense, you shouldn't try it. =============================================================== Hardware Update Bulletin In the last issue, I reported several FCO (Field Change Order) kits for various devices. In response to your requests, here are some more FCO's for the TU80: o TU80 'hangs' during backup - Jan '85 - kit EQ-01323-01 o TU80 dislikes 11/84 - Nov '85 - kit EQ-01397-01 o TU80 cover slams - May '85 - kit EQ-01341-01 =============================================================== Software Update Bulletin RSTS/E V9.5 arrived right after the February issue was sent to the printer. This release seems quite well-done and bug-free (in the sense that no new bugs crept in). Some of the long-standing bugs, such as RSTS not reading RT-11 magtapes, are still present, however. The Feb '88 RSTS/E Dispatch contains two patches for the 9.5 monitor - one enables the new file truncation feature, and the other apparently fixes a bug where RSTS was 'allergic' to certain PPN's (files could not be created in these PPN's, for example). This release also includes the source for the SHUTUP program, which has been requested by several users. =============================================================== 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. A problem with INIT 'losing' the status of RA-series disks was reported. If a drive starts out with the port select button out, pressing it in while at "Start timesharing?" will be ignored by INIT, and the drive remains unavailable. However, if you press it in while the system is up, the drive will become available. When running the disk test programs in the TEST$: account, if the account you are logged into does not exist on the disk being tested, you will get the '?Can't file file or account' error message.