Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
cbl12b.d06
There is 1 other file named cbl12b.d06 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR COBOL-20-V12B
EDIT 44 FOR COBDDT
[SYMPTOM]
A histogram table produced by some programs will be
incorrect (some paragraph names are omitted and some values
are wrong) whereas similar but smaller programs produce a
correct table.
[DIAGNOSIS]
The histogram table is being overwritten. A TECOing error
was made during v12B development which, when other
conditions are right, will cause this to happen.
The full story is:
When the History Initialize or Begin command is given COBDDT
calculates how much space it needs to hold the histogram
values. It calls GWORDS to allocate this much.
However, GWORDS allocates space on a page boundary. We are
not sure if this is required here but the routine is also
used by overlay code. In any case this causes no problem
except to waste some space. However, it does leave some
space free below the histogram tables. At the end when
COBDDT wants to print the histogram it calculates how much
space is required for two buffers and asks for that space.
If the previous hole is big enough it gets space from it and
all is well. However, if the hole is not big enough it is
given that address anyway and eventually the output buffer
wipes out the histogram data giving the incorrect results
seen.
The reason for this is a TECOing error made during 12B
development. The arg block for the FUNCT. call (HSTFFN
through HSTADR) was originally all EXP 0s. At some point
the first four EXP 0s were changed to BLOCK 1s except that
somehow they ended up as BLOCK 0s. Thus giving the first
five words the same address. The only effect of this was to
replace the size required (406 words) with the function
requested (6). Thus, FUNCT. thought it was allocating 6
words rather that 406 and almost always found space in the
previous hole.
[CURE]
Turn the BLOCK 0s into BLOCK 1s.
********************************************************************************
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 1446 FOR COBOL
[SYMPTOM]
A user-defined currency symbol that is used in place of a
floating dollar sign in a PICTURE definition along with a
minus sign will be overwritten by the minus sign if the
number being displayed is negative.
[DIAGNOSIS]
To use the extended instruction EDIT, a pattern command
string is built by the compiler. This pattern string
dictates how to process the source characters to build the
desired output from the given PICTURE definition and data.
While building this string, a test is made on the float
character, and if it is not a dollar sign, it is assumed to
be a plus or minus sign. This causes an extra routine to be
built on to the end of the pattern string to determine if
the source number is negative, and if so, to insert a minus
sign before the first significant digit. This is causing
the user-defined currency symbol to be overwritten.
[CURE]
Put in an additional test after the dollar sign test to see
if the float character matches the field DOLLR., which
contains any user-defined currency symbol, and on a match,
skip over the routine which generates the leading sign code.
********************************************************************************
EDIT 1447 FOR COBOL
[SYMPTOM]
Program names containing any character other than "A" - "Z",
"a" - "z", or "0" - "9" as the first character will generate
an illegal instruction during compilation.
[DIAGNOSIS]
During code generation, the program name is interpreted as
a UUO call rather than a literal.
[CURE]
When the program name is encountered, skip over the test to
see if it is in the form of a UUO call.
********************************************************************************
EDIT 1450 FOR COBOL
[SYMPTOM]
FREE does not work on key = 0 for dynamic access.
[DIAGNOSIS]
FREE has to be followed by key name or EVERY for COBOL-74, but no
error message is generated by the compiler to show the syntax error.
[CURE]
Edit 1450 to IOGEN and DIAGS to catch this syntax error.
********************************************************************************
EDIT 1451 FOR COBOL
[SYMPTOM]
COBOL generates fatal error message 'MUST BE A HIGHER LEVEL
CONTROL THAN THAT OF THIS GROUP' at random.
[DIAGNOSIS]
To test to see if the RESET control identifier is higher
than that of the group level control identifier, a test is
made to see which of the two control identifier's table
addresses is smaller. If the RPWTAB is expanded between the
time the first address is saved and when the test is made,
then the address saved is invalid to use.
[CURE]
Rather than test the absolute address of the control
identifiers, use the relative address into the RPWTAB.
********************************************************************************
EDIT 1452 FOR COBOL
[SYMPTOM]
COBOL generates fatal error message 'MUST BE A HIGHER LEVEL
CONTROL THAN THAT OF THIS GROUP' at random.
[DIAGNOSIS]
To test to see if the RESET control identifier is higher than
that of the group level control identifier, a test is made to see
which of the two control identifiers table addresses is smaller. If
the RPWTAB is expanded between the time the first address is saved and
when the test is made, then the address saved is invalid to use.
[CURE]
Rather than test the absolute address of the control identifiers,
use the relative address into the RPWTAB.
********************************************************************************
EDIT 1453 FOR COBOL
[SYMPTOM]
Edit 1411 gives a warning messgae for left truncation, but
the source line number is wrong.
[DIAGNOSIS]
The code to get hte source line number is not correct.
[CURE]
Use the same routine that is used in other places in the
compiler. Note edit 1411 must be applied before this edit.
********************************************************************************
EDIT 1454 FOR COBOL
[SYMPTOM]
The 68274 converter when converting the SYMBOLIC KEY clause to a
comment, places the key on the line following the SYMBOLIC KEY clause.
[DIAGNOSIS]
When converting a line to a comment, the converter inserts a CRLF
before the next statement. The module that updates where the next
statement is does not update the pointer if the next statement is a
period. So when the converter inserts a CRLF into the line, it
inserts it before the last word in the statement.
[CURE]
Update the pointer to the start of the next clause if a period is
seen.
********************************************************************************
EDIT 1455 FOR COBOL
[SYMPTOM]
The 68274 converter does not correctly convert the statement
following the NOTE clause if the statement is of the same
line as part of the NOTE clause and if the first word of the
statement is replaced by another word.
[DIAGNOSIS]
The 68274 converter uses two internal buffers to generate
the translated code. When the converter makes a statement a
comment, it must make sure that it is the only statement on
that line. To do this, the converter writes out to the CVT
file the contents of the first buffer. The second buffer is
then copied to the first buffer. The statement that is
being commented out is removed from the second buffer and
replaced by spaces. The statement that is not being
commented out is removed from the first buffer and replaced
by spaces. When this is completed, the converter does not
update the position and state of the current line.
[CURE]
Set the pointer to the current word on the second buffer,
and reset the flag that tells if the statement is to be
commented out.
********************************************************************************
EDIT 1456 FOR COBOL
[SYMPTOM]
If the first term in a COMPUTE statement uses a 'ZERO' as a
factor the next term will be ignored.
[DIAGNOSIS]
The module MATGEN turns on a flag when it determines that a
factor in a multiplication is zero, and does not bother to
generate code to perform the multiplication. If the
processing of the next part of the expression requires a
subexpression be calculated before the zero term is used,
the zero field is moved to a temporary location, but the
flag signifying 'zero in an accumulator' is never turned
off. The next term is also considered to be zero, and if it
also requires a multiplication, it is not performed.
[CURE]
In the module EXPGEN, when it is determined that an
accumulator must be moved to a temporary location, shut off
the flag that signifies 'zero in an accumulator'.
********************************************************************************
EDIT 1457 FOR COBOL
[SYMPTOM]
Very occasionally the usage of the syntax IF SET-NAME SET for DBMS-10/20
Data Manipulation Language will cause garbage to be placed in the Literal
generated for the set-name by the compiler.
[DIAGNOSIS]
The code in IFGEN which creates the Literal calls STASHL to put it into
the Literal Table. With the particular example provided the Literal
Table had to be expanded in the middle of putting the Literal in place.
In the process the VALTAB area which was the source of the text of the Literal
got moved down in core because it is below the Literal Table. However,
the pointer to the address of this area was never updated. So, when the
IFGEN routine went to get the rest of the name it was now pointing
at garbage.
[CURE]
Make sure that the VALTAB pointer gets updated by passing it to the
STASHL routine in the field CURVAL. If the Literal Table has to be
expanded, the XPAND routine will be called and it will update the
pointer. This is done in edit 1457 to the COBOL-10/20 compiler.
********************************************************************************
EDIT 1467 FOR COBOL
[SYMPTOM]
When relinking the COBOL compiler, the undefined global
ALCPA. may be detected.
[DIAGNOSIS]
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.
[CURE]
Resolve ALCPA. within the module DBGETF, where other
DBMS-type memory management calls are resolved for the
compiler.
********************************************************************************
EDIT 1047 FOR LIBOL
[SYMPTOM]
During simultaneous access, if the process that has the lock on a
record encountered a fatal error and was aborted, another process that
has been in ENQ I/O wait for this locked record would hang until the
aborted process is reset.
[DIAGNOSIS]
When the first process encountered the fatal error, it took the abort
route without dequeuing the locked record. Therefore other processes
cannot access this record even though the first process is killed.
[CURE]
Edit 1047 to LSU to do the dequeue before the job is aborted.
********************************************************************************
EDIT 1050 FOR LIBOL
[SYMPTOM]
Accessing a relative file randomly or dynamically will
result in the end-of-file path being taken on the first
empty record encountered.
[DIAGNOSIS]
The last block number field, D.LBN, is not being set for
random files opened for input only. When reading the file,
if an empty record is encountered, a routine is entered to
add one to the count of records processed and to check the
current block number against the last block number in the
file. Since this field has not been set up, end of file is
always set.
[CURE]
The OPEN routine should set the last block number field.
Edit 1050 to CBLIO.MAC will add a call to OPNEL2 which will
use the file size in the extended lookup argument block to
determine the last block number and store it in D.LBN.
********************************************************************************
EDIT 1051 FOR LIBOL
[SYMPTOM]
REWRITE doesn't work after READ NEXT on relative file with dynamic
access.
[DIAGNOSIS]
When LSU tries to get the actual key for comparsion, the wrong
instruction is used and therefore the data from a wrong address is
assumed as the actual key and the comparsion fails. This failure of
comparsion leads to the error message of "record not retained".
[CURE]
Edit 1051 to LSU to get the correct address.
********************************************************************************
EDIT 1052 FOR LIBOL
[SYMPTOM]
When extending a blocked file LIBOL tries to determine if
the last block is completely filled or not. This is being
done incorrectly for SIXBIT files, resulting in one less
record than is possible.
[DIAGNOSIS]
When determining how many additional records can be placed
in the last block of an extended file, LIBOL fills a buffer
with that block. It calculates the number of words used in
the buffer, multiplies it by the number of bytes per word,
yielding the number of bytes used, then divides this result
by the number of bytes per record, expecting to get the
number of records in the last block. The record size used
ignores the header word contained in each record and the
fact that all sixbit records will start at the beginning of
the next word. This means the computation may be off by up
to two words per record.
[CURE]
Since the used portion of the buffer is stated in words and
the file table contains the record size in words, use those
fields to determine the number of records contained in the
last buffer.
********************************************************************************
EDIT 1053 FOR LIBOL
[SYMPTOM]
Trying to open RMS files for I-O while dumper is backing them up gets
error message "?LBL520 File is being modified".
[DIAGNOSIS]
DUMPER has got the files open frozen and RMS could not open the files
for I-O. But DUMPER is not modifying any files.
[CURE]
Edit 1053 to LBLERR to issue a correct error message.
********************************************************************************
EDIT 1054 FOR LIBOL
[SYMPTOM]
When opening an ISAM file for Simultaneous access and the
IDX file is present but not the IDA file and using
Declaratives to trap fatal file I-O errors and setting the
action code to force continued execution of the program, a
fatal program failure is encountered with an "unexpected
return from ENQ/DEQ" and the program execution is terminated
immediately.
[DIAGNOSIS]
When Simultaneous Update is in effect, C.OPEN elects to
ignore the error on the Open of the IDA file. However upon
return to LFENQ., this routine does not even test for a
failed Open and merely passes on in its main line of code to
call its ENQ handler where the program failure finally
occurs. In the case of a failed Open, the Unavailable path
should not be taken. However, the execution should proceed
at the "Next Sentence" in the user's program in the event
that the action code is set to 1.
[CURE]
Make LFENQ. check for an Open failure upon return from
C.OPEN. Install edit 1054 to LSU.MAC and CBLIO.MAC and
rebuild Libol.
********************************************************************************
EDIT 1055 FOR LIBOL
[SYMPTOM]
Reading a SIXBIT file results in the fatal error:
The maximum record size may not be exceeded
File FILE-ID [FILE ID] on device DSK: cannot do INPUT.
[DIAGNOSIS]
When a file is extended, the last physical block is brought
into memory and examined so the buffer pointers and record
counts can be set. In the sample program provided, the
logical block of five records required two physical blocks
to contain it. The physical block count was not being set
correctly if the file ended on a logical block boundary.
When LIBOL determined that the file last ended on a logical
block boundary, it reset the buffer pointers to the
beginning of the buffer and the number of records to be
added to the new buffer, but the physical block count was
not reset to two. This caused an incorrectly formatted
block to be written out to the file. When reading the file
back the fatal error occurred.
[CURE]
At the routine OPNNXX in CBLIO which requests a dummy write
to reset the buffer pointers and also resets the number of
records per logical block, insert edit 1055 to reset the
physical block count.
********************************************************************************
EDIT 1056 FOR LIBOL
[SYMPTOM]
If DBMS has been added to LIBOL/C74LIB, DBMS modules
are loaded even for programs that do not use DBMS.
[DIAGNOSIS]
Each cobol program unit requires a file from the
link-time libraries that produces a link-time request for
symbol DBSTP$. In a library that has DBMS installed, this
request is satisfied by loading the DBMS module that defines
all the entry vectors, and if the OTS is being loaded
non-share, this also causes ALL of DBMS to be loaded.
[CURE]
Replace the request for symbol DBSTP$ with a request
for symbol %DBSTP. Add a new module %DBSTP which defines
%DBSTP==DBSTP$. and make sure that this module gets placed
before the dummy (non-DBMS) DBSTP$ routine in the link-time
library. If DBMS is loaded, make sure that this module, and
the dummy DBSTP$ routine are placed after the actual DBMS
entry module. In this way, if no DBMS entry points are
requested, the %DBSTP request will be satisfied by the dummy
DBSTP$. And if the DBMS entry module has been loaded to
satisfy DBMS DML calls, the %DBSTP request will be satisfied
by the actual DBMS DBSTP$. This edit requires edit 517 to
DBMS, which merely changes the DBMS20.CTL file to take
advantage of this new capability.
********************************************************************************
EDIT 1057 FOR LIBOL
[SYMPTOM]
The patched version of LIBOL sets file status to zero when
error occurs if file is opened for input; and the error
number for lookup error is set to 2 instead of 3 if the file
is not found.
[DIAGNOSIS]
The patched version has edit 1007, which did not set the
file status to 30 to indicate a permanent error occurred, it
also has a wrong value for error number. Edit 1015 tried to
set the error number to the correct value but failed.
[CURE]
Edit 1057 to CBLIO to make the necessary corrections.
********************************************************************************
EDIT 1060 FOR LIBOL
[SYMPTOM]
UNSTRING returns a value of zero into a numeric destination
if the input data field contains leading spaces.
[DIAGNOSIS]
To UNSTRING a data field, the delimiter is first looked for.
After it's found, the source characters preceding the
delimiter are transferred into a temporary hold area equal
in length to the destination field. Padding characters will
be added and then a conversion routine called to convert the
data and put it into the destination field. In the example
provided the source field was alphanumeric and contained a
leading space, the destination field was numeric and greater
than needed. After the delimiter was found, leading zeros
were put into the temporary field followed by the actual
data. A conversion was then performed on the data which
then consisted of leading zeros, a space, and then numeric
characters. The conversion halted when it found the space,
and left the destination field containing the leading zeros
only.
[CURE]
Since the conversion instruction will ignore leading spaces,
but not imbeddened spaces, edit 1060 to NSTRNG will change
the padding character to spaces.
********************************************************************************
EDIT 1061 FOR LIBOL
[SYMPTOM]
LIBOL generates a RECORD SEQUENCE error when reading a magtape
with the RECORDING MODE IS SIXBIT and at monitor level, a TAPE FORMAT
INDUSTRY COMPATABLE.
[DIAGNOSIS]
LIBOL opens a sixbit magtape with the .IOBIN set in the OPEN uuo
call. The OPEN uuo sets the byte size for the magtape to 36 bit bytes
if the hardware characteristics for the magtape drive is CORE-DUMP.
If the hardware mode for the drive is SIXBIT, the file is opened with
a byte size of 6. If the hardware mode is ASCII, the file is opened
with a byte size of 7. In all other cases, the file is opened with a
byte size of 8.
[CURE]
If the device being opened has RECORDING MODE IS SIXBIT, and it
is a magtape, set the hardware mode to be industry compatible core
dump.
********************************************************************************
EDIT 1062 FOR LIBOL
[SYMPTOM]
A program using indexed files halts with a memory protection
violation.
[DIAGNOSIS]
LIBOL compares the blocking factors of an index file as
stated in the file's statistics block and in the user's
program. If the factor in the statistics block is less than
or equal to the factor in the program, it is assumed correct
and used to request core to build a table for storing the
addresses of the records within a data block. If the value
is not correct, not enough core may be reserved which
results in the run-time failure.
[CURE]
Edit 1062 to CBLIO will change the test on blocking factors
to require that the program's factor match the index file's
factor.
********************************************************************************
EDIT 1063 FOR LIBOL
[SYMPTOM]
When doing Simultaneous Update with Relative files, data records are
lost without warning when being added to a file.
[DIAGNOSIS]
The user has failed to use the routine SETEOF to set the file size to
the maximum byte count before subjecting the file to Simultaneous
Updaters. As a result, when either of two updaters extends the file
the other is unable to discover this. So, when the other wishes to
extend the file, he may bury the first user's new records when he does
so.
[CURE]
Install edit 1063 to LIBOL to give a warning message if a Relative file
is being opened for Simultaneous Update and its file size has not been
set to the maximum byte count. A fatal error message is not being given
because it would force other similar executions which do not extend the
file to terminate unnecessarily.
********************************************************************************
EDIT 1064 FOR LIBOL
[SYMPTOM]
When doing Simultaneous Update with Checkpoint, data records may be
lost without warning when being added to a file.
[DIAGNOSIS]
The routine CHKPNT, which does the checkpointing, is executed in LIBOL
after the routine LRDEQX, which releases ENQ locks on file resources.
As a result, a race condition can exist in which two or more users are
doing overlapping accesses to the same shared file.
[CURE]
Install edit 1064 to LIBOL to eliminate this race condition in the
several places where it can exist by moving the calls to LRDEQX.
********************************************************************************
END OF COBOL-20-V12B