Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
gal702.d12
There are no other files named gal702.d12 in the archive.
EDIT DESCRIPTIONS FOR GALAXY-10-V702
EDIT 3015 FOR LPTSPL
[SYMPTOM]
LPTSPL will insert an extra linefeed on the first page
of output when FORWARDSPACEING or for a /BEGIN:xx switch.
[DIAGNOSIS]
LPTSPL has had this problem for at least four years and
we have tried to fix this problem at least five other times
in the past... so let's teach lptspl about FORWARDSPACEING
because he does not currently know how to do it.
[CURE]
Add and revamp code.
********************************************************************************
EDIT 443 FOR PULSAR
[SYMPTOM]
Magtape labels are sometimes overwritten during a reel
switch using a single TU77 or TU78 tape drive.
[DIAGNOSIS]
Some TU77s and TU78s generate spurious on-line
interrupts when the drive is actually off-line or in the
process of loading. When PULSAR tries to recognize tape
labels, it gets and processes an off-line interrupt (since
the drive never really came on-line) but never expects an
off-line condition to happen when the tape drive is still
assigned to a user job, as is the case when a reel switch
occurs. Part of the off-line processing code releases the
TCB (Tape Control Block). A side effect of doing this is a
label release which inadvertently gets the user's job out of
event wait for the reel switch. Immediately, the user job
hangs in operator wait for the off-line tape drive. When
the operator notices the OW condition and makes sure a tape
is mounted and on-line, the user's job starts writing the
tape. The tape was at the load point because the operator
just loaded it, so user data overwrites the tape labels.
The corrupted labels are never discovered until the
volume-set is read.
[CURE]
Re-work off-line handling, taking into consideration
the drive may still be assigned to a user.
********************************************************************************
EDIT 444 FOR PULSAR
[SYMPTOM]
PULSAR does not always recognize valid "VOL1" labels.
[DIAGNOSIS]
When checking for "VOL1" labels, PULSAR assumes that
bits 32-35 always cleared. In actuality, the contents of
these bits is indeterminate.
[CURE]
Always clear bits 32-35 prior to comparing against ANSI
or EBCDIC "VOL1".
********************************************************************************
EDIT 445 FOR PULSAR
[SYMPTOM]
PULSAR sometimes returns the wrong density for
unlabeled tapes.
[DIAGNOSIS]
A JRST to the wrong label in the loop which checks for
"VOL1" labels causes the drive to be set to the last density
checked which is not necessarily the default density for the
drive.
[CURE]
Change JRST RVOL.3 to JRST RVOL.5.
********************************************************************************
EDIT 446 FOR PULSAR
[SYMPTOM]
After installing edit 445, PULSAR reports incorrect
densities for DX10/DX20 controlled tape drives. The
densities are not always predictable and can vary depending
upon the written density of the tape, the type of TU7x
drive, and whether an explicit RECOGNIZE command is given or
the drive is read because of AVR.
[DIAGNOSIS]
Some ancient code left over from the original PULSAR
version 1 tried to be clever about kontrollers which were
capable of doing auto density detection. It never set up an
initial density to be used when checking for "VOL1" labels.
[CURE]
Remove all knowledge of specific tape kontrollers. The
code in PLRLBP at RVOL.5 only needs to know if a tape was
read at a different density than was expected.
********************************************************************************
EDIT 447 FOR PULSAR
[SYMPTOM]
PULSAR loops during a backspace operation on unlabelled
tapes.
[DIAGNOSIS]
A typo in the backspace code causes PULSAR to loop
continually trying to switch to the first reel of the
volume-set.
[CURE]
Change JUMPF BSF.7 to JUMPF BSF.8.
********************************************************************************
EDIT 450 FOR PULSAR
[SYMPTOM]
PULSAR gripes that a structure contains the system queues when it
really doesn't.
[DIAGNOSIS]
PULSAR GETTAB's %LDQUS during initialization and stores this
for later checks. Problem is, QUASAR can change this from under
PULSAR causing the error.
[CURE]
GETTAB %LDQUS each time it is needed, rather than relying on
old and possibly obsolete information.
********************************************************************************
EDIT 451 FOR PULSAR
[SYMPTOM]
Allow unprivileged users can't access IBM labeled
which contain an access code of " " (space).
[DIAGNOSIS]
access code contains a space.
[CURE]
yes fixed in PLRLBP.
********************************************************************************
EDIT 1232 FOR QUASAR
SYMPTOM
SHOW PARAMETERS BATCH /NODE:FOO where FOO is an IBM emulation
node gives the response
"Batch-Stream 0 [FOO] -- Device unknown --"
even when node FOO is online and started
DIAGNOSIS
CHKOBJ in QSRDSP doesn't like IBM emulation objects when
processing SHOW PARAMETERS.
CURE
In QSRDSP at CHKO.3+6L, IF THE IBM emulation object exists,
return TRUE even if we're processing SHOW PARAMETERS, not just
SHOW STATUS.
********************************************************************************
EDIT 1233 FOR QUASAR
[SYMPTOM]
QUASAR doesn't handle attaching and detaching dual-ported disk drives
correctly.
[DIAGNOSIS]
Confusion in the handling of the monitor detach message.
[CURE]
Clear up the confusion.
********************************************************************************
EDIT 1234 FOR QUASAR
[SYMPTOM]
Bizarre statistics recorded in magtape usage entries - 524292
hard read errors and 524 (thousand) characters written.
[DIAGNOSIS]
QUASAR sends part of a volume switch message from PULSAR to the
accounting daemon as statistics for a magtape usage entry.
Prior to MCO 10968 (701A) and QUASAR edit 1165, QUASAR did TAPOP.
UUOs to get the magtape statistics when a tape was dismounted or
when a volume switch occurred. The above edits fixed the problem
where the counters were getting cleared before QUASAR did the
UUOs to read the statistics. The statistics were appended to the
"deassign" message sent by the monitor to QUASAR when a device
was released. However, the volume switch code in QUASAR still
called I$TDSM assuming it did TAPOP. UUOs to read the
statistics, but edit 1165 changed I$TDSM to get the stats from
the "deassign" message. The problem is that when I$TDSM is
called at volume switch time, the message just received is a
"volume switch" message from PULSAR, not a "deassign" message
from the monitor. So I$TDSM happily takes part of the "volume
switch" message and sends it as magtape stats to the accounting
daemon.
[CURE]
In the monitor, add a new entry point, SNDVSS, in SNDFIN. Modify
SNDFIN to lite a flag in the "deassign" message indicating it's
really tape statistics for a volume switched unit (conceptually a
"deassign" for accounting purposes) when entered via SNDVSS. Add
a call to SNDVSS in TMPLSU just before updating the database to
reflect the volume switch. Also remove the call to TPSTAT to
report stats to the user (SET WATCH MTA) and insert it right
after the call to SNDVSS in TPMLSU. This prevents the stats from
being reported twice for the same tape drive when a volume switch
is cancelled.
In QUASAR, add code in D$DEAS and I$TDSM to recognize the monitor
flag in the "deassign" message from the monitor and do the
correct things with respect to sending the accounting daemon tape
statistics. Also in QUASAR, remove the call to I$TDSM at VSR.0
which was responsible for the erroneous numbers to begin with.
This call is no longer needed since the monitor will now send a
message when a volume switch occurs.
********************************************************************************
EDIT 1235 FOR QUASAR
[SYMPTOM]
Cannot use QUEUE. UUO to submit a batch job at a tag.
[DIAGNOSIS]
QSRQUE thinks the .QBBGN block is only legal for output queues.
[CURE]
Show QSRQUE the error of his ways; allow .QBBGN for input as well as
output queues. Only allow a SIXBIT argument in the case of input queues
(a starting label rather than a beginning line number).
********************************************************************************
EDIT 1236 FOR QUASAR
[SYMPTOM]
"SHOW STATUS" command in OPR may show "No processor" when there really
is one.
[DIAGNOSIS]
QUASAR can delete a spooler from its database when it shouldn't. In
QUASAR's IPCF message resend code, if a resend of a message fails with
"no such PID", QUASAR takes the PID of the intended receiver and deletes
the corresponding Processor Status Block if one exists. The problem is
that QUASAR is getting the PID of the intended receiver from the wrong
place.
[CURE]
Get the PID from the resend argument block, not from G$SAB.
********************************************************************************
EDIT 2263 FOR QUEUE
[SYMPTOM]
Can't use private version of GALAXY for queueing.
[DIAGNOSIS]
Check ACK code cause packets from IPCC to get ignored.
[CURE]
Check the ACK code after checking if packet was from IPCC.
********************************************************************************
END OF GALAXY-10-V702