Trailing-Edge - PDP-10 Archives - bb-bt99g-bb - cbl12b.d07
There is 1 other file named cbl12b.d07 in the archive. Click here to see a list.
                 EDIT DESCRIPTIONS FOR COBOL-20-V12B                            
                             EDIT 45     FOR COBDDT
COBDDT does not ACCEPT COMP-1 numbers if they contain a decimal point.
There is no code to input floating point numbers.
Implement ACCEPT of floating point numbers.
                             EDIT 46     FOR COBDDT
A 'STEP' command will print the wrong paragraph names if the
user has used the 'MODULE' command to specify a symbol table
for a module other than the  one  that  is  currently  being
For symbol resolution, there is only set of  pointers  being
maintained.   If  the  user  wants  to refer to symbols in a
module other than the one currently being executed,  he  has
to  use  the  'MODULE'  command which will adjust the symbol
table pointers.  If execution  continues  without  resetting
the  symbol  module  back  to  the  module  being  executed,
incorrect paragraph names  will  be  listed  by  the  'STEP'
Edit 46 to COBDDT will keep another pointer for use  by  the
routine which prints out paragraph names so that the address
of the currently executing paragraph can be resolved to  the
correct name.
                             EDIT 1460   FOR COBOL
When a key  is  subscripted,  either  no  error  message  is
prompted  or a wrong error messgae is displayed at the wrong
If the key being referred to in the Procedure Division is  a
subscripted  dataname in the Data Division, an error message
should be displayed to indicate  that  subscripting  is  not
allowed  for  keys.  But, due to an error in the compiler, a
wrong error message is displayed at the first  line  of  the
program;  and if the dataname preceding this key in the Data
Division is also subcripted, no error message  is  displayed
at all.
The compiler only checks  for  subscripting  in  the  SELECT
statement.   When  it reads the "KEY IS dataname" statement,
it does not check to see if this dataname is subscripted  in
the  other divisions.  In the Data Division, there is no way
to check every dataname to see if it is a key before outputs
the dataname to GENFIL for phase E to process;  furthermore,
in the Procedure Division, the "READ file KEY  IS  dataname"
is   processed   without  checking  for  subscripting.   The
compiler doesn't know that it is  using  an  incorrect  data
structure   to  process  the  statements  in  the  Procedure
Division and causing erroneous results.
Edit 1460 to COBOLD and DIAGS  to  check  in  the  Procedure
Divison to see if the key name is subscripted, if so, give a
fatal error message.
                             EDIT 1461   FOR COBOL
Bad results are generated from  COMPUTE  statements  if  the
fields are converted into two word floating point data.
When testing data modes to  see  if  one  or  two  words  of
temporary  space is needed to hold intermediary results, the
mode F2MODE is often not tested.
Before all calls to GETEMP to request temporary space,  test
for  F2MODE  as  well  as  D2MODE.  Edit 1461 to EXPGEN will
provide the necessary tests.
                             EDIT 1462   FOR COBOL
A program in which SEGMENT is mistakenly substituted for SECTION after
a paragraph name gets a compiler error.
Two reserved words have the same token value.  These are  SEGMENT  and
COMPILER-BREAK-IN-PHASE.   The  latter is a special reserved word only
available with the debugging version of the compiler  (i.e.   DEBUG==1
in  the  build).   However  the  syntax  for  it  is  available in the
procedure division phase.  After the compiler has seen  the  paragraph
name  it looks for an acceptable verb.  SEGMENT is not one of these so
it  should  take  the   default   path   and   try   something   else.
COMPILER-BREAK-IN-PHASE  would  be  acceptable  and  in  the debugging
compiler would do the correct thing.  However because they  share  the
same token SEGMENT causes this action to be done but since this is not
the debugging compiler the compiler gets confused and dies.
Change the token value for COMPILER-BREAK-IN-PHASE in P.MAC.   Compile
P  and DTREE.MAC and reload.  The change in COBOLA.MAC is just to make
the documentation match the  code  so  COBOLA  does  not  need  to  be
recompiled to fix the bug.
                             EDIT 1463   FOR COBOL
