Trailing-Edge
-
PDP-10 Archives
-
bb-bt99e-bb
-
gal702.d09
There is 1 other file named gal702.d09 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR GALAXY-10-V702
EDIT 3004 FOR LPTSPL
[Source After Edit] %104 (003004)
[SYMPTOM]
Files PIP'd to the printer from a magtape written by LPTSPL print
differently than when they are printed normally. There should
not be a difference. V2 LPTSPL did it right.
[DIAGNOSIS]
LPTSPL substitutes <CR><LF> for <CR><DC3> in CR23 when J$MTAP(J)
is nonzero. This was probably implemented for unsupported
reasons - DC3s do funny things to terminals.
[CURE]
Don't substitute <CR><LF> for <CR><DC3> in CR23 when J$MTAP(J) is
nonzero. However, only output the <CR><DC3> if we're spooling to
a real LPT or MTA device. This is no commitment to support
spooling to other devices besides LPTs and MTAs, we just don't
want break things that currently work.
********************************************************************************
EDIT 3005 FOR LPTSPL
[Source After Edit] %104 (003005)
[SYMPTOM]
LPTSPL misinterprets PSI interrupt conditions at interrupt time.
'CPU failure' on single CPU systems.
[DIAGNOSIS]
LPTSPL does not check the correct PSI conditions when trying to
determine the cause of the PSI interrupt. When all the IO.ERR
bits and PS.RDO are lit and the printer is local, LPTSPL thinks a
CPU failed.
[CURE]
For CPU failure, the correct bits to check are
PS.RDO!PS.RIE!PS.ROE in the PSI conditions word.
********************************************************************************
EDIT 3006 FOR LPTSPL
[Source After Edit] %104 (003006)
[SYMPTOM]
With LPTSPL edit 2772 and the following commands in SYSJOB.INI,
LPTSPL thinks the printer is not available when the operator
tries to start it.
LOG
ASSIGN LPT0 LPT010
LPTSPL
[DIAGNOSIS]
Edit 2772 was a bit too cautious in trying to prevent the same
device (TTYs mostly) from being OPENed on 2 different printer
streams. If DEVCHR bits DV.ASC and DV.ASP are lit, LPTSPL will
not try to OPEN the device. However, given the above scenario,
DV.ASC being lit will not cause any problem. Furthermore, the
OPEN would fail if someone else had the device already assigned.
[CURE]
Just check DV.ASP. Don't try to save executing a few extra lines
of code and let the OPEN UUO decide whether LPTSPL can use the
device.
********************************************************************************
EDIT 3007 FOR LPTSPL
[Source After Edit] %104 (003007)
[SYMPTOM]
1) LPTSPL may die strangely if a printer goes offline or comes
online at the wrong time, especially if more than 1 printer is
being driven.
2) LPTSPL may report the wrong printer going offline.
[DIAGNOSIS]
1) Currently LPTSPL lites the 'output blocked' bit (LPTSPL uses
UU.AIO) a few instructions before actually doing the OUT UUO. It
also clears this bit when it processes 'online' interrupts.
Under certain scenarios it is possible that the 'output blocked'
bit gets cleared when the I/O really isn't complete. Using the
current buffer headers when this happens could cause strange
results.
2) LPTSPL assumes that the printer going offline is associated
with the current context in which it is executing. This is not
always the case.
[CURE]
1) In LPINTR, when we clear 'output blocked' on online interrupt,
zero the byte count in the buffer ring header. This will keep
LPTSPL from using invalid buffer ring information if the buffers
haven't been advanced yet. (We have to do this because we can
never be sure we will always get every 'output done' interrupt
that we expect).
2) When a printer goes offline, make sure LPTSPL reports the
correct printer. Check the status word of all printers and
report only the printers really offline.
********************************************************************************
EDIT 3010 FOR LPTSPL
[Source After Edit] %104 (003010)
[SYMPTOM]
Can't clear job stuck on a line printer that is having hardware
problems. ABORT PRINTER /PURGE doesn't always work.
[DIAGNOSIS]
When purging a job, LPTSPL tries to flush the output buffers and
send a formfeed before releasing the job. If for some reason
output can't be done, LPTSPL waits indefinitely, never releasing
the job.
[CURE]
On ABORT PRINTER /PURGE, don't worry about flushing the output
buffers or sending a formfeed, just release the current job.
********************************************************************************
EDIT 0057 FOR MOUNT
[Source After Edit] %1 (000057)
[SYMPTOM]
It's difficult to type in long commands to MOUNT.
[DIAGNOSIS]
MOUNT doesn't support line continuation.
[CURE]
Add the code to support line continuation using the SCAN-like
convention of using a dash, "-", as the line continuation
character. E.g.
.MOUNT FOO:/VOL:(REEL1,- <CR><LF>
#REEL2)
NOTE: "#" is output by MOUNT as line continuation prompt.
********************************************************************************
EDIT 345 FOR OPERAT
EDIT 345
[Symptom]
ORION can't get TTY name of a user issueing a 'SEND OPR'
command when the user is not logged in.
[Diagnosis]
By the time ORION gets the IPCF message from
SYSTEM[GOPHER] the job number is no longer valid.
[Cure]
Add code to get TTY name from new QUEUE. UUO arg block.
See MCO 11204.
********************************************************************************
EDIT 346 FOR OPERAT
[Source After Edit] %4 (000346)
[SYMPTOM]
Application "hello failure" message contains junk on typeout.
[DIAGNOSIS]
The address of the application name is not stored correctly in
APLHEL. Also, the code assumes there is always only one
application.
[CURE]
Fix the code. Get the application name string address from the
table address returned by the S%TBLK routine.
********************************************************************************
EDIT 442 FOR PULSAR
[Source After Edit] %4 (000442)
[SYMPTOM]
PULSAR dies with RTT stopcodes.
[DIAGNOSIS]
In the early days of label tape development it was felt that
PULSAR would never, under normal circumstances, attempt to release a
TCB more than once. As PULSAR grew, the methods of error recovery
changed, but the paranoia code remained. Today, It is more likely
than ever for RTT stopcodes to occur during normal error recovery.
[CURE]
Remove the stopcode.
********************************************************************************
EDIT 1207 FOR QUASAR
[Source After Edit] %4 (001207)
[SYMPTOM]
If a batch job is started by the next command, and the batch job
is requeued, the same batch job will be scheduled on the next
pass of QUASAR's scheduler. Requeued jobs should not start right
away because they are put back in the queue with a /AFTER:+5 .
[DIAGNOSIS]
We never clear the REQUEST-ID for the NEXTed request after it has
been scheduled.
[CURE]
Clear the NEXT request REQUEST-ID word in the object block as
soon as we get the QE page for scheduling the request.
********************************************************************************
EDIT 1212 FOR QUASAR
[Source After Edit] %4 (001212)
[SYMPTOM]
QUASAR using inordinate amounts of runtime and not deleting
spooled files. This occurs when the first entry in QUASAR's
"delete file" list is for an off-line structure or the structure
nolonger exists. This case is only exercised when there is more
than one spooled file to delete and the structure is off-line.
[DIAGNOSIS]
If the structure is not on-line we get the next request in the
queue, the following entries will never be processed because we
do not advance the pointer to the next entry. We will loop "N"
times through this code where "N" is the number of entries in the
queue.
[CURE]
Move QSRQUE's DLF.1A label to correctly load the pointer.
********************************************************************************
EDIT 1213 FOR QUASAR
[Source After Edit] %4 (001213)
[SYMPTOM]
A print request of small files and numerous copies will be
aborted with the "? Page Limit Exceeded" error message; the
limit will be less than the number of file copies.
[DIAGNOSIS]
QUEUE passes QUASAR the correct file size and count, however,
QUASAR does not realize that there needs to be at least as many
pages as there are copies to print.
[CURE]
Teach QUASAR this so it calculates a better estimate.
********************************************************************************
EDIT 1214 FOR QUASAR
[Source After Edit] %4 (001214)
[SYMPTOM]
GALAXY does not allow the /ASSIST switch to be modified.
[DIAGNOSIS]
We don't have code in QUENCH, QMANGR, or QUASAR to support it: we
don't even have the bits defined.
[CURE]
Implement the bits and code to do this. WARNING: Both QUASAR
edit 1214 and QMANGR edit 2255 are required for this change to be
functional and safe. If these changes are not installed together
a batch modify request will either not work or the /BEGIN, /TAG,
or /ASSIST value will be modified in an uncontrolled fashion.
********************************************************************************
EDIT 1215 FOR QUASAR
[Source After Edit] %4 (001215)
[SYMPTOM]
QUASAR incorrectly determines that a certain type of disk drive
does not exist.
[DIAGNOSIS]
QUASAR's mask that is used to extract the Kontroller type for a
structure from a STRLST entry, CVL.KT, is not the correct size.
The STRLST entry allocates 6 bits for the kontroller type field,
CVL.KT is only 3 bits wide.
[CURE]
Change CVL.KT to be 6 bits wide so it matches the STRLST entry.
********************************************************************************
EDIT 1216 FOR QUASAR
[Source After Edit] %4 (001216)
[SYMPTOM]
The QUEUE. UUO .QBNOD argument sets the processing node instead
of the destination node.
[DIAGNOSIS]
The entire problem is in QSRQUE's CRQNOD routine. We write the
node information to the EQ's .EQROB+.ROBND field instead of the
.EQLIM+ONOD word.
[CURE]
Fix the code to do this.
********************************************************************************
EDIT 1217 FOR QUASAR
EDIT 1217
[Symptom]
Add support in QUASAR for new monitor .IPCST, structure
mounted, IPCF message. This message is received by QUASAR
when a structure is mounted by someone other than PULSAR, i.e.
OMOUNT or KLEPTO.
[Diagnosis]
yes
[Cure]
yes
********************************************************************************
********************************************************************************
EDIT 1221 FOR QUASAR
[Source After Edit] %4 (001221)
[SYMPTOM]
Undeserved deadlock errors when all disk resources are in use
and drives are attached and detached.
[DIAGNOSIS]
Volume-sets for unknown structures are not deleted when catalog
NAKs are received from PULSAR.
[CURE]
Delete these volume-sets.
********************************************************************************
EDIT 1222 FOR QUASAR
[Source After Edit] %4 (001222)
[SYMPTOM]
More of QUASAR edit 1212. Problems with more than five requests
and the following case.
QUASAR using inordinate amounts of runtime and not deleting
spooled files. This occurs when the first entry in QUASAR's
"delete file" list is for an off-line structure or the structure
nolonger exists. This case is only exercised when there is more
than one spooled file to delete and the structure is off-line.
[DIAGNOSIS]
We don't keep all the requests incore.
[CURE]
When there are file delete requests and we can't process
********************************************************************************
EDIT 1223 FOR QUASAR
[Source After Edit] %4 (001223)
[SYMPTOM]
Garbage messages or no messages from QUASAR in response to QUEUE
commands.
[DIAGNOSIS]
After a truncated long message of over 1000 characters containing
error strings, such as protection violation on a rename, QUASAR
does not clear the buffer full flag. All subsequent text strings
sent in response to a QUEUE command may be empty, truncated, or
contain garbage.
[CURE]
Fix the code to clear the flag.
********************************************************************************
EDIT 1224 FOR QUASAR
EDIT 1224
[Symptom]
Ocassionally, when using bypass labeled tapes, user jobs get
stuck in Event Wait for PULSAR.
[Diagnosis]
The problem is caused by an interesting race:
1. A priv'ed user requests bypass processing on a labeled tape.
2. QUASAR reassigns tape to user and sends PULSAR a "volume mounted"
messages which among other things, instructs PULSAR to set the
label type to bypass.
3. The user job starts to run and attempts I/O or tape positioning.
Seeing the label type is not bypass, the monitor puts the job in
event wait and sends a first I/O or positioning request to PULSAR.
4. PULSAR gets the monitor's request but according to his data base
the tape isn't owned by any job. PULSAR assumes the monitor is
confused and pitches the request without scheduling any work for
the tape. The user's job is now stuck waiting label DDB release
which will never happen.
5. PULSAR finally gets around to processing the "volume mounted"
message from QUASAR and sets the label type. By now, the damage
has been done.
Attempts to understand it's cause by taking a snapshot of the monitor
yield no useful data, as PULSAR will have most likely set the label
type to bypass by the time the dump is take. Lots of time can be
wasted looking for a flaw in the monitor which doesn't exist.
[Cure]
QUASAR should set the label type prior to reassigning the tape to
the user's job.
********************************************************************************
EDIT 2255 FOR QUEUE
[Source After Edit] %4 (002255)
[SYMPTOM]
GALAXY does not allow the /ASSIST switch to be modified.
[DIAGNOSIS]
We don't have code in QUENCH, QMANGR, or QUASAR to support it: we
don't even have the bits defined.
[CURE]
Implement the bits and code to do this. WARNING: Both QUASAR
edit 1214 and QMANGR edit 2255 are required for this change to be
functional and safe. If these changes are not installed together
a batch modify request will either not work or the /BEGIN, /TAG,
or /ASSIST value will be modified in an uncontrolled fashion.
********************************************************************************
EDIT 2256 FOR QUEUE
[Source After Edit] %104 (002256)
[SYMPTOM]
Typing a Control-C (^C) during a QUEUE listing may cause
subsequent QUEUE commands to display the wrong information.
[DIAGNOSIS]
If the queues are large, it may take several IPCF messages from
QUASAR to the QUEUE program to display the queues to the user.
This may exceed the user's IPCF receive quota. If this happens,
the send fails and QUASAR waits for a bit and then retries the
send of the IPCF message containing part of the queue listing.
Meanwhile, if the user types 2 Control-Cs, and then enters
another QUEUE command, text from the previous QUEUE command may
be displayed, confusing the user. Since QUEUE's PID is its job
number, QUEUE displays all messages from QUASAR that it
recognizes, it has no way of distinguishing which invocation of
the program (QUEUE) resulted in QUASAR sending the message.
[CURE]
An "until RESET" PID should be used, but we can't require SYSINF
to be running. So, add code that implements an ACKing code,
similar to what was done to keep MOUNT and QUASAR in synch. If
QUEUE receives a message that doesn't contain the ACK code it was
expecting, throw away the message.
********************************************************************************
EDIT 2257 FOR QUEUE
[Source After Edit] %104 (002257)
[SYMPTOM]
Illegal memory reference at user PC 400010 after GETSEGing
QMANGR.EXE and executing the instruction at what should be the
entry point.
[DIAGNOSIS]
COPYRIGHT macro generated ASCII text starting at 400010, which is
QMANGR's entry point.
[CURE]
Move COPYRIGHT macro after PORTAL QMANGR at 400010. This will
keep the entry point the same as it has been.
********************************************************************************
EDIT 521 FOR QUEUE
[Source After Edit] %4 (000521)
[SYMPTOM]
QUEUE does not process the /BEGIN and /TAG switches correctly.
[DIAGNOSIS]
The code is oblivious to the multiplexed nature of the /TAG and
/BEGIN switches.
[CURE]
Change QUEUE so 1) conflicting switches typed by users will be
detected using SCAN's functionality and 2) pick up the SWITCH.INI
defaults if the /TAG and /BEGIN switches are not in the command
line.
********************************************************************************
EDIT 522 FOR QUEUE
[Source After Edit] %4 (000522)
[SYMPTOM]
GALAXY does not allow the /ASSIST switch to be modified.
[DIAGNOSIS]
We don't have code in QUENCH, QMANGR, or QUASAR to support it: we
don't even have the bits defined.
[CURE]
Implement the bits and code to do this. WARNING: Both QUASAR
edit 1214 and QMANGR edit 2255 are required for this change to be
functional and safe. If these changes are not installed together
a batch modify request will either not work or the /BEGIN, /TAG,
or /ASSIST value will be modified in an uncontrolled fashion.
********************************************************************************
EDIT 4255 FOR SPRINT
[Source After Edit] %104 (004255)
[SYMPTOM]
System security. A 'dataset' user can submit a batch job for a
'non-dataset' account (PPN) if the password for the 'non-dataset'
account is known. The batch job has to be submitted from cards
(real reader or IBMCOM) or via SUBMIT /READER.
[DIAGNOSIS]
Passwords are sometimes not enough security.
[CURE]
Until additional security features are added to the TOPS-10
software, add some conditional code in SPRINT that prevents
the above possible breach of security. Invent 2 conditional
assembly parameters, LGNPHY and LGNPSU, that turn code 'on' which
prevents accounts (PPNs) from logging in under batch that
normally cannot login from a 'dataset' or 'remote' terminal. If
LGNPHY is nonzero, batch jobs submitted from spooled card decks
created by CDRIVE will not be allowed to login under batch if the
target account cannot login 'dataset' or 'remote'. If LGNPSU is
nonzero, batch jobs created via SUBMIT /READER will not be
allowed to login under batch if the target account cannot login
'dataset' or 'remote'. The values of LGNPHY and LGNPSU in our
sources will be zero, 'off'.
********************************************************************************
EDIT 4256 FOR SPRINT
[Source After Edit] %104 (004256)
[SYMPTOM]
The $CREATE card /PRINT switch is sticky. All $CREATEd files
after the first file are printed regardless of the $CREATE's
absence of a switch.
[DIAGNOSIS]
We are not zeroing the /QUEUE:FLAG field, L.QFN.
[CURE]
Zero the flag.
********************************************************************************
EDIT 2537 FOR SPROUT
[Source After Edit] %4 (002537)
[SYMPTOM]
SPROUT may loop if SPFORM.INI doesn't exist or plotter request
doesn't match a switch line in SPFORM.INI after edit 2534 is
applied.
[DIAGNOSIS]
Edit 2534 setup certain defaults for units and step sizes, but in
either of the above scenarios, certain parameters aren't
converted to steps like the plotting code expects them.
[CURE]
Make sure all conversions from units to steps are done regardless
of what happens during SPFORM.INI processing. Rearrange some of
the code edit 2534 added.
********************************************************************************
EDIT 2540 FOR SPROUT
[Source After Edit] %104 (002540)
[SYMPTOM]
Can't clear job stuck on a plotter that is having hardware
problems. ABORT PLOTTER /PURGE doesn't always work.
[DIAGNOSIS]
When purging a job, SPROUT tries to flush the output buffers
releasing the job. If for some reason output can't be done,
SPROUT waits indefinitely, never releasing the job.
[CURE]
On ABORT PLOTTER /PURGE, don't worry about flushing the output
buffers, just release the current job.
********************************************************************************
END OF GALAXY-10-V702