Google
 

Trailing-Edge - PDP-10 Archives - bb-bt99g-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