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.
�����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������