Google
 

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