A COPY REPLACING ...  BY ==pseudo-text==
fails if the BY and the following == are not on the same line.
The lexical scanner routine when it sees BY stores the  current  input
pointer  and  reads  on  until it encounters the terminal ==.  All the
text between these points is stored in a buffer.  The  initial  ==  is
then  deleted  by overwriting them by two nulls.  If the BY and the ==
are on the same line this works because  the  input  byte  pointer  is
positioned  at the last space after the BY.  However if the == is on a
new line the byte pointer stops at the end  of  the  line.   Thus  the
overwriting  by  nulls wipes out the carriage return and line feed but
leaves the initial == still there.
Delete all characters from the byte pointer up to, and including,  the
initial ==.
                             EDIT 1464   FOR COBOL
Edit 1450 flags the error messgae at the wrong line.
There was an error in edit 1450 which results in calling the
routine OPNFAT instead of OPFAT and causes the error message
to flag at the wrong line.
Edit 1464 to IOGEN to call the correct routine.
                             EDIT 1465   FOR COBOL
None observed but code is wrong.
Edit 1354 is a change to phase D of the compiler but it uses
a  location defined in the storage for phase E.  Some of the
storage for phase D overlays the storage for phase E, KEYRLN
is one such word.  Thus any change to KEYRLN in phase D will
change the value of some other word defined in phase D.   No
bad effects have been seen up to now because it falls in the
middle of a DBMS INVOKE buffer.
Define a word in the phase D storage and use it rather  than
                             EDIT 1466   FOR COBOL
Data in a file with a recording mode of STANDARD ASCII  will
not  be  written properly if WRITE statements include either
The routine which determines the size of the required buffer
space for a file will not include space for carriage returns
or line feeds if  the  file's  RECORDING  MODE  is  STANDARD
ASCII.   When  a WRITE statement is processed for that file,
and if it included one of the above clauses, LIBOL will  put
out  the  extra line control characters which will cause the
buffer to be filled earlier than expected and force a  write
to  the  specified  device  at  the  wrong  time,  causing a
distortion of the data.
Since we do not want line  control  characters  in  STANDARD
ASCII  files,  we  are  issuing edit 1466 to the compiler to
give  a  fatal  error  on  any  WRITE  statements   with   a
                             EDIT 1467   FOR COBOL
[S] When relinking the COBOL compiler, the undefined  global
ALCPA.  may be detected.
[D] The routine ALCPA.  is called from SCHIO2, as  a  result
of  DBMS-20  V.6 edit 473.  If a custoem installs that edit,
and then subsequently attempts to relink the COBOL  compiler
using the DBMS-patched SCHIO2, the undefined ALCPA.  will be
[C] Resolve ALCPA.  within the module  DBGETF,  where  other
DBMS-type  memory  management  calls  are  resolved  for the
                             EDIT 1470   FOR COBOL
If edit 1447  is  installed,  the  module  IPCGEN  will  not
assemble.  If edit 1451 is installed, the module RPWGEN will
not assemble.
Edit 1447 failed to declare the routine PUTAYY as  external.
Edit 1451 failed to declare the field LMASKR as external.
Edit 1470 to IPCGEN  and  RPWGEN  will  declare  each  field
                             EDIT 1471   FOR COBOL
     The "LINE IS x" clause in a TYPE PH item fails to advance to  the
next page if the LINE clause is on an 01 level entry and preceded by a
TYPE RH report group with a line clause greater than 1.
     When generating the code for any report group, a test is made  to
see  if a call to the LIN.H routine is required to advance to the next
page.  If the group  is  TYPE  PAGE  HEADING  and  is  generating  the
initialization  section of the report, the call to LIN.H should always
be generated.
     If the group is TYPE PAGE HEADING and the code being generated is
the  initialization  code,  skip  the  test to find out if the call to
LIN.H is necessary.
                             EDIT 1472   FOR COBOL
