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
[SYMPTOM]
COBDDT does not ACCEPT COMP-1 numbers if they contain a decimal point.
[DIAGNOSIS]
There is no code to input floating point numbers.
[CURE]
Implement ACCEPT of floating point numbers.
********************************************************************************
EDIT 46 FOR COBDDT
[SYMPTOM]
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
executed.
[DIAGNOSIS]
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'
command.
[CURE]
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
[SYMPTOM]
When a key is subscripted, either no error message is
prompted or a wrong error messgae is displayed at the wrong
line.
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.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
Bad results are generated from COMPUTE statements if the
fields are converted into two word floating point data.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
A program in which SEGMENT is mistakenly substituted for SECTION after
a paragraph name gets a compiler error.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
A COPY REPLACING ... BY ==pseudo-text==
fails if the BY and the following == are not on the same line.
[DIAGNOSIS]
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.
[CURE]
Delete all characters from the byte pointer up to, and including, the
initial ==.
********************************************************************************
EDIT 1464 FOR COBOL
[SYMPTOM]
Edit 1450 flags the error messgae at the wrong line.
[DIAGNOSIS]
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.
[CURE]
Edit 1464 to IOGEN to call the correct routine.
********************************************************************************
EDIT 1465 FOR COBOL
[SYMPTOM]
None observed but code is wrong.
[DIAGNOSIS]
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.
[CURE]
Define a word in the phase D storage and use it rather than
KEYRLN.
********************************************************************************
EDIT 1466 FOR COBOL
[SYMPTOM]
Data in a file with a recording mode of STANDARD ASCII will
not be written properly if WRITE statements include either
ADVANCING or POSITIONING clauses.
[DIAGNOSIS]
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.
[CURE]
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
POSITIONING or ADVANCING clause.
********************************************************************************
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
detected.
[C] Resolve ALCPA. within the module DBGETF, where other
DBMS-type memory management calls are resolved for the
compiler.
********************************************************************************
EDIT 1470 FOR COBOL
[SYMPTOM]
If edit 1447 is installed, the module IPCGEN will not
assemble. If edit 1451 is installed, the module RPWGEN will
not assemble.
[DIAGNOSIS]
Edit 1447 failed to declare the routine PUTAYY as external.
Edit 1451 failed to declare the field LMASKR as external.
[CURE]
Edit 1470 to IPCGEN and RPWGEN will declare each field
external.
********************************************************************************
EDIT 1471 FOR COBOL
[SYMPTOM]
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.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
During compilation, the message "? ASSEMBLY ERROR: ***
COMPILER BUG! ***" appears on the terminal.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
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.
[DIAGNOSIS]
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
possible.
[CURE]
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
[SYMPTOM]
Edit 1450 flags an error message for "FREE EVERY RECORD".
[DIAGNOSIS]
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.
[CURE]
Edit 1474 to IOGEN to include "FREE EVERY RECORD" as correct
syntax.
********************************************************************************
EDIT 1475 FOR COBOL
[SYMPTOM]
Register TE is corrupted by edit 1452 to COBOLC.
[DIAGNOSIS]
Edit 1452 was incorporated into COBOLC to remove the FATAL
error message MUST BE A HIGHER LEVEL CONTROL THAN THAT OF
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
unchanged.
[CURE]
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
[SYMPTOM]
A catastrophe in phase E with a bad table link at 502261
after doing an alphabetic/numeric check on a non subscripted
item.
[DIAGNOSIS]
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.
[CURE]
Add a JRST NOTSUB at EXMS9+15 to produce the correct error
message. Remove the other suggested lines of code.
********************************************************************************
EDIT 1477 FOR COBOL
[SYMPTOM]
The result from a COMPUTE statement is incorrect.
[DIAGNOSIS]
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.)
[CURE]
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
[SYMPTOM]
Unexpected results occur when programmers use HIGH or LOW
-VALUES with numeric fields.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
RMS cannot correctly handle files using variable length
alternate keys.
[DIAGNOSIS]
RMS is not intended to handle such keys. The COBOL ANSI
standard does not allow such keys.
[CURE]
Edit 1501 to CLEANC will provide a syntax error on any
alternate key that is variable length.
********************************************************************************
EDIT 1502 FOR COBOL
[SYMPTOM]
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.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
CPYLIB fails with "?CPYREL Premature EOF in library file" if
library contains a multiple of 64 entries.
[DIAGNOSIS]
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.
[CURE]
Edit 4 to CPYLIB to read in the word for end of table.
********************************************************************************
EDIT 5 FOR CPYLIB
[SYMPTOM]
A fatal error occurs at compile-time, stating that a libary
file cannot be found.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
CPYLIB.MAC will not assemble correctly with edit 5
installed.
[DIAGNOSIS]
The bit definition for F%%SEQ cannot be used in a TLXX
instruction.
[CURE]
Use a TXO instruction and let the macro routine figure it
out.
********************************************************************************
EDIT 207 FOR ISAM
[SYMPTOM]
Edit 205 does not type out the correct file error.
[DIAGNOSIS]
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.
[CURE]
Fix the test to do the second complement before typing out
the message.
********************************************************************************
EDIT 210 FOR ISAM
[SYMPTOM]
Edit 204 doesn't work correctly if input and output modes
are mixed.
[DIAGNOSIS]
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.
[CURE]
Edit 210 to ISAM to set the correct input mode.
********************************************************************************
EDIT 211 FOR ISAM
[SYMPTOM]
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.
[DIAGNOSIS]
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.
[CURE]
In the routine which processes the label, before calling the
GETBYT routine, edit 211 will set the bit ONEBYT.
********************************************************************************
EDIT 1065 FOR LIBOL
[SYMPTOM]
FREE with key does not work after a RETAIN NEXT, READ NEXT
on a relative file.
[DIAGNOSIS]
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.
[CURE]
Edit 1065 to CBLIO and LSU to store the key in the Retained
Records table.
********************************************************************************
EDIT 1066 FOR LIBOL
[SYMPTOM]
Recording mode is standard ascii does not produce 8 bit byte
records when using standard labeled tapes.
[DIAGNOSIS]
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 ).
[CURE]
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
[SYMPTOM]
Edit 1065 to module LSU doesn't work correctly.
[DIAGNOSIS]
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.
[CURE]
Edit 1067 to remove edit 1065.
********************************************************************************
EDIT 1070 FOR LIBOL
[SYMPTOM]
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.
[DIAGNOSIS]
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
[SYMPTOM]
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.
[DIAGNOSIS]
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.
[CURE]
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
[SYMTPOM]
Programs which require data to be converted from one-word
floating point to two word comp may execute incorrectly.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
An RMS file that is closed with delete will not be deleted.
[DIAGNOSIS]
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
closed.
[CURE]
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
[SYMPTOM]
If a negative two word comp field is entered through a
terminal, it may be converted incorrectly into computational
format.
[DIAGNOSIS]
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.
[CURE]
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
word.
********************************************************************************
EDIT 1075 FOR LIBOL
[SYMPTOM]
Some records in a multi-level ISAM file may be missed on a
START, READ NEXT sequence.
[DIAGNOSIS]
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.
[CURE]
At SREAD2+4 change POPJ PP, to JRST SETLRW
********************************************************************************
EDIT 1076 FOR LIBOL
[SYMPTOM]
Very large programs will fail in an unpredictable fashion.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
Records within the same data block may be duplicated if a
relative file is accessed dynamically and selected records
rewritten.
[DIAGNOSIS]
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.
[CURE]
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
[SYMPTOM]
When two jobs updating the same relative files using SMU,
sometimes one of the jobs erroneously gets INVALID WRITE
error.
[DIAGNOSIS]
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.
[CURE]
Edit 1100 to CBLIO to force write the buffer out to disk.
********************************************************************************
EDIT 1102 FOR LIBOL
[SYMPTOM]
The fatal error message
RESET TIME COMPT. UUO FAILED
? JSYS ERROR: INVALID SIMULTANEOUS ACCESS
FILE file-name [filename] CANNOT BE OPENED ON DEVICE DSK:
will appear when the second user attempts to open a file for
simultaneous update.
[DIAGNOSIS]
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.
[CURE]
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
determined.
********************************************************************************
EDIT 1103 FOR LIBOL
[SYMPTOM]
Under COBOL-10, the RETAIN statement occasionally causes a Simultaneous
Update program accessing an ISAM file to fail with a Fatal End-of-File
error.
[DIAGNOSIS]
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.
[CURE]
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.
********************************************************************************
END OF COBOL-20-V12B