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
	LPTSPL will insert an extra linefeed on the first page
	of output when FORWARDSPACEING or for a /BEGIN:xx switch.
	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.
	Add and revamp code.
                             EDIT 443    FOR PULSAR
     Magtape labels are sometimes overwritten during a  reel
switch using a single TU77 or TU78 tape drive.
     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.
     Re-work off-line handling,  taking  into  consideration
the drive may still be assigned to a user.
                             EDIT 444    FOR PULSAR
     PULSAR does not always recognize valid "VOL1" labels.
     When checking for "VOL1" labels,  PULSAR  assumes  that
bits  32-35  always  cleared.  In actuality, the contents of
these bits is indeterminate.
     Always clear bits 32-35 prior to comparing against ANSI
                             EDIT 445    FOR PULSAR
     PULSAR  sometimes  returns  the   wrong   density   for
unlabeled tapes.
     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
     Change JRST RVOL.3 to JRST RVOL.5.
                             EDIT 446    FOR PULSAR
     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.
     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.
     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
     PULSAR loops during a backspace operation on unlabelled
     A  typo  in the backspace  code  causes  PULSAR  to  loop
continually   trying   to  switch  to  the  first  reel of the
     Change JUMPF BSF.7 to JUMPF BSF.8.
                             EDIT 450    FOR PULSAR
	PULSAR gripes that a structure contains the system queues when it
	really doesn't.
	PULSAR GETTAB's %LDQUS during initialization and stores this
	for later checks.  Problem is, QUASAR can change this from under
	PULSAR causing the error.
	GETTAB  %LDQUS each time it is needed, rather than relying on
	old and possibly obsolete information.
                             EDIT 451    FOR PULSAR
	Allow unprivileged users can't access IBM labeled
	which contain an access code of " " (space).
	access code contains a space.
	yes fixed in PLRLBP.
                             EDIT 1232   FOR QUASAR
node gives the response
	"Batch-Stream 0 [FOO] -- Device unknown --"
	even when node FOO is online and started
	CHKOBJ in QSRDSP doesn't like IBM emulation objects when
	In QSRDSP at CHKO.3+6L, IF THE IBM emulation object exists,
return TRUE even if we're processing SHOW PARAMETERS, not just
                             EDIT 1233   FOR QUASAR
QUASAR doesn't handle attaching and detaching  dual-ported  disk  drives
Confusion in the handling of the monitor detach message.
Clear up the confusion.
                             EDIT 1234   FOR QUASAR
Bizarre statistics recorded in magtape  usage  entries  -  524292
hard read errors and 524 (thousand) characters written.
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
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
Cannot use QUEUE. UUO to submit a batch job at a tag.
QSRQUE thinks the .QBBGN block is only legal for output queues.
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
"SHOW STATUS" command in OPR may show "No processor" when  there  really
is one.
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
Get the PID from the resend argument block, not from G$SAB.
                             EDIT 2263   FOR QUEUE
	Can't use private version of GALAXY for queueing.
	Check ACK code cause packets from IPCC to get ignored.
	Check the ACK code after checking if packet was from IPCC.