During compilation, the message  "?   ASSEMBLY  ERROR:   ***
COMPILER BUG!  ***" appears on the terminal.
A DIVIDE  statement  with  a  literal  as  the  divisor  and
multiple  dividends  is not storing the divisor so it can be
used again.  The routine which attempts to  restore  it  for
the next divide restores garbage.
After setting up the B operand, return to the division  code
that  will  store  it if it is being used in a series.  Edit
1472 to MATGEN will test to see if the literal is being used
in  a  series  and  go  to  the  same  area  of  code that a
non-literal falls through.
                             EDIT 1473   FOR COBOL
A truncation warning will be generated on  a  REPORT  WRITER
statement  which  uses  the  compiler-generated PAGE-COUNTER
field as its source  if  the  PICTURE  clause  precedes  the
SOURCE  clause  and  the  PICTURE  accounts for fewer that 6
digits.  No warning will be given if the  SOURCE  clause  is
before the PICTURE clause.
The size of the compiler-generated PAGE-COUNTER is  adjusted
to match a user-defined field if the user's field is defined
before the SOURCE statement is scanned.  This will eliminate
any  truncation  warnings later and allow the user to adjust
the PAGE-COUNTER size to what seems more reasonable.  If the
size  of  the  user's  field is not stated before the SOURCE
clause is processed, no adjustment  is  made,  and  warnings
will  be  generated  later  if  it  appears  a truncation is
Edit 1473 to MOVGEN will test on the DA.LPC bit (data  field
is a line/page counter) in a source item of a move statement
and adjust the size to match that of the  destination  field
as long as it is not larger.
                             EDIT 1474   FOR COBOL
Edit 1450 flags an error message for "FREE EVERY RECORD".
Edit 1450 did not include "FREE  EVERY  RECORD"  as  correct
syntax  when  the checking was done.  Therefore the compiler
thinks the syntax is wrong and flagged the error message.
Edit 1474 to IOGEN to include "FREE EVERY RECORD" as correct
                             EDIT 1475   FOR COBOL
Register TE is corrupted by edit 1452 to COBOLC.
Edit 1452 was incorporated into COBOLC to remove  the  FATAL
THIS GROUP.  At DA85.X + 3 where a  deposit  byte  is  being
done  to  store away the DATAB link to the RESET identifier,
there's a possibility  that  TE  may  have  previously  been
clobbered.   Since  the  fix utilizes TE heavily and the DPB
also depends on TE, it is probably  unwise  to  assume  that
after  executing  this  code  the contents of TE will remain
To remedy this situation you should change the TE's in  edit
1452  to  TC's.   Register  TE will now strictly contain the
correct DATAB link and leave any changes to be made with TC.
                             EDIT 1476   FOR COBOL
A catastrophe in phase E with a bad  table  link  at  502261
after doing an alphabetic/numeric check on a non subscripted
In the module CMNGEN at location EXMS9+12  a  load  byte  is
done  to  see if an occurs clause is seen at this level.  In
the event that DA.OCC is zero (i.e.  no occurs  clause),  an
error  message  specifying  "FATAL - May not be subscripted"
should be generated.
Add a JRST NOTSUB at EXMS9+15 to produce the  correct  error
message.  Remove the other suggested lines of code.
                             EDIT 1477   FOR COBOL
The result from a COMPUTE statement is incorrect.
To adjust for floating point results that  may  be  slightly
off  (5.1699999999  instead  of  5.17),  a  small correction
factor is generated and added to the  result  before  it  is
moved  to the destination field.  This factor was previously
1/500 of the normal rounding value that  would  be  used  if
requested  (A  rounding  value  of  .5  would  result  in an
adjustment  value   of   .001).    Since   this   value   is
insignificant  to  the  destination  (being 3 decimal places
more  significant),  we  assumed  it  could  only   increase
accuracy.   It  is  possible though that it could adjust the
value of the intermediary field if the number of significant
decimal  places  being maintained is greater than the number
of  decimal  places   in   the   correction   factor.    (An
intermediary  value  of .99998 being stored in a destination
field with no  decimal  places  should  yield  a  zero,  the
current  correction  factor  of  .001  is  causing  a '1' to
result.) (If the user expected a '1' in the  example  above,
the use of the 'ROUNDED' clause will yield it.)
Edit 1477 to CMNGEN will alter the value of  the  correction
factor  consider the number of significant decimal places in
the source fields as well as in the destination field.
                             EDIT 1500   FOR COBOL
