Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
galv41.d08
There is 1 other file named galv41.d08 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR GALAXY-10-V4-1
EDIT 1152 FOR GLXLIB
[Source After Edit] %1 (001152)
[SYMPTOM]
ABS GALAXY STOPCODES IN OPR
[DIAGNOSIS]
When an indirect file is too big to fit in the parsing buffer,
OPR dies with an ABS (GALAXY) stopcode. This can be confusing
when the OPR command "TAKE @" is the command that was typed.
What happened was that since the filename was missing, a default
filename was used (usually SYS:SYSTEM.CMD) and the file was big
enough to overflow the the buffer. However, SYS:SYSTEM.CMD is a
"take" file, not an indirect file (there is a difference), and
should never have been used.
[CURE]
Don't allow FILIN to default filenames for indirect files.
Instead of giving an ABS, just type an error message when the
indirect file is too big to fit in the parsing buffer.
********************************************************************************
EDIT 1157 FOR GLXLIB
[Source After Edit] %1 (001157)
[SYMPTOM]
When OPR is started by a MIC file, it keeps going into TI state
waiting for MIC to feed it input even when MIC is no longer in
control of the job.
[DIAGNOSIS]
K%INIT in GLXKBD checks to see if MIC is in control of the job
and sets a flag if so. However, no checking is done to see if
MIC ever releases the job.
[CURE]
In GLXKBD, the K%INIT routine, instead of setting BATFLG negative
when MIC is controlling the job (the same as for a real batch
job), set BATFLG positive. At BIN.1 in GLXKBD, check to see if
BATFLG is positive and if so, do a TRMOP. UUO to determine
whether MIC is still controlling. If MIC is still in control, go
do the INCHWR UUO and block for a character (go into TI state),
otherwise zero BATFLG indicating MIC no longer in control and
then go hibernate, waking on IPCF receives and character input.
This does NOT completely fix the problems of OPR under MIC, but
it's the best that can be done given MIC's support status.
********************************************************************************
EDIT 1160 FOR GLXLIB
[Source After Edit] %1 (001160)
[SYMPTOM]
SNDMSG always sends packets of 510 words to [SYSTEM]GOPHER
regardless of actual message size. This leads to monitor free
core being used needlessly.
[DIAGNOSIS]
Code in SNDMSG uses PAGSIZ-2 as packet size for all messages to
[SYSTEM]GOPHER.
[CURE]
Use actual message length as packet size.
********************************************************************************
EDIT 1163 FOR GLXLIB
[Source After Edit] %1 (001163)
[SYMPTOM]
XCMDEV in GLXSCN will successfully parse a "null" device name.
For example, OPR will parse the command "RECOGNIZE :" without
error - QUASAR promptly dies with a QBI stopcode.
[DIAGNOSIS]
The reason why this hasn't been noticed before is that not too
many people will type just a ":" and expect it to be parsed as a
device name. Also, if the device field being parsed is not
"parse only", a DEVCHR UUO is done to make sure what was typed is
a valid device. If "parse only" is set for the field, XCMDEV
will only make sure the ":" is typed if "ignore suffix" is not
set for the field. If "parse only" and "ignore suffix" are set
for the field to be parsed, "null" (nothing in the atom buffer)
will parse successfully. In the above example, the device field
of the RECOGNIZE command is set to "parse only".
[CURE]
In XCMDEV, before checking for "parse only" or "ignore suffix",
check to make sure that the first character of the field in the
atom buffer is not null (zero).
********************************************************************************
EDIT 1164 FOR GLXLIB
[Source After Edit] %1 (001164)
[SYMPTOM]
If NUL is the file structure, then OPNCOM will return a zero in
the FD block built by SETFD. This will lead to QUASAR CRL and
RRF stopcodes when a batch job has NUL as the logfile structure.
This bug may also result in other random and interesting results
when using GLXLIB to open files with NUL as the structure.
[DIAGNOSIS]
In OPNCOM the FILOP. uuo returns a 0 in the path block when the
structure is NUL. This caused the SETFD routine to create an FD
block with 0 as the structure name.
[CURE]
Add code at OPNC.2 to prepare for a 0 returned by the FILOP. uuo
by writing the structure name to the path output buffer before
performing the uuo. The FILOP. uuo will write over this word if
it is successful and the path has a structure, it will not zero
the word if we return true and the path does not contain a
structure. This is only of interest in the case of the structure
being NUL.
********************************************************************************
EDIT 1166 FOR GLXLIB
[Symptom]
GLXIPC not as useful as it could be. Can't determine the
sender's privs. Can't set error codes in the packet descriptor
blocks.
[Diagnosis]
Oversight.
[Cure]
Add about a dozen lines of code
********************************************************************************
EDIT 1167 FOR GLXLIB
[Source After Edit] %1 (001167)
[SYMPTOM]
QUEUE /DISPOSE:RENAME changes file made to zero (.IOASC).
[DIAGNOSIS]
The GLXLIB F%REN routine does not preserve the mode when the
protection code is changed because the FILOP. UUO rewrites the
entire word if the RB.PRV field is changed.
[CURE]
No good cure, the FILOP. UUO is behaving correctly, the zero
value (.IOASC) is valid given the change to the RB.PRV field, so
on a RENAME we must do a LOOKUP and copy by hand the file I/O
mode to the RENAME block.
********************************************************************************
EDIT 1170 FOR GLXLIB
[Symptom]
GLXSCN does not perform $DEFAULTing correctly for tokens.
[Diagnosis]
GLXSCN does not copy the default string for the token into
the atom buffer if a CRLF was typed instead of the token.
[Cure]
Copy the default string for the token into the atom buffer.
********************************************************************************
EDIT 1171 FOR GLXLIB
[Source After Edit] %1 (001171)
[SYMPTOM]
GLXFIL EDIT 106 introduced a DATE-75 bug and GLXLIB does not do a
FILOP RENAME correctly.
[DIAGNOSIS]
EDIT 106 does not set the high order three bits of the creation
date field. It also does not properly setup the FILOP RENAME.
[CURE]
Add and revamp code to correctly setup the FILOP RENAME UUO, this
solves the problem related to the original SPR.
********************************************************************************
EDIT 1167 FOR QUASAR
[Source After Edit] %4 (001167)
[SYMPTOM]
The NEXT command in OPR fails when the object specified has not
been STARTed yet and there are entries in the queue for it.
[DIAGNOSIS]
The A$NEXT routine looks for the obj block of the object
specified in the NEXT command. If the obj block doesn't already
exist, an error is returned to the user.
[CURE]
If the obj block doesn't exist yet, create one. In A$NEXT call
GETOBJ instead of A$FOBJ.
********************************************************************************
EDIT 1170 FOR QUASAR
[Source After Edit] %4 (001170)
[SYMPTOM]
QUASAR does not send an ACK to a user, if requested, using
QUEUE. UUO to DISMOUNT a structure or MOUNT a structure
that is not contained in the system catalogue.
[DIAGNOSIS]
User QUEUE. UUO requests are delivered to QUASAR by
the [SYSTEM]GOPHER. The logic in QUASAR that determined what
ACKs should be sent to [SYSTEM]GOPHER was insufficient. The
only ACK that the [SYSTEM]GOPHER doesn't need to return to
the QUEUE. UUO user is the "mount request queued" ACK text.
This is because, normally, a MOUNT command has 2 ACKs
returned - the "mount request queued" ACK and the ACK saying
if the structure was mounted or not. QUEUE. UUO users only
get 1 ACK, so we only want to send the important one. For
DISMOUNTs, the code never checked if user was waiting for an
ACK.
[CURE]
Remove the checks for "GOPHER" requests in USRNOT. Make the
"GOPHER" check in USRACK - don't send the "mount request
queued" text ACK if a "GOPHER" mount request. For
DISMOUNTs, make sure the "waiting for ACK" bit gets set if
user is waiting.
********************************************************************************
EDIT 1171 FOR QUASAR
[Source After Edit] %4 (001171)
[SYMPTOM]
Can't use /DISPOSE: for jobs submitted to the INP: queue via
QUEUE. UUO. SUBMIT /DISPOSE: (QUEUE prog) works.
[DIAGNOSIS]
In QSRQUE.MAC, CRQODP explicitly checks that only entries for
output queues can use a /DISPOSE arg block.
[CURE]
Remove check for output queues, thus allowing /DISPOSE to work
for jobs entering any queue.
********************************************************************************
EDIT 1172 FOR QUASAR
[Source After Edit] %4 (001172)
[SYMPTOM]
QUASAR doesn't process search list change messages from the
monitor for MIC cojobs.
[DIAGNOSIS]
In I$SLCM, QUASAR checks the JB.LBT bit of the .GTLIM word for
the job. This bit is set by MIC and BATCON.
[CURE]
Check the OB.BSS (batch stream set) bit of the .GTOBI word
instead.
********************************************************************************
EDIT 1173 FOR QUASAR
[Source After Edit] %4 (001173)
[SYMPTOM]
MOUNT does not know which response from QUASAR is associated
with which mount request when more than 1 mount request is
outstanding. Another problem is that a user can specify
/NOTIFY for one mount request and issue another mount
request without /NOTIFY before the first request is
fulfilled and no notification will occur when the first
request is fulfilled.
[DIAGNOSIS]
QUASAR uses one MDR for each user. Each mount request is
associated with the same MDR. ACK codes, notify flags, and
sender's PID are stored in the MDR. These fields get
written with each mount request. On a new mount request,
any pending request with specific data in these fields are
overwritten with new request's data. QUASAR uses this "ACK
data" when deciding whether or not to notify user. This
"ACK data" may not reflect what the user specified when the
mount request was made. Simply having MOUNT send an ACK
code in a mount request and look for it in QUASAR's
responses will not fix all cases because the notify flags
are also overwritten by a subsequent mount request by the
same user.
[CURE]
Make entries in VSL for ACK code, PID and flags. When VSL
is linked to MDR, copy these fields from MDR and indicate
that data has been copied to VSL. Use the data in VSL when
responding (ACKing) the requestor unless the data in MDR is
valid (MOUNT /WAIT is this special case). Change MOUNT to
generate a semi-unique ACK code and send it in message to
QUASAR. MOUNT will now know which message it is waiting for
since each time MOUNT is run a different ACK code will be
generated. This problem will be a temporary restriction
until QUASAR edit 1173 and MOUNT edit 55 are released via
Autopatch. The code changes required are large and they
depend on other edits.
********************************************************************************
EDIT 1174 FOR QUASAR
[Source After Edit] %4 (001174)
[SYMPTOM]
QUASAR NBM stopcodes. Scenario: User issues a mount request for
a structure FOO that is not currently mounted. STRLST says that
FOO is a RP04 but when the pack is spun up it's really an RP06.
QUASAR notices the difference, tells the operator, updates his
internal catalogue , etc. and continues merrily along until the
user dismounts the structure - QUASAR dies.
[DIAGNOSIS]
The code in D$CCAT that handles this situation contained a couple
mistakes. It detected the fact that FOO(RP04) and FOO(RP06) were
different resources and that it should not let FOO(RP06) be
mounted (and catalog updated) if FOO(RP04) has pending
allocations. If it does, the resulting counts in the
corresponding 'B' and 'C' matrices are incorrect. The code to
check the number of allocations is wrong - SKIPE should be SKIPN
- among other things.
[CURE]
Fix the code in D$CCAT to only allow conflicting entries in the
internal catalog to be updated if and only if there are no
pending allocations for the resource corresponding to the catalog
entry to be deleted. Don't allow a disk to be mounted if
anything except the owner PPN differs between the old and new
entry and the old entry has pending allocations. QUASAR can
not determine which resource the user actually wants.
********************************************************************************
EDIT 1175 FOR QUASAR
[Symptom]
QUASAR QBI (QUASAR blew it) stopcode is not QUASAR's fault.
[Diagnosis]
QUASAR dies when he notices that he's about to send a "null" (zero)
device name to PULSAR in a RECOGNIZE msg. The problem is really in
ORION, he's the one that builds the block with the device name in it.
[Cure]
Change QBI stopcode in QUASAR into a WTO just in case a "null" device
appears. Add a PBI (P$DEV blew it) stopcode in ORION where the device
name is returned from OPRPAR.
********************************************************************************
EDIT 1176 FOR QUASAR
[Symptom]
The request queue type is no longer displayed for batch requests in
a SHOW STATUS STRUCTURE /USER command. Requires QUASAR edit 1173.
[Diagnosis]
This is an unexpected side effect of QUASAR edit 1173. Edit 1173
copies this information (and other) from the MDR to the VSL. All the code
now uses the VSL for this information. However, the request queue type
is stored in the MDR after edit 1173 copied the information to the VSL.
[Cure]
Make sure the request queue type is stored in the VSL. At BMDR.1 add
code to store the request type in .VSRFL.
********************************************************************************
EDIT 1177 FOR QUASAR
[Source After Edit] %4 (001177)
[SYMPTOM]
QUASAR ILM stopcodes occur when OPR does SHOW STATUS command and
there are a large number of jobs in the queue.
[DIAGNOSIS]
QUASAR does not check for room in the buffer before writing to
it. QUASAR may write beyond the end of the 1 page buffer to a
non-existent page.
[CURE]
Make QUASAR check to see if he is at the end of the buffer before
writing to it.
********************************************************************************
EDIT 1200 FOR QUASAR
[Source After Edit] %4 (001200)
[SYMPTOM]
QUASAR will print a spurious TAB before a job name when listing
the LPT queue when there are a large number of jobs in the queue.
The job immediately preceding the one with the extraneous TAB
must have non-NORMAL forms and queued to local node.
[DIAGNOSIS]
QUASAR does not handle a line wrap at end of buffer correctly.
[CURE]
Make QUASAR clear the TAB in QSRDSP's DMPS.7 routine when
restoring the byte count and pointer.
********************************************************************************
EDIT 1201 FOR QUASAR
[Source After Edit] %4 (001201)
[SYMPTOM]
Batch jobs fail to LOGIN. The job was SUBMITed with a
/DESTINATION: SIXBIT node name switch and LOGIN does not accept
the SIXBIT argument.
[DIAGNOSIS]
Three problems; 1) LOGIN does not accept the /LOCATE SIXBIT node
name switch, 2) we should not be scheduling the BATCH job until
we have a node number, and 3) we should be converting the SIXBIT
node name to OCTAL node number as soon as possible.
[CURE]
In QUENCH convert the node name to number if possible, in QUASAR
convert the node name to number as soon as possible, and don't
schedule the batch job until we have a node number. The LOGIN
change requires documenting the LOCATE switch and the QUENCH and
QUASAR changes do not require a LOGIN change to resolve the
problem.
********************************************************************************
EDIT 1202 FOR QUASAR
[Source After Edit] %4 (001202)
[SYMPTOM]
A stopped printer may seem to continue by itself. An operator
can issue a STOP PRINTER command and receive an ack that says the
printer is stopped, but the printer starts printing again on the
next schedulable print request for that printer.
[DIAGNOSIS]
When QUASAR receives a STOP request, he checks in the object
block of the device to see if it is currently active. If the
device is active, QUASAR forwards the STOP request to the
spooler. In this case, QUASAR does NOT mark the device as
stopped in its object block, he waits for the spooler to send a
status update. If the timing is right, QUASAR can forward a STOP
request to a spooler at the same time the spooler is finishing
(releasing) the current request. The spooler receives the STOP
request, says the device is stopped, but never sends a status
update to QUASAR because the device is no longer active. (The
STOP request was received after the release was done). QUASAR is
never told the device is stopped, so he happily starts another
request for the device when one is available.
[CURE]
Always mark the device as stopped on a STOP request regardless of
whether the device is active or not. QUASAR knows how to handle
an object status of "stopped+active".
********************************************************************************
EDIT 1203 FOR QUASAR
[Source After Edit] %4 (001203)
[SYMPTOM]
Batch jobs fail after LOGIN because they exceed CORMAX.
[DIAGNOSIS]
The QSRSCH test is comparing words to pages and always succeeds.
[CURE]
Make the QSRSCH test compare words.
********************************************************************************
EDIT 1204 FOR QUASAR
[Symptom]
QUASAR could be smarter, PULSAR confused. When DISMOUNT /REMOVing
a structure via OPR and PULSAR needs an operator response to
continue (front-end file system on pack, etc), QUASAR does not
use what he knows to help out an operator or PULSAR. Subsequent
commands to MOUNT, RECOGNIZE , or DISMOUNT the structure, while
the WTOR from PULSAR is still pending, give erroneous acks or
forwards more work to PULSAR which he sometimes doesn't handle
gracefully (like ?Illegal UUOing at PC 000001).
[Diagnosis]
QUASAR knows the structure in question is to be or is in the process
of being dismounted but just doesn't say so when he should.
[Cure]
Teach QUASAR to be more explicit when he can. Add text where
appropriate in acks concerning structure dismounts, etc., when
the structure in question is dismounting.
********************************************************************************
EDIT 1205 FOR QUASAR
[Source After Edit] %4 (001205)
[SYMPTOM]
QUASAR deletes a spooler from its database when he shouldn't.
"SHOW STATUS" command may show "No Processor" when really there
is one.
[DIAGNOSIS]
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. Trouble is, QUASAR is getting the PID with which he
makes this check from the wrong place.
[CURE]
Get the PID from the resend arg block, not from G$SAB.
********************************************************************************
EDIT 1206 FOR QUASAR
[Source After Edit] %4 (001206)
[SYMPTOM]
When running on a non-networking monitor, spoolers will not
be scheduled to run after QUASAR edit 1142 or before edit
1142 the scheduling of spoolers will stop when a user queues
a request with a /DESTINATION switch.
[DIAGNOSIS]
Two problems:
1. The node UUO fails and we assume the node is off
line. This problem was not seen before edit 1142
because we crocked it so the lowest numbered node
in the database could never go off line.
2. We are easily confused by a multiplicity of zero
numbered nodes, and will assume the LOCAL or
CENTRAL node is offline.
[CURE]
The code required to resolve this problem was shipped in the
IBMCOM beware file and requires an additional QSRNET edit.
This change is required to identify the LOCAL or CENTRAL
node correctly so we do not set it offline. The changes to
QSRSCH are only required if QUASAR edit 1201 is installed.
This change is required so we schedule jobs that were
submitted with a /DESTINATION switch correctly.
********************************************************************************
EDIT 2254 FOR QUEUE
[Source After Edit] %104 (002254)
[SYMPTOM]
QMANGR fails to correctly handle the /OUTPUT: switch.
[DIAGNOSIS]
QMANGR is not passing QUASAR the switch value, because in QMANGR
a test at CRE.7B is reversed.
[CURE]
In QMANGR fix the test.
********************************************************************************
EDIT 516 FOR QUEUE
[SYMPTOM]
The /OUTPUT: switch is badly broken; the GALGEN default is
ignored and the incorrect value may be passed to QUASAR.
[DIAGNOSIS]
QUENCH uses the incorrect symbols confusing OUTPLOG and INPLOG.
[CURE]
Use the correct symbols in QUENCH.
********************************************************************************
EDIT 517 FOR QUEUE
[SYMPTOM]
Operator logged in as [1,2] has the SUBMIT on behalf of fail when
ERSATZ or PATHOLOGICAL devices are used. A command would look
like this "SUBMIT [10,10]=CTL:FOO,NUL:"
[DIAGNOSIS]
QUENCH fails to default the PPN correctly when an ERSATZ or
PATHOLOGICAL device is used for the input file.
[CURE]
Check the value of the implied PPN bit (PT.IPP), if set on do not
set the PPN and clear any path given since the device is going to
ignore it.
********************************************************************************
EDIT 520 FOR QUEUE
[SYMPTOM]
Batch jobs fail to LOGIN. The job was SUBMITed with a
/DESTINATION: SIXBIT node name switch and LOGIN does not accept
the SIXBIT argument.
[DIAGNOSIS]
Three problems; 1) LOGIN does not accept the /LOCATE SIXBIT node
name switch, 2) we should not be scheduling the BATCH job until
we have a node number, and 3) we should be converting the SIXBIT
node name to OCTAL node number as soon as possible.
[CURE]
In QUENCH convert the node name to number if possible, in QUASAR
convert the node name to number as soon as possible, and don't
schedule the batch job until we have a node number. The LOGIN
change requires documenting the LOCATE switch and the QUENCH and
QUASAR changes do not require a LOGIN change to resolve the
problem.
********************************************************************************
END OF GALAXY-10-V4-1