Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

                 EDIT DESCRIPTIONS FOR DBMS-10-V5A                              
  
  
                             EDIT 601    FOR DBMS
  
[SYMPTOM]
  
With Edit 544 installed, a FIND rse5 on a CALC record  wins  a  356
error, "Data inconsistent".
  
  
[DIAGNOSIS]
  
The area involved contained two different records stored CALC,  one
of  which  was  not  contained  in  the  sub-schema  invoked by the
program.  Edit 544 attempts  to  check  data  integrity  with  each
record  fetched.   During  these  checks,  data is fetched from the
in-core record block for the record being checked.  In  this  case,
records  of  different types CALCed to the same CALC chain, so when
following the CALC chain  to  the  desired  record,  a  record  was
fetched  which  was not in the sub-schema.  No in-core record block
existed and the tests operated on spurious  data,  failing  with  a
xx56 error.
  
  
[CURE]
  
Replace edit 544 with edit 601, which does the  same  checking  but
ensures  that  an  in-core record block exists before doing further
tests.  If there is none, then bypass the rest of the tests.
********************************************************************************
  
  
                             EDIT 602    FOR DBMS
  
  
  
  
[SYMPTOM]
  
     DBMEND commands which require positioning to the end of
the journal can fail with the diagnostic:
  
   ?MNDFAE UNABLE TO: START READING FROM LAST CHUNK IN JOURNAL
  
This can easily happen  with  a  large  journal  (over  6000
blocks) which has been closed such that the journal has been
overwritten (only the label page has valid  information  for
the current sequence).
  
[DIAGNOSIS]
  
     A binary search algorithm is implemented to locate  the
last  page  in the journal with the current journal sequence
number.  The search starts with a  range  the  size  of  the
whole  journal,  and  repeatidly halves the range during the
process of the search.  The search terminates when the range
is  3  pages or less, allowing a short serial backwards walk
to  definitively  locate  the  desired   last   used   page.
Unfortunately   the   range  'extent'  value  is  maintained
independently of the  actual  range  size  between  any  two
points  which  are being searched, and it is also rounded up
for odd length extents in an effort  to  prevent  collapsing
too fast because of truncation when the extent is divided by
2.  The combination of these aspects of  the  algorithm  can
result  in  an  extent value which is larger than the actual
range size between any two points, and  if  the  search  has
been   entirely   uni-directional,   can  easily  result  in
computing a block number which is outside  the  valid  block
numbers  for  the  file (either less than 1, or greater than
the largest allocated).  It is  this  last  situation  which
produces the MNDFAE diagnostic.
  
[CURE]
  
     Rework the binary algorithm slightly to  recompute  the
search extent based on the end points of a particular search
range.  This causes slightly slower convergence towards  the
desired  point  of  the  file  (and a few extra reads in the
process), but it will always work, regardless of the size of
the file, or the direction of the search.
********************************************************************************
  
  
                             EDIT 603    FOR DBMS
  
  
  
  
[SYMPTOM]
  
     Sites  with  edit  557  installed  can  receive  random
unexpected  SUS (xx62 system in undefined state) exceptions,
even when all failing transactions are properly  backed  out
via  a  run-unit  using before images from the journal.  The
incidence of these occurrances  is  dimished  by  edit  576,
however  they  will  still  occasionally  happen.   The only
physical  symptom  is  that  the  journal  JUS  (Journal  in
undefined  state)  flag  is  set (-1 in word 30 of the first
journal page).
  
[DIAGNOSIS]
  
     Edit 557 was designed to prevent simultaneous  updators
from  continuing to update a data base that had been left in
a questionable state via an update exception returned to any
one  of  the  updating  run-units.   It  accomplised this by
checking for an error flag being on,  and  leaving  the  JUS
word  on in the journal label page for the other updators to
detect.  Unfortunately  this  situation  occured  for  every
update  exception that failed, even though the exception may
have been recovered by an automatic backup or  a  subsequent
call  to  JBTRAN.   Edit  576 tried to soften the effect for
subsequent calls for the run-unit that  initially  left  the
JUS condition, but did not address the actual problem.
  
[CURE]
  
     Check the internal SUS flag to determine whether of not
to leave JUS set when leaving DBCS.  If the exception occurs
outside a transaction, the automatic rollback will clear the
SUS state internal to the DML call, and JUS will not be left
on.  If inside a transaction,  the  data  base  will  remain
locked  via  the  ENQ  until  the  run-unit  calls JBTRAN to
backout the transaction, at which point the SUS  state  will
be  turned  off,  and  JUS will be cleared on DBCS exit.  Of
course, if there is  no  active  journal  containing  before
images,  there  is no possibility of rollback, and hence JUS
(if there is a journal at all) will remain on until  cleared
via  some external recovery method (usually terminating with
a DBMEND UNLOAD command).   Also,  if  a  transaction/update
verb is aborted (via system crash or program abort) JUS will
remain on until manually cleared.
  
This edit removes both edits 557 and 576.
********************************************************************************
  
  
  
END OF  DBMS-10-V5A