Unexpected results occur when programmers use  HIGH  or  LOW
-VALUES with numeric fields.
This is a DEC extension to the COBOL language which  is  not
thoroughly  explained  in the manual.  It appears that users
expect the highest numeric  value  instead  of  the  highest
collating  sequence  value.   Also, for COMP items which are
word  based  and  not   character   based,   there   is   no
corresponding collating sequence so we are using the highest
numeric value.
Since this is a DEC extension to the language we are issuing
edit  1500  to  produce  warnings where this feature is used
with the aim of eventually phasing it out.
                             EDIT 1501   FOR COBOL
RMS cannot correctly  handle  files  using  variable  length
alternate keys.
RMS is not intended to handle such  keys.   The  COBOL  ANSI
standard does not allow such keys.
Edit 1501 to CLEANC will  provide  a  syntax  error  on  any
alternate key that is variable length.
                             EDIT 1502   FOR COBOL
The record size used by WRITE and REWRITE verbs is the  size
of  the  record  format  specified,  which may not match the
record size stated in the FD clause, nor the maximum  record
size,  if  there  is more that one record format for a given
file description.  This  means  that  records  of  different
sizes  can  be  written  to  a  file  and  will  have  to be
maintained by these different formats, or subsequent  writes
by different formats may change the size, and therefore, the
data these records contain.
The compiler does give a warning that a record  size  stated
in  an  FD  clause  will  be  ignored  if a record format is
larger, but if a record  format  is  smaller,  there  is  no
warning  and  a different size records can be written out to
the file.  Though the OTS can  process  these  records,  the
user  may  not  have  intended the records to have different
formats and has no way of knowing that this has occurred.
Edit 1502 to CLEANC and DIAGS will produce a warning on  all
record formats smaller than the largest record format (whose
size will be used as the file's record size).
                             EDIT 4      FOR CPYLIB
CPYLIB fails with "?CPYREL Premature EOF in library file" if
library contains a multiple of 64 entries.
When CPYLIB reads in the fine table into  memory,  the  last
block  is  always  read in as an incomplete block.  It is to
continue reading this block until it either  encounters  the
end  of  table  signal (-1), or finishes reading the maximum
number of entries  in  a  block  (64).   But  the  erroneous
instruction  SOJG  makes  CPYLIB  return without reading the
word after all the entries, which contains -1 to signal  the
end of the table.
When CPYLIB copies the input into the temp file for  output,
it  goes  down  the fine table directory that it read in and
expects to find either another entry or  the  -1.   When  it
couldn't find either, it decided this is a premature EOF.
Edit 4 to CPYLIB to read in the word for end of table.
                             EDIT 5      FOR CPYLIB
A fatal error occurs at compile-time, stating that a  libary
file cannot be found.
The rough table entries (that point to the fine table blocks
which  have  an  entry  for  each  module)  contain  only  6
characters even though the module names can contain up to  8
characters.   This  makes it possible for the search routine
which scans the rough table to go to the  wrong  fine  table
block  and  miss  a  module  entry,  making it appear to the
compiler that the module is not located in the library file.
Edit 5 to CPYLIB will change the routine which  makes  rough
table entries so it will store the 7th and 8th characters of
a module name.
                             EDIT 6      FOR CPYLIB
CPYLIB.MAC  will  not  assemble  correctly   with   edit   5
The bit definition for F%%SEQ  cannot  be  used  in  a  TLXX
Use a TXO instruction and let the macro  routine  figure  it
                             EDIT 207    FOR ISAM
Edit 205 does not type out the correct file error.
The correct error status is complemented to  see  if  all  4
bits  are  on.   However  this complemented value is used to
type out the error status.
Fix the test to do the second complement before  typing  out
the message.
                             EDIT 210    FOR ISAM
Edit 204 doesn't work correctly if input  and  output  modes
are mixed.
The record pointer points to the output data file, therefore
the  input  mode  for  the  routine  to  type out the record
content should be the same  as  the  output  file,  not  the
original data mode of the input file.
Edit 210 to ISAM to set the correct input mode.
                             EDIT 211    FOR ISAM
Using the ISAM  utility  to  build  an  index  file  from  a
sequential  file  previously packed onto a tape using the /L
option will result in the error message:
        ?File name does not match tape label id
The file cannot be restore.
The routine which reads the tape calls  the  GETBYT  routine
and  expects  to  read one byte of the label at a time.  The
GETBYT routine will read either a byte or a record depending
on  the setting of the bit ONEBYT in the switch word.  Since
this bit is off, the GETBYT routine is  reading  the  entire
label  and the first few records, and depositing the data in
the wrong place.
In the routine which processes the label, before calling the
GETBYT routine, edit 211 will set the bit ONEBYT.
                             EDIT 1065   FOR LIBOL
FREE with key does not work after a RETAIN NEXT,  READ  NEXT
on a relative file.
RETAIN NEXT on a relative file does not put the key  in  the
Retained   Records   Table,   it   only  sets  the  bit  for
retain-next-record flag.  But the "FREE file-name REOCRD KEY
key"  looks  for  a  key  from the Retained Records Table to
match the specified key in the FREE statement.  When the key
is  not  found,  it  thinks the record is never retained and
sets the not-retained flag and returns unless  there  is  an
NOT RETAINED path for it to take.
Edit 1065 to CBLIO and LSU to store the key in the  Retained
Records table.
                             EDIT 1066   FOR LIBOL
     Recording mode is standard ascii does  not  produce  8  bit  byte
records when using standard labeled tapes.
     When using tapes that have monitor labels, LIBOL assumes that the
files  are  opened  as 8 bit bytes.  The monitor opens the tape with 8
bit bytes when the tape is standard labeled, and has a  record  format
of  D.  When using standard labeled ascii tapes LIBOL does not set the
format to D, and so the monitor opens the tape  to  whatever  the  SET
TAPE FORMAT is ( ie.  if SET TAPE FORMAT CORE-DUMP opens the tape with
36 bit bytes ).
     Whenever LIBOL opens a monitor labeled tape that has a  recording
mode of either standard ascii or ascii, set the record format to D.
                             EDIT 1067   FOR LIBOL
Edit 1065 to module LSU doesn't work correctly.
Edit 1067 made the READ  verb  bypass  the  instructions  to
calculate  the  block  number  for relative files and so the
block number is always zero,  thus  locks  the  whole  file.
When  two programs are updating the same relative file, each
program can't read the record the  other  program  has  just
updated  and  would  ignore  the change that was made by the
other program.
Edit 1067 to remove edit 1065.
                             EDIT 1070   FOR LIBOL
If the use's OTS has been built with the NUMSTD  switch  set
to  zero,  numeric  data  declared  with  either  leading or
trailing separate sign will not be handled correctly  if  it
requires  a translation from display mode to binary mode for
further processing.
The translation function used by the extended instruction to
convert  the data from display mode to binary was originally
designed to be used for numeric testing only.   It  did  not
translate  the  digits,  but only verified whether they were
allowable characters in a numeric field.   The  function  is
now  being  used by the conversion instructions and needs to
be changed.
Edit 1070 to NUBSTB will alter the construction of the table
NUMS.7  for  ASCII  and  SIXBIT  translation so that numeric
digits will be translated as well as verified.   (This  will
now  match the table build by a standard LIBOL build).  This
edit is needed only for ANSI 74 OTS's built with the  NUMSTD
switch set to zero.
                             EDIT 1071   FOR LIBOL
With RMS-20 files,
if two or more fatal file access errors occur as a result of setting the
action-code in a USE Procedure under Declaratives, the contents of File
Status field 2 gives the running total of all the error code values which
have occurred during the program run.
Under control of a USE Procedure in Declaratives the File-Status field 2,
which contains the 10-digit error number, is not cleared when a new error
is encountered, with the result that the contents of this field are
cumulative when the error number is computed.
Install Edit 1071 to LBLERR.MAC and rebuild your LIBOL or C74LIB. This
edit will cause the File-Status field 2 to be reset each time it is about
to be computed.
                             EDIT 1072   FOR LIBOL
Programs which require data to be  converted  from  one-word
floating point to two word comp may execute incorrectly.
If edit 1004 is not installed, the sign bit will  be  turned
on  in  the  wrong  word  of  the  result.   If edit 1004 is
installed, the sign bit will be turned  on  in  the  correct
word, but this should not be done if the result is zero.
Edit 1072 to FIX.MAC will test first to see if the  two-word
result is zero and if so, will not turn on the sign bit.
                             EDIT 1073   FOR LIBOL
An RMS file that is closed with delete will not be deleted.
Though the flag bit for DELETE is being set properly, it  is
not  tested  on  in the LIBOL module RMSIO, so no request is
issued to the RMS utility to delete the  file  after  it  is
Edit 1073 to RMSIO will test on the flag  bit  CLS%DL  after
the  file  is  closed, and call the $ERASE routine in RMS to
delete a file if the program requests it.
                             EDIT 1074   FOR LIBOL
If a negative two word  comp  field  is  entered  through  a
terminal, it may be converted incorrectly into computational
After the digits have been converted and the two word  field
is  built,  the  sign flag is tested.  If it is on, the twos
complement of the number is  formed  by  complementing  both
words  and  adding one.  The 'one' is added to the low order
word, if the result is non-zero, the routine is exited.   If
the  result  is  zero,  then  one is added to the high order
word.  The error is occurring when the result of  the  first
add  is negative zero, the routine is still exited though it
shouldn't be.
Edit 1074 to ACCEPT.MAC will test on the  carry  flag  after
the first 'add one' is done, and if it is set, will zero the
sign bit of the low order word and add one to the high order
                             EDIT 1075   FOR LIBOL
Some records in a multi-level ISAM file may be missed  on  a
START, READ NEXT sequence.
In module CBLIO at SREAD+2 when UPDOWN is called to bring in
the  next  data  block, some records might be skipped due to
LRW not being updated.
                             EDIT 1076   FOR LIBOL
Very large programs will fail in an unpredictable fashion.
If the .EXE file built by LINK extends into  the  area  that
the  OTS  assumes is available for its own use, that part of
the  .EXE  will  be  overwritten  by  the  OTS  and  program
execution  will  continue  until  the  overwritten  area  is
accessed in an attempt to retreive application code or data.
Edit 1076 to COBST.MAC will add an  error  handling  routine
after  the  GET  call  which  loads  in the OTS.  If the OTS
cannot be loaded, a fatal error message will be printed  and
execution  halted.   In  the  case  of a program that is too
large, the user will be advised to  recompiled  the  program
using  the  compiler's  switch  /R which will direct LINK to
load the OTS with the application into the .EXE file.
                             EDIT 1077   FOR LIBOL
Records within the same data block may be  duplicated  if  a
relative  file  is accessed dynamically and selected records
One of the data records had a  different  format  which  was
smaller.   It  was  rewritten using the second record format
and increased in size.  The record pointers into the  buffer
were  not  adjusted  when  the record was lengthened, so the
pointers were still  pointing  at  where  the  record  ended
before  it  was rewritten.  There were now extra blank words
at the end of this record which were interpreted  as  header
words  for  deleted records.  Therefore the record count was
increased incorrectly.  When  rewriting  subsequent  records
the  incorrect  record  count  was used, and the records put
back into the buffer in the wrong place.  The error repeated
until  the  entire  buffer was processed and another read to
disk requested.  At that point the record  count  was  reset
and  then  maintained correctly since all successive records
had the same size.
Edit 1077 to CBLIO will provide an additional  test  on  the
access  mode  of  a file and update the record pointers into
the buffer if the access mode is dynamic,  as  it  does  for
sequential.   We  are  also  issuing edit 1502 to CLEANC and
DIAGS to provide warnings at  compile  time  if  the  record
formats for the same file are of different lengths.
                             EDIT 1100   FOR LIBOL
When two jobs updating the same relative  files  using  SMU,
sometimes  one  of  the  jobs erroneously gets INVALID WRITE
LIBOL on TOPS-10 lets the monitor do  the  flushing  of  the
buffer  instead  of  forcing to write the buffer to the disk
itself, thus creates a race condition.
Before the monitor could flush the buffer that the first job
had just written out, the second job tried to write the same
record and got the INVALID WRITE error.
Edit 1100 to CBLIO to force write the buffer out to disk.
                             EDIT 1102   FOR LIBOL
The fatal error message
 FILE file-name [filename] CANNOT BE OPENED ON DEVICE DSK:
will appear when the second user attempts to open a file for
simultaneous update.
If edit 1007 is installed in LIBOL at a  site  that  is  not
using  at  least  monitor version 5.0, the read unrestricted
bit (OF%RDU) that is  used  to  open  a  file  will  not  be
defined.  The open mode will become frozen by default, which
will not allow other users access to the file.   If  someone
else  has  previously  claimed  access to the file in thawed
mode, the second open will fail.  This will  occur  even  if
the  user  has  specified simultaneous update syntax in both
programs because the open that is failing is being  done  at
RESET  time  to  determine the necessary buffer space and is
ignoring the user's specifications.  LIBOL attempts to  open
the  file  temporarily  using  the  unrestricted read option
which is unavailable before version 5 of the monoitor.
Edit 1102 to CBLIO and COMUNI  will  make  all  code  within
TOPS2X  conditional  brackets  TOPS20 code and add a test on
the monitor level before attempting to execute it.  At reset
time,  before  opening  any files, the monitor level will be
                             EDIT 1103   FOR LIBOL
Under COBOL-10, the RETAIN statement occasionally causes a Simultaneous
Update program accessing an ISAM file to fail with a Fatal End-of-File
If two or more COBOL-10 SMU users are accessing the same file under SMU
Open for some type of Update or ANY, one of them may encounter a race
condition within the LIBOL SMU code which causes the TOPS-10 IN UUO to
take the error return with the IO.EOF bit set. This can happen because
LIBOL SMU code attempts to read the user's ISAM file prior to setting
the requested record locks. This is done in order to ascertain the file
block number on which the record should or would reside. Thus, the SMU
code is actually circumventing the ENQ locking procedure in order to
acquire information which is necessary in order to acquire the locks
for the user. Until the lock is established, there is no protection for
the retrieval being done by the Retain. In most cases this is no problem
because SMU merely wants to know if the file block exists and what its
block number is. Or, on the other hand, if the block does not exist, SMU
receives a null block number, which signifies that it should ask for a
lock on record 0, which is interpreted as a lock on the entire file.
(This Read has come to be called a "Fake Read" and it uses the same
LIBOL code for the most part that is used for regular Reads.)
Occasionally, when a block is in the process of being created on the disk
file, another user may do a Fake Read to it via the Retain statement.
If the other user makes the unprotected retrieval between the time that the
file's RIB is updated to point to the new file block and the time when
the block is written to disk, he will be doing a retrieval which is
momentarily outside the range of the file. This is why the IN UUO takes
the error return and the IO.EOF bit is set. (It is noteworthy that none
of the other bits were set, including IO.ERR.) Accordingly, it appears
that the IN UUO does not regard this problem as serious. When the LIBOL
code saw theerror return, it interpreted it severely, giving the program
failure. However, an investigation of the LIBOL code involved in the Fake
Read revealed that it was already prepared to return a block number of 0
in the event of the EOF return. Thus, there was no need to force the
program failure in this case.
In order to ascertain whether we have encountered this situation, we
should test three things: (1) Are we doing a Fake Read? (2) Do we have
a serious error on the IN UUO? and (3) Is the EOF flag set? If the
answers are (1) Yes, (2) No, and (3) Yes, then the program execution can
continue without risk. These tests are implemented in edit 1103 to LIBOL.