Trailing-Edge
-
PDP-10 Archives
-
BB-L014E-BM
-
autopatch/cbl12b.d05
There are 2 other files named cbl12b.d05 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR COBOL-20-V12B
EDIT 43 FOR COBDDT
[SYMPTOM]
When a DISPLAY command such as "DISPLAY DATA-NAME-1 OF
TABLE-NAME-2" is issued, and TABLE-NAME-2 is redefining
another table, COBDDT does not find the desired field and
issues an error message "?Not uniquely defined, use more
qualification".
[DIAGNOSIS]
While searching through the DATA table structure, verifying
that a qualified item has been sufficiently described, items
are traced back through the group-names that can define
them. Since a table which is being redefined points to its
second definition, this search continues, looking for
possible qualifiers in the second table. It will appear
that a data field defined in the first table can also be
qualified using the second table name even though it is not
declared within it. Since the second table name is now seen
as qualifying its own members and the previous table's
members, it no longer is a sufficiently unique identifier.
[CURE]
When tracing back through the table structure for an item's
complete qualification, a link to an item that has the same
level number should not be considered a link to a possible
qualifier, but just used as a link in a chain back to a
prior group-name.
********************************************************************************
EDIT 1336 FOR COBOL
[SYMPTOM]
For moves that are not group to group or elementary to elementary
and use fields with USAGE of either INDEX or COMP-3, incorrect data is
being moved.
[DIAGNOSIS]
When readjusting the modes for a group move, the table indexes
for INDEX and COMP-3 fields are not being converted. The table used
in MOVGEN for usage modes has different values associated with the
modes than the DATAB, therefore the values must be adjusted. INDEX
fields should be converted to have the same table index as COMP
fields. COMP-3 fields are changed to use the slot that would have
been associated with INDEX fields.
[CURE]
Edit 1336 to MOVGEN will adjust the values for the table indexes
for the INDEX and COMP-3 fields.
********************************************************************************
EDIT 1337 FOR COBOL
[SYMPTON]
MOVE literal to EDITED-DATA-FIELD will be syntaxed as "BAD
USAGE - COMPILER ERROR".
[DIAGNOSIS]
The receiving field has an internal length of one. Rather
than store a LITERAL, the mode of the A operand is changed
to a 14 to represent immediate mode, and the MXX. routine
called to generate a half move immediate. This routine
tests on the modes of the operands and finds this value
invalid, so a compiler error is cited and this code
bypassed.
[CURE]
Rather than jump back through MXX., set up the rest of the
parameters and call GMOV.I directly to build the HRRZI
statement to generate the single character literal. Edit
1337 to MOVGEN will accomplish this.
********************************************************************************
EDIT 1340 FOR COBOL
[SYMPTON]
No warnings are given to indicate possible differences in
the handling of VALUES assigned to fields with a JUSTIFIED
clause or the use of NOT in statements with abbreviated
combined relation conditions.
[DIAGNOSIS]
Print a warning after any such statement.
[CURE]
Edit 1340 will create two new warning messages and initiate
their occurrence in the output listing file.
********************************************************************************
EDIT 1341 FOR COBOL
[SYMPTON]
The same source line will be given two truncation warnings
for the same data item.
[DIAGNOSIS]
Receiving fields of internal length one were being tested
twice for truncation.
[CURE]
Test on the mode of the "A" operand and if it is immediate
mode, bypass the second test for truncation.
********************************************************************************
EDIT 1342 FOR COBOL
[SYMPTOM]
When two debug lines are together and the first ends with a
literal and no period, a fatal error, "improper continuation
character", is returned.
[DIAGNOSIS]
When a literal is the last item on a line and there is no period,
the next line is scanned. If the next line contains a "d" for
debugging and the debug switch is on, the compiler flags a fatal
error. The compiler in its checks for legal continuation characters
in column 7 does not check for the "d" in all instances.
[CURE]
Check for a "d" in column 7 in addition to a space or hyphen.
This is done by Edit 1342 to GETITM.
********************************************************************************
EDIT 1343 FOR COBOL
[SYMPTON]
The output file from the 68274 Converter has no change made
to a NOTE statement.
[DIAGNOSIS]
No provision for handling NOTEs is built into the converter.
[CURE]
Edit 1343 will insert the necessary code into phase D for
handling these statements.
********************************************************************************
EDIT 1344 FOR COBOL
[SYMPTOM]
The compiler generates bad code for a literal compare.
[DIAGNOSIS]
When entering a preliminary routine before expanding the literal
table, the pointer into the value table could be either relative or
absolute depending on which routines were executed previously. The
compiler was setting up relative offset assuming it always had an
absolute pointer. Therefore, it generated an incorrect pointer to the
literal when returning from the expansion routine. In turn, this
caused the wrong literal to be generated in the code.
[CURE]
Check the pointer to see if it contains an absolute or relative
value and proceed accordingly. This is done by Edit 1344.
********************************************************************************
EDIT 1345 FOR COBOL
[SYMPTON]
Compiler execution halts with:
"? Illegal UUO t user PC XXXXXX"
[DIAGNOSIS]
Illegal UUO trap handling has not been implemented.
[CURE]
Edit 1345 will set up .JBINT with the address of an argument
block for handling such failures, which will result in a
call to the routine for handling illegal LUUO's.
********************************************************************************
EDIT 1346 FOR COBOL
[SYMPTON]
Incorrect program execution or program failure should occur
due to a PUSHJ to an incorrect address.
[DIAGNOSIS]
If a variable length table has a size depending on a field
which is not COMP, a routine is generated to convert the
field to a COMP value. This routine is assigned a tag
during a call to GETTAG which is stored in the data table
entry DA.DCR. This location can hold a 9 bit value or up to
512. A value that is any larger is truncated and used as
the label of the conversion routine. Any uses of the table
will generate a PUSHJ to this label so that size of the
table can be checked against the maximum limit.
[CURE]
Edit 1346 will increase the size of the location to store
the conversion routine label. This also means decreasing
the size of the field which contains the number of ascending
or descending keys declared for a table. This field will
hold up to 255 keys. If either of these fields is exceeded,
a fatal error will be generated.
********************************************************************************
EDIT 1347 FOR COBOL
[SYMPTOM]
Edit 1312 caused fields with a picture clause such as,
02 EDIT-ITEM PIC -,999,999.99.
to be flagged with the warning message "No room for significant
digit before first comma".
[DIAGNOSIS]
Edit 1312 checked for any picture string which had a + or -
symbol followed by a comma, whether the string used floating symbols
or not. In order to pass the FCTC test, a picture string that does
not use a floating symbol should not be flagged with a warning about
room for a significant digit.
[CURE]
Do not flag non-floating symbol strings with a warning. This is
done by edit 1347 to PSCAN.
********************************************************************************
EDIT 1350 FOR COBOL
[SYMPTOM]
The 68274 converter is not flagging the use of a signed
numeric literal in a STOP statement as being illegal in the
converted source file.
[DIAGNOSIS]
No converter code was implemented to detect this difference
between ANSI 68 and ANSI 74.
[CURE]
Edit 1350 will alter the syntax tree for the converter to
detect the use of a signed literal and will give a warning
message.
********************************************************************************
EDIT 1351 FOR COBOL
[SYMPTON]
Compile fails with error message:
Bad table-link at 999999
?CBLBUG Catastrophe in Phase E, dump being taken
[DIAGNOSIS]
While generating code for a READ .. INTO statement, the
LITERAL table was expanded. This caused the HLDTAB table to
be moved as well. Since the operands for the MOVE of the
record data were in HLDTAB, their pointers were now wrong.
The MOVGN. routine tried to use the old pointers and
resulted in a bad table link, which aborts the compile.
[CURE]
Before calling the MOVGN. routine, move the required
operands to a fixed area.
********************************************************************************
EDIT 1352 FOR COBOL
[SYMPTOM]
Incorrect results occur in COMPUTE statements containg
subtractions.
[DIAGNOSIS]
In the module EXPGEN at the routine CSUB, the mode of the
"A" operand is not being tested for two word floating point.
One work is assumed.
[CURE]
Insert an additional test on the mode of the "A" operand.
********************************************************************************
EDIT 1353 FOR COBOL
[SYMPTOM]
The compiler halts in phase E with the message on TOPS10:
?HALT at user PC 999999
or on TOPS20:
?PA1050: illegal instruction 254200,,0 (HALT) at user 999999
[DIAGNOSIS]
An invalid level number in the DATA DIVISION caused the
level number on the following statement to be changed to 01.
The size of the field became the record size and not the
field size. While generating code to compare this field
with a literal, the LITD. routine of MOVGEN was called to
build a literal equal in size to the data field and store it
in the literal table. Since the size of the literal was
greater than 4096 words, so the STASHP routine of CMNGEN
halted rather than try to store it.
[CURE]
Edit 1353 will replace the HALT in CMNGEN with a call to an
error routine to provide a diagnostic message and set an
error flag so code generation will not be attempted.
********************************************************************************
EDIT 1354 FOR COBOL
[SYMPTOM]
Program execution halts with the error message:
?$FIND FAILED
?Unexpected RMS error, STS= 300065, STV= 0
?LBL500 RMS-SYSTEM failure
LIBOL error number: 09.00.00.0.500
File: FILENAME: DEV:FILE.EXT
[DIAGNOSIS]
Several alternate keys were defined, some with the same
starting offset within the record format. A START verb was
used which specified one of these alternate key fields.
While trying to match that data field with an entry in the
alternate key table, the only criterion used was a match on
the word and bit location within the record. The first key
that matched the offsets of the field in the START statement
was selected as the alternate key. Since this key turned
out to be shorter than the field in the START statement, the
argument block set up by the compiler was in error. When
this argument block was passed to RMS, it objected.
[CURE]
Edit 1354 to COBOLD will store the size of the data field
used in the START statement and compare it against the
selected key field. If it is greater than the key size, the
search for the key will continue to the next alternate key.
********************************************************************************
EDIT 1355 FOR COBOL
[SYMPTON]
Moving zero to a COMP-3 field will result in incorrect data
being stored in the receiving field. When displayed on a
terminal, the results will appear to be 2000000, instead of
0.
[DIAGNOSIS]
Edit 1307 to CMNGEN changed the routine which stored the
value of zero in the literal table to allow for signed and
unsigned values. The change in code deleted a statement
which would have zeroed an accumulator required to build the
literal.
[CURE]
Edit 1355 will zero accumulator 10, allowing the literal to
be built properly.
********************************************************************************
EDIT 1356 FOR COBOL
[SYMPTOM]
Using qualification for a record name in the DATA RECORD ARE
clause causes the fatal error message "IMPROPER CLAUSE" to be issued.
[DIAGNOSIS]
In CTREE, after the compiler checks the record name used in the
DATA RECORDS ARE clause, the acceptable nodes that control can pass to
does not include a check for an OF or IN phrase. This omittence
causes the use of qualification to fail.
[CURE]
Inclusion of the node to allow an OF or IN phrase requires making
checks to ensure a valid filename follows. If a filename has not been
stated, control should pass to an additional node which will cause an
error meesage to be issued. If a filename has been stated control
will pass to another new node. This node causes execution of a COBOLC
routine which compares the stated filename to the current filename,
thus certifying the record name is properly qualified.
Edit 1356 to CTREE supplies the three new nodes and the changes
needed in the current nodes to allow qualification in the DATA RECORDS
ARE clause. The portion of Edit 1356 applied to COBOLC checks the
file name ensuring correct qualification of the record name.
********************************************************************************
EDIT 1357 FOR COBOL
[SYMPTOM]
A word to be replaced sometimes causes a HALT. For example:
PARA-1
EXAMINE...
[DIAGNOSIS]
The code to decide which line the work is on gets confused and
searches the previous line. When the required word is not found a
HALT is given.
[CURE]
Add a line counter so that the line is known and doesn't have to be
guesses from the byte pointers.
********************************************************************************
EDIT 1360 FOR COBOL
[SYMPTOM]
Conver of a file with COPY REPLACING doesn't work.
[DIAGNOSIS]
No code to do it, so the characters get into the CVT file twice.
[CURE]
Test for this case and only enter them once. Note: Both the LST file
and the CVT contain the source after replacement has taken place.
********************************************************************************
EDIT 1361 FOR COBOL
[SYMPTOM]
68274 dies with I/O to unassigned channel if a CVT is not requested.
[DIAGNOSIS]
The CVT buffer is not set up but I/O is done anyway.
[CURE]
Test for this case and don't do any output. We decided to do this
rather than give an error since a list file will show reserved words
and things that 68274 could not convert. This is a better listing
than just putting the CBL through a syntax pass to the COBOL compiler,
since things that the converter can handle will not give errors.
********************************************************************************
EDIT 1362 FOR COBOL
[SYMPTON]
A build of the COBOL compiler will fail with undefined
global symbol HLDSAV if edit 1335 is installed and the MCS
or TCS switches are off.
[DIAGNOSIS]
Edit 1335 uses the field HLDSAV which is declared only if
MCS or TCS is on.
[CURE]
Edit 1362 will move the definition of HLDSAV to outside the
conditional code.
********************************************************************************
EDIT 1363 FOR COBOL
[SYMPTON]
The compiler error message:
?nn ASSEMBLY ERRORS: *** COMPILER BUG! ***
results in programs defining both collating sequences and
CHANNEL numbers.
[DIAGNOSIS]
In scanning through the mnemonic table searching for
collating sequences, an incorrect number of words was jumped
over if the entry found was a CHANNEL number entry. If the
CHANNEL number entry was defined after the alphabet, there
was no problem. If it preceded the alphabet, when the
search through the table was continued, it was always one
word off in looking for entry header words.
[CURE]
The size of a CHANNEL number entry in the mnemonic table is
two words, whereas the alphabet entries are three or more
words depending on whether or not they are standard
sequences or user-defined. Edit 1363 will adjust the scan
through the mnemonic table to take this into consideration.
********************************************************************************
EDIT 1364 FOR COBOL
[SYMPTON]
UNSTRING results in incorrect data in the destination fields
if the source is an edited field and the delimiter is a
literal or figurative constant.
[DIAGNOSIS]
The compiler is setting the size of the delimiter equal to
the size of the source field, making matches on the
delimiter always false unless the entire field matches the
delimiter.
[CURE]
The routine which builds the argument block consisting of a
byte pointer and a character count is used by multiple
routines. When handling source fields, it is supposed to
set the character count to the external size of the data
field if it is edited. When called for the purpose of
building an argument block for delimiters, this adjustment
should be bypassed.
********************************************************************************
EDIT 1365 FOR COBOL
[SYMPTON]
Source characters were not received by the destination
field.
[DIAGNOSIS]
The source field was defined as a numeric edited item with
an occurs clause. When the definition of the sending field
was set up, the internal size of the source was used, not
the external size which includes character positions for the
editing characters.
[CURE]
Edit 1365 to STRGEN will put in a test on the source to see
if it is edited and use the external size of the field if it
is.
********************************************************************************
EDIT 1366 FOR COBOL
[SYMPTON]
A program using REPORT WRITER may fail with a catastrophe in
phase C.
[DIAGNOSIS]
Edit 1335 has a typographical error in it. A MOVE statement
should be a MOVEM.
[CURE]
Edit 1366 to COBOLC corrects the statement.
********************************************************************************
EDIT 1367 FOR COBOL
[SYMPTOM] Changing a NOTE to a comment in the 68274 converter causes a
line following a NOTE to be ignored.
[DIAGNOSIS] After converting a NOTE line to a comment, the control of
the compiler is not passed backed, and instead the compiler flows
through extra code.
[CURE] After converting the NOTE paragraph to comments, return to the
calling segment of the compiler.
********************************************************************************
EDIT 1370 FOR COBOL
[SYMPTON]
Program will appear to compile correctly, but will fail at
execution time with various OPEN failure messages from LIBOL
or RMS, or, may fail to compile due to catastrophes in phase
E.
[DIAGNOSIS]
The descriptors for the alternate keys are built by IOGEN in
phase E. If this process is interrupted to expand tables,
the value in CURAKT is assumed to be an absolute address and
is adjusted to account for the expansion. Since the value
was not absolute, it becomes corrupted and no longer points
to a valid address.
[CURE]
Change CURAKT to an absolute address so it can be adjusted
properly when the tables are expanded.
********************************************************************************
EDIT 1371 FOR COBOL
[SYMPTOM]
If a truncation warning occurs when moving data from the linkage
section to the working-storage section, the sending field's name is
specified rather than the receiving field's name. This same error
occurs when moving subscripted data to another data name.
[DIAGNOSIS]
When a linkage section field or a subscripted field is being
processed, either the FASUB or FBSUB flag is set on. This flag is
checked when a MOVE is being generated. If the flag is on some
additional steps are taken which include resetting CUREOP. The flag
is checked for both the sending field and the receiving field. If
only the sending field requires the additional processing, CUREOP does
not get reset to point to the receiving field before the truncation
warning is generated. As a result, since the warning routine uses the
contents of CUREOP to determine the recieving fields data name, the
wrong name is displayed.
[CURE]
Before issuing a truncation error, reset CUREOP so that it points
to the receiving field. Edit 1371 to MOVGEN accomplishes this.
********************************************************************************
EDIT 1372 FOR COBOL
[SYMPTOM]
When using the COPY statement in a COBOL program with the REPLACING
clause, if the leading == are not placed following the BY, the ompiler
terminates execution with the message:
?Not enough memory to continue compilation
[DIAGNOSIS]
Without the leading ==, the compiler assumes it is getting an
identifier or a data-name instead of pseudo-text for replacing. When
it encounters the ending ==, it thinks this is the start of another
replacing clause for pseudo-text and start to read until it sees
another ==, which does not exist. It keeps reading until it runs out
of memory.
[CURE]
Edit 1372 to getitm to test for the end-of-file so the compiler will
only looks for the == until the end of the program and then flags an
error message.
********************************************************************************
EDIT 1373 FOR COBOL
[SYMPTOM]
When a program has more than one report heading line and no
CONTROL clause for a report, the page is advanced between the printing
of the report heading lines and the page heading lines.
[DIAGNOSIS]
The compiler generates code at the beginning of the page-heading
routine which causes the page to be advanced before the page headings
are printed. The code generated includes incrementing the
page-counter, moving a value to the line-counter accumulator, moving
the address of the report writer table to an accumulator and calling
LINE.H. The value moved to the line-counter accumulator is either the
value stated in the HEADING cluse or a default value of 1. In either
case, the value signifies the top-of-page for the report. When LINE.H
is called, it compares the value in the line-counter accumulator with
the current line. If the current line is greater than the accumulator
value a page advance occurs, otherwise processing of the page-heading
routine continues. As a result, the page is advanced before printing
the page headers which is correct except on the first page when report
headings may have been printed. When there is one report header line,
the top-of-page and the current line number are equal so no page
advancing occurs. However, when two or more report heading lines have
been printed, the current line is greater than the value in the
line-counter accumulator and the page is erroneously advanced. This
problem does not occur when the CONTROL clause is used because the
CONTROL clause eliminates the call to LINE.H.
[CURE]
Add a flag to the report writer table in TABLES. This flag is
switched on in COBOLC when the compiler sees a TYPE IS REPORT HEADING
clause. The flag is then checked in RPWGEN when the page-heading
routine is generated. If the flag is on, additional code will be
generated which tests for the first time though the page-heading
routine and accounts for all possible report header lines. These
steps are accomplished with Edit 1373 to TABLES, COBOLC and RPWGEN.
********************************************************************************
EDIT 1374 FOR COBOL
[SYMPTON]
Any data field compared to high-values will be considered
greater than high-values if a collating sequence of EBCDIC
is being used.
[DIAGNOSIS]
When generating the proper high-value field to use in a
comparison, the IFGEN module is using the mode of the data
field involved in the comparison, and is not considering
whether another collating sequence has been declared. Since
in this case the data field is sixbit, the high-value
character used is a sixbit value. The comparison routine is
converting each character in the data field involved to the
EBCDIC equivalent, but is then testing against the sixbit
value for high-values.
[CURE]
The IFHIV routine of IFGEN is generating the value for
high-values. Edit 1374 will put in a test on the collating
sequence and adjust the data mode if necessary.
********************************************************************************
EDIT 1375 FOR COBOL
[SYMPTOM]
Read statement generates fatal error "ID DIVISION Must be
subscripted" when using variable length records. This problem occurs
only when the data name with the depending clause is defined more than
once.
[DIAGNOSIS]
When a read statement is encountered, COBOL looks to see
if any part of the record being read is variable length. If it is
variable length, the compiler generates a move of the length of the
item read to the depending item in the WORKING-STORAGE SECTION.
When generating the code to do the move, the compiler searches
for the data item with the depending clause. To search for the item,
COBOL looks at the link to the depending item to see if it is not
zero. The table entries for each data item are variable length, with
some not containing the link to the depending item. If the depending
link is not defined, when it is loaded it will load in the link to the
data name with the same name rather than the link to the depending
item.
[CURE]
When searching for the data item with the depending clause,
first look to see if the depending item link is defined for that data
entry.
********************************************************************************
EDIT 1376 FOR COBOL
[SYMPTOM]
If line preceding FD clause is too long, the FD clause gets thrown out
as an improper clause without diagnostic reporting "Period assumed".
[DIAGNOSIS]
When the line is too long, there is no test to see if the following is
a FD clause so that the diagnostic message for "Period assumed" can be
given for the previous line. Therefore the compiler assumes the
following clause is invalid.
[CURE]
Edit 1376 to COBOLC to test for the FD clause.
********************************************************************************
EDIT 1377 FOR COBOL
[SYMPTOM]
COBOL does not always generate a warning for truncation in COMPUTE
statements.
[DIAGNOSIS]
After COBOL finishes a floating point divide and converts the result
back to fixed point, the size of the destination is clobbered during
the process. Therefore the size of the destination is no longer
correct when it is used later on to check for truncation.
[CURE]
Edit 1377 to check for truncation before the conversion to
fixed-point.
********************************************************************************
EDIT 1400 FOR COBOL
[SYMPTOM]
When a USE statement with the LABEL PROCEDURE format specifies
two or more file names in the same statement a fatal diagnostic is
issued. The same error occurs when two sections use the same
statement except the file names are different.
Also, if the USE statement does not contain a BEGINNING or
ENDING, the designated procedures are not executed for both the
beginning and ending labels. Similarly, if the USE statement does not
contain the words REEL, FILE or UNIT, the designated procedures are
not executed for both REEL or UNIT labels and for FILE labels.
[DIAGNOSIS]
When the USE statement is compiled, certain bits are set on in
the OPRTR word to signify which options have been chosen. Some of the
bits have several meanings. For example, bit 14 is turned on when the
procedure is to be executed for the UNIT or REEL. Bit 14 also
designates EXTEND was used. Similarly, bit 15 designates either that
the procedure is to be executed for FILE labels or the 'file name
OPEN' option was specified. When a test is made to decide whether a
general use procedure or a file specific use procedure is to be set
up, bit 14 is checked. However, bit 14 can be on in either case,
thus, if a file name is specified, control passes to the wrong
routine, i.e., the routine for the general use procedure. The error
occurs when this routine is entered a second time upon encountering a
second file name. The routine checks to see if a section has been
stored in the USE table for a USE statement with the same format. An
error message will be issued if the location in the table for a
specified format already has an entry. Since the compiler is not
recognizing the specific file names, it considers that an identical
format has been used and an error is issued.
The second problem arises in the routine that should be executed
for a USE statement using a specific file name. This routine is
checking to see which bits in OPRTR were set, i.e., ENDING, BEGINNING,
BEFORE, AFTER, REEL or FILE. The routine builds an offset into a
table depending on the settings. Each half word in the table
corresponds to one of the possible cases for when the designated
procedures are to be executed, for example, before beginning reel or
after ending file. Since the routine is building the offset by adding
to it depending on whether a bit is set, only the last applicable case
is being set up. As a result the designated procedures will only be
executed for one case rather than all requested or implied cases.
[CURE]
Set up a bit in the OPRTR word which will designate that a
specific file name is being used. The bit will be turned on when a
file name is encountered in a USE statement. The bit will be tested
to decide whether control is to pass to the general USE procedure
routine or the file specific USE procedure routine.
In the file specific USE procedure routine, test for all possible
cases of when a procedure should be executed. After determining that
a case applies, execute the code for storing the pointer to the
procedure then test for the next case until all applicable table
locations for a file have been set up.
Edit 1400 to COBOLD, DTREE and PURE make these changes.
********************************************************************************
EDIT 1401 FOR COBOL
[SYMPTOM]
Statements following EXIT statement not generating error message in
COBOL-74.
[DIAGNOSIS]
After an EXIT statement has been detected no check is being made to
see that the remaining part of the paragraph contains no statements.
[CURE]
After detecting an EXIT statement, check to see that the remainder of
the COBOL paragraph contains no statements.
********************************************************************************
EDIT 1402 FOR COBOL
[SYMPTOM]
Evaluating an expression may generate a different result
than COMPUTing an expression with the same operands. For
example, "If (A - B)/A = " may generate a different value
than "COMPUTE C = (A - B)/A".
[DIAGNOSIS]
Since the first statement has no result field, there is no
way of knowing how many decimal places to maintain, so the
definitions of the operands are used to determine this. In
the second example, the destination field is inspected to
determine the required accuracy. This leads to different
results.
[CURE]
To assure these two expressions yield the same results, the
division should be done in floating point and the same
degree of accuracy maintained in each case.
********************************************************************************
EDIT 1404 FOR COBOL
[SYMPTOM]
Spurious "Non-sixbit character in VALUE of DISPLAY-6 item".
[DIAGNOSIS]
When generating code for IF statements with the second item being
a literal, a swap of the literal and the data item being compared is
done. This swaping may expand the size of the LITTAB table, changing
the location where the literal is for the IF statement.
[CURE]
After swapping the literal and the data item to be compared,
update the byte pointer to the literal.
********************************************************************************
EDIT 1405 FOR COBOL
[SYMPTOM]
COBOL does not give syntax error if the period after the NEXT SENTENCE
statement following ELSE is missing.
[DIAGNOSIS]
In the syntax tree for the procedure division, the default path for
the NEXT SENTENCE statement does not go to the error routine when the
period is not found.
[CURE]
Edit 1405 to set the correct default path in DTREE for the NEXT
SENTENCE statement.
********************************************************************************
EDIT 1406 FOR COBOL
[SYMPTOM]
COPY REPLACING statements which are continued in the A margin
generate error messages.
[DIAGNOSIS]
When comparing the character in the source code to an equal sign,
no check is made to see if the an equal sign in the A margin.
[CURE]
Make the check to see if the source character is an equal sign,
include a check to see if it is an equal sign in the A margin.
********************************************************************************
EDIT 1407 FOR COBOL
[SYMPTOM]
COPY REPLACING in ID DIVISION does not delete fields being
replaced.
[DIAGNOSIS]
When coping the PROGRAM-ID statement from a library file, no test
is made to determine if the first word is part of the statement to be
changed with the replacing statement. The statement is then read
again and is exchanged with the replacing statement.
[CURE]
After reading in the program name, check to see if the
replacement test swich is on. If the switch is on, do not output the
next characters to the listing file, and get the next word rather than
skipping over the next paragraph.
********************************************************************************
EDIT 1410 FOR COBOL
[SYMPTOM]
MOVE SPACES to item in LINKAGE SECTION generates illegal memory
reference in phase G.
[DIAGNOSIS]
When generating the code to move spaces to a data item, the
compiler generates a loop starting at zero to the number of
characters, and moves spaces to to each character one at a time. The
code generated to move the table size into an AC was causing phase G
to generate an illegal memory referance if the table size was greater
than 100000 characters. Phase G of the compiler reads in the size of
the table and masks out the first three bits of the size. If the
three bits are zero, than the size is treated as a constant, and if
any are set, the size is treated as a location of where the size
parameter is located.
[CURE]
If the table size is greater than 100000, place the size of the
table in a location, and place the address of the size in second
parameter.
********************************************************************************
EDIT 1411 FOR COBOL
[SYMPTON]
No truncation warning will be printed for COMPUTE statements
that specify ROUNDED, or the result of the COMPUTE will be
shifted left one decimal place.
[DIAGNOSIS]
If the intermediary result in a computation has been
converted to floating point, the rounding routine will
convert it back to an integer and change the operand size
and number of decimal places to match the destination field.
The data needed to determine if there is any leading digit
truncation is lost, so no warning message is triggered
later. Edit 1403 tested for truncation earlier, but failed
to note that one digit was added for rounding.
[CURE]
Remove edit 1403 if it is installed. Install edit 1411 to
CMNGEN to test for truncation in the rounding routine before
converting the floating point number to integer.
********************************************************************************
EDIT 1412 FOR COBOL
[SYMPTOM]
Sequentail READ does not work when an ISAM file is accessed
sequentially under simultaneous update.
[DIAGNOSIS]
Without specified key, the key field is initialized with nulls. The
RETAIN finds the first valid key and retains it while the null value
is still in the key field. When simultaneous update compares the key
that was just retained and the key it is going to READ, they are
different and an error is generated.
[CURE]
Edit 1412 to COBOLD and IOGEN to make RETAIN and READ get the same
key.
********************************************************************************
EDIT 1413 FOR COBOL
[SYMPTOM]
When using the 68274 conversion utility, conversion of the INVOKE
causes the DBMS statements in the schema file to be added to the CVT
file as well as leaving in the INVOKE statement.
[DIAGNOSIS]
When the INVOKE statement is seen, the converter copies in the
statements in the schema file and processes them. When processing of
each statement is completed, it is copied to the CVT file.
[CURE]
Test to see if the statements are being generated by from the
DBMS schema file. If the are, do not copy the statement to the CVT
file.
********************************************************************************
EDIT 1414 FOR COBOL
[SYMPTOM]
DBMS USE procedures in the declaratives section of a
COBOL subprogram are always ignored.
[DIAGNOSIS]
While the COBOL compiler always builds the USE
procedure list, it never generates the code to call the
routine (INITDB) which sets up the address for the BIND
code, if the program unit being compiled is a subprogram.
While this does conform to the documentation in the DBMS-20
DML Reference Manual, it is unnecessarily restrictive.
[CURE]
Generate the call to INITDB in the code for the main
entry point (default entry if non specified) for all program
units that contain an INVOKE verb.
********************************************************************************
EDIT 1415 FOR COBOL
[SYMPTOM]
INSPECT statement in COBOL-74 is not the same as the EXAMINE
statement in COBOL-68, although when using the converter the
differences between these statements are ignored.
[DIAGNOSIS]
The EXAMINE verb in COBOL-68 counts the number of occurrences of
a givin character in a data item and places this count into TALLY.
The INSPECT verb in COBOL-74 counts the number of occurrences of a
givin character in a data item and adds this count to TALLY. The
converter ignores the difference that the INSPECT verb adds to TALLY,
where the EXAMINE replaces TALLY.
[CURE]
Before converting EXAMINE to INSPECT, generate a line to
initialize TALLY.
********************************************************************************
EDIT 1416 FOR COBOL
[SYMPTOM]
Comparison of numeric item with a non-numeric literal is handled
differently in COBOL-74 then in COBOL-68. The 68274 converter does
not issue a warning when this difference is seen.
[DIAGNOSIS]
In the conversion of the IF statement no test is made to see if
the size of the operand is different than the size of the operator.
[CURE]
When converting the IF statement, make a test to see if the sizes
of the operand and operator are the same, and if they are not generate
a warning message.
********************************************************************************
EDIT 1417 FOR COBOL
[SYMPTOM]
The 68274 conver does not convert the WRITE statement to WRITE
BEFORE ADVANCING 1 LINE.
[DIAGNOSIS]
Before a WRITE statement is converted to WRITE BEFORE ADVANCING,
a test is made to see if the access mode of the file to be written to
is sequential. If no access method is specified in the SELECT
statement, the default mode is assumed to be sequential. If a file
has no access specified, its default value is set after the PROCEDURE
DIVISION.
[CURE]
Setup the default access mode after the DATA DIVISION.
********************************************************************************
EDIT 1420 FOR COBOL
[SYMPTOM]
Sorting EBCDIC fields does not work correctly.
[DIAGNOSIS]
When COBOL generates code to sort, it has to generate code
executed by the SORT utility to load in the key of the current record.
On EBCDIC sorts with a two character offset, code is generated to load
in the first part of the key, then to load in the second half of the
key. Rather then loading in the second half of the key, a compare is
generated. The compare is generated because phase E of the compiler
generates code from the first internal table of op-codes rather than
the second.
[CURE]
Before moving the op-code in to be generated, call PUTASA which
will tell phase E of the compiler to generate the code using the
second table of op-codes rather than the first.
********************************************************************************
EDIT 1421 FOR COBOL
[SYMPTOM]
Moving a signed numeric data-item to a right justified alphanumeric
data-item results in the right most digits being truncated when the
receiving field is smaller than the sending field.
[DIAGNOSIS]
When the sending field is copied into the receiving field, the mode of
the sending field is also copied into the receiving field's mode and
overwrites the bit for justified-right. Therefore it is doing a
standard alignment instead of right justification and truncates the
right most digits instead of the left most digits.
[CURE]
Edit 1421 to MOVGEN to re-establish the mode of the receiving field
before the move.
********************************************************************************
EDIT 1422 FOR COBOL
[SYMPTOM]
The 68274 converter adds an extra * after the DATE-COMPILED
statement.
[DIAGNOSIS]
The 68274 converter when it see the DATE-COMPILED statement,
ignores copying the rest of the statement including the cariage return
and line feed to the CVT file. The remaining statements are then
converted to comments, with the first line following the DATE-COMPILED
statement replacing the comments on the same line as the DATE-COMPILED
statement.
[CURE]
While skipping over the data after the DATE-COMPILED statement,
copy the data to the CVT file.
********************************************************************************
EDIT 1423 FOR COBOL
[SYMPTOM]
The 68274 converter does not convert the FILE LIMITS into a
comment.
[DIAGNOSIS]
When converting the FILE LIMITS statement into a comment, the
line is split into two lines. When the word FILE is found, no action
takes place to comment that line. Rather, when the word LIMITS is
seen, it then attemts to comment out the line. When converting lines
to comments, a pointer is set to the current word being processed, and
if there are any other words on the same line, the current word is
placed on a new line and then converted into a comment.
[CURE]
Convert the line into a comment when the word FILE is found and
if the next word begins with "L".
********************************************************************************
EDIT 1424 FOR COBOL
[SYMPTOM]
Numeric data read from an ASCII file may be incorrect.
[DIAGNOSIS]
Data declared with a usage of COMPUTATIONAL, INDEX, or
COMP-1 is stored in 36 bits in binary form. If this field
is in an ASCII record and is written out to disk, it will be
tranferred to the buffer in 7-bit bytes. The last bit will
be ignored. When the file is read back, it is corrupted.
[CURE]
Edit 1424 will give a fatal syntax error on any field
declared as with a usage other than DISPLAY in an ASCII
record.
********************************************************************************
EDIT 1425 FOR COBOL
[SYMPTOM]
The 68274 converter converts RESERVE negative number AREAS to
RESERVE / AREAS.
[DIAGNOSIS]
When converting the RESERVE statement, the converter adds two to
the number of areas allocated. No test is made to see if the number
is less than one after the addition takes place.
[CURE]
If the number of areas for the RESERVE statement is less than one
after the adding of two, set the number to one.
********************************************************************************
EDIT 1426 FOR COBOL
[SYMPTOM]
The TALLY statement is generated without the word COMP.
[DIAGNOSIS]
The word COMP is missing in the TALLY line.
[CURE]
Add the word COMP to the 01 TALLY statement.
********************************************************************************
EDIT 1427 FOR COBOL
[SYMPTOM]
The 68274 converter gives the error message, "Should be unsigned
integer in COBOL-74", when data item is an unsigned integer.
[DIAGNOSIS]
Before the 68274 converter loads in the the bit to tell if the
data item is a signed integer, the address of the entry in the tables
for that item are distroyed.
[CURE]
Before loading in the bit to be tested, restore the address of
the entry in the tables.
********************************************************************************
EDIT 1430 FOR COBOL
[SYMPTOM]
The first word of WORKING STORAGE may be corrupted and
COMPUTE statements will generate results that are incorrect.
[DIAGNOSIS]
When the compiler determines that an intermediary result
must be stored temporarily while another value is being
computed, a "TEMP" field is used. When determining the
number of words necessary for the "TEMP", the mode of the
intermediary field is examined. This examination does not
include a test for double precision floating point, so the
default size of one word is used.
[CURE]
Edit 1430 to EXPGEN will add an additional test to the
STASHA routine to check for double precision floating point.
********************************************************************************
EDIT 1431 FOR COBOL
[SYMPTON]
A COBOL program using DBMS will receive the syntax error:
*** FATAL - CBL639 Identifier-2 must be one-word computational
if the identifier-2 used in a FIND statement is not
computational. An index item should also be allowed.
[DIAGNOSIS]
COBOLD is currently testing the identifier for a usage mode
of computational only. This test should be extended to
allow the INDEX usage mode as well.
[CURE]
Edit 1431 to COBOLD and DIAGS will provide the additional
test and adjust the syntax error message.
********************************************************************************
EDIT 1432 FOR COBOL
[SYMPTOM]
The warning messages are not displayed on user's terminal if input to
the compiler's promt is an indirect command file.
[DIAGNOSIS]
When the input to the compiler's promt is an indirect command file,
the switch is reset to indicate that commands are being read from a
disk file. But the bit for displaying warning messages is not set
again, therefore the messages are not displayed.
[CURE]
Edit 1432 to COBOLA to turn on the bit for displaying warning
messages.
********************************************************************************
EDIT 1433 FOR COBOL
[SYMPTOM]
When generating a report with a REPORT HEADING report group, but
no PAGE HEADING report group, the program get an illegal instruction.
[DIAGNOSIS]
The REPORT WRITER CONTROL SYSTEM checks to see if there is a PAGE
HEADING report group for each report. If there is no PAGE HEADING
report group, the control system will generate one so that the page
numbers will be incremented properly. Edit 1373 generates in the PAGE
HEADING section, code to test if a form feed is needed. If there is
no PAGE HEADING report group, the code generated edit 1373 should not
be done.
[CURE]
Make a test to see if the PAGE HEADING routine is a dummy
routine. If it is, generate only an increment PAGE-COUNTER in the
PAGE HEADING routine.
********************************************************************************
EDIT 1434 FOR COBOL
[SYMPTOM]
UNSTRINGing data into signed numeric fields will not pass
the sign that is stored in the source field.
[DIAGNOSIS]
When forming a description of the sending field for numeric
data, the sign flag is always shut off.
[CURE]
Edit 1434 to STRGEN will insert a new test on the receiving
field to determine if it is signed, and if it is, will turn
on the sign flag in the sending field. This will cause
MOVGEN to allow the sign to be moved with the data.
********************************************************************************
EDIT 1435 FOR COBOL
[SYMPTOM]
If you give /Y with no ":" followed by <CR-LF>, COBOL goes
into TI wait state. If you give the same command from an
indirect file, COBOL gives IO to unassigned channel. Also,
in the same code the error message at NOFILE is not
complete.
[DIAGNOSIS]
COBOL has already eaten the <CR-LF> while looking for the
":". It then goes into a loop at BADCOM eating up the line
looking for a <CR-LF>. In the case of the indirect file
COBOL tries to continue but has wiped out the I/O buffers.
[CURE]
If the command is from the terminal, set the bit to reread
the last character so we will see the <CR-LF> again. If an
error occurs in an indirect command, just exit. This means
moving some code from BADC2 to HELP which previously shared
the same two lines of code. Fix NOFILE by calling the
routine to output the correct file spec.
********************************************************************************
EDIT 1436 FOR COBOL
[SYMPTOM]
The 68274 converter dies with an illegal UUO when a program
contains a COUNT entry in an input CD, or if there is a CLASS entry in
an output CD.
[DIAGNOSIS]
When the 68274 converter sees the COUNT statement, or a CLASS
statement in the COMMUNICATION SECTION, a conversion of the word DEPTH
to COUNT is attempted. Because there is no word DEPTH in the current
buffer, this causes an illegal instruction.
[CURE]
If the COUNT statement, or the CLASS statement is incountered,
make no attempt to convert the word DEPTH to COUNT.
********************************************************************************
EDIT 1437 FOR COBOL
[SYMPTOM]
If there is more than one undefined label in a line, only the
first will get flagged as an undefined symbol.
[DIAGNOSIS]
If an error has occured on a DISPLAY statement line, the
remainder of the line is not processed.
[CURE]
If the error on the display statement is an undefined symbol
error, generate an error for the symbol, and process the remainder of
the line.
********************************************************************************
EDIT 1440 FOR COBOL
[SYMPTOM]
COPY REPLACING of a text string by a numeric literal may
give a spurious "Period assumed" warning.
[DIAGNOSIS]
GETITM, the COBOL character scanner, would like to operate
in one pass. Whenever it has to look ahead, it sets flags
and writes to the listing file. However, COPY REPLACING
requires that it use two passes and backup the source and
listing file. This specific bug occurs because the scanner
encounters "FOO." and finds that FOO is to be replaced by a
number, say 1. It then reads ahead again to find the
terminator and finds a period. It now has "1." and does not
know if that is an integer 1 followed by a period or the
first part of a floating point number. It then reads ahead
until it finds a space, which may be on the next line or
even worse. At this point it cannot backup correctly and
thus looses the period.
[CURE]
After replacing the text string, it is impossible to
continue the numeric literal after the period. So, set the
flag that says stop on period to resolve the ambiguity.
********************************************************************************
EDIT 1441 FOR COBOL
[SYMPTOM]
EXPGEN will not assemble if the BIS assembly switch is off
and edit 1402 or 1430 is installed. An undefined symbol
will result in either case.
[DIAGNOSIS]
The symbol "CCXFP" should include a period (CCXFP.).
References to F2MODE (two-word floating point) are for BIS
systems only.
[CURE]
Make references to F2MODE conditionally defined and correct
spelling of "CCXFP.".
********************************************************************************
EDIT 1442 FOR COBOL
[SYMPTOM]
A MOVE of a 10 digit DISPLAY item with LEADING SEPARATE sign to a
1-word COMP item moves only the sign.
Also a MOVE of a large negative DISPLAY item with LEADING sign to a
smaller COMP item will lose the sign.
[DIAGNOSIS]
There is confusion over the size of the DISPLAY item. Since the sign
occupies a character position the data item is actually 11 bytes long
and all must be read to get the correct value. The code at MDC.
knows this and removes 1 before making the truncation test. However
the result is now returned in two words not one as the subsequent code
expects. This code believes that the value is in AC not AC+1 and thus
just moves the sign.
In the case that the source picture is actually bigger than the
destination the source value is truncated from the left by advancing
the source input byte pointer. This will not work if it has a leading
sign.
[CURE]
Test for the possibility that two words might be returned and get the
result from the correct acc.
Add the sepatate sign test in other places so that false truncation
warnings are not given.
If the source has a leading sign do not truncate from the left. Get
the full value and then truncate by division.
Note that these changes will not produce optimal code. However to do
so would have invalidated existing programs.
********************************************************************************
EDIT 1443 FOR COBOL
[SYMPTOM]
The COBOL compiler allows identifier of a FIND statement to be a
COMP item with decimal places in some cases, and does not allow it in
others.
[DIAGNOSIS]
FIND-rse-3 does not check to see if the data item defined by
identifier is a COMP item with no decimal places.
[CURE]
Check to see if the COMP item has decimal places. If it does,
generate an error message.
********************************************************************************
EDIT 1444 FOR COBOL
[SYMPTOM]
68274 does not convert card image source files correctly if column
73-80 exists.
Specificaly:
1. If a text string is replaced by a longer one the comment
column is shifted right causing the line to become too long.
2. Some text strings do not get converted and the coment column
is changed instead.
[DIAGNOSIS]
These are two separate but related problems.
1. Although a counter is kept as to how much the line has been
increased it is never used and the text replacement causes
the line to shifted.
2. If the text to be replaced is the first item on a line the
pointer to the beginning of the item is actually to the space
after the last item on the previous line. The converter
synchronizes by comparing the first character of the old text
string with the text after this space. Normally this is OK
as a <cr-lf> is found and the next line tried. However if a
character in the comment field matches then replacement
occurs at the wrong place.
[CURE]
1. If the new line would be longer see if enough spaces not in
literals can be removed to keep the line the same length. If
so do that, if not split the line at the last space not in a
literal before column 73 and continue the line in field B on
a new line.
2. Compare up to six characters for a correct match before
synchronizing.
********************************************************************************
EDIT 1445 FOR COBOL
[SYMPTOM]
68274 converts a clause into a comment by inserting a "*" in the
comment column. If this clause is the last in a paragraph the ending
period gets included in the comment.
[DIAGNOSIS]
There is no code to backup over the period and split the line so that
only the clause is commented and the period is on a new line.
[CURE]
Write the code to do so.
********************************************************************************
EDIT 1 FOR CPYLIB
[SYMPTOM]
Compiling programs that invokes a library built by CPYLIB causes a
premature EOF error if the first module in the library is built with
the /S option.
[DIAGNOSIS]
When CPYLIB builds the rough table for the library, it makes a
two-word entry from the first of each 128 modules to build this table.
The second word contains the address of the fine table. If the first
module happens to have the /S option, the bit on the left half of this
word which specifies the /S option is set and also gets moved to the
rough table ,this makes CPYLIB go to the wrong address looking for the
fine table.
[CURE]
Edit 1 to CPYLIB to clear the option bit in left half of this word.
********************************************************************************
EDIT 2 FOR CPYLIB
[SYMPTOM]
The INSERT command does not allow module name to include digits.
[DIAGNOSIS]
When the INSERT command is executed, a check is made to determine
if the module name is valid. This checking is done by checking each
character of the module name. If a character is not a letter or a
dash, an error message is printed, and the INSERT command is ignored.
[CURE]
When checking each character of the module name, check to see if
the character is a digit. If it is a digit, store the digit, and then
read the next character.
********************************************************************************
EDIT 3 FOR CPYLIB
[SYMPTOM]
An incorrect library routine will be retrieved by CPYLIB or
the COBOL compiler.
[DIAGNOSIS]
In the fine table at the head of the library file, the
address of each module is stored in 23 bits. CPYLIB is only
storing 21 bits of the module address. It is also doing a
half word load to get the address, so only 18 bits are
picked up. This incomplete address is then being used later
to retrieve the module, so the wrong data is accessed.
[CURE]
Edit 3 to CPYLIB.MAC will fix the byte pointers to use all
23 bits of the address field. A error message will be
issued if the library file has grown too large and can no
longer be expanded.
********************************************************************************
EDIT 201 FOR ISAM
[SYMPTOM]
When trying to exit the ISAM utility with a control-z, different
error messages will be displayed depending on what part of the utility
is being executed.
[DIAGNOSIS]
When ISAM makes comparisons to identify the character that has
been input, it fails to check for a control-z.
[CURE]
Test for input of a control-z and if seen exit the ISAM utility.
This is accomplished by Edit 201 to ISAM.
********************************************************************************
EDIT 204 FOR ISAM
[SYMPTOM]
when building an ISAM file from a sequential file and ISAM encounters
a record too short for the key field, only error message "?ISMRTS?
record too short to contain key field" is displayed. When keys are
out of order, only message "?ISMK00 keys are out of order" and the key
are displayed. The offending record itself is not.
[DIAGNOSIS]
There is no routine in ISAM to display content of records with errors.
[CURE]
A routine is installed in ISAM to display the number of the offending
record and the content of this record.
********************************************************************************
EDIT 205 FOR ISAM
[SYMPTOM]
When an error occurs during a read or write operation, the file status
bits are checked, but only a general purpose error message is displayed.
No apecific information is given to tell the user the cause of the error.
[DIAGNOSIS]
There is no routine in ISAM to display error messages according to
file status bits thtat are set.
[CURE]
A routine has been installed in ISAM to interrogate the bit settings
********************************************************************************
EDIT 206 FOR ISAM
[SYMPTOM]
When printing out an error message from ISAM, an extra comma is
always included at the end of the last message.
[DIAGNOSIS]
The ASCIZ error message includes an comma as part of the literal.
[CURE]
Type out the comma separately. If it is the last message, do not
type out a comma.
********************************************************************************
EDIT 31 FOR LIBARY
[SYMPTOM]
LIBARY will print the error message "?ERROR READING INPUT
FILE" and halt if there is a module with no source lines in
a .LIB file.
[DIAGNOSIS]
While looking for some source to process, LIBARY skips ahead
and copies the next module rather than recognize an empty
module. This puts its pointers one off. When the directory
indicates that there should be one more module to copy, the
actual end of file has been reached. It continues reading
to find the last module and attempts to go beyond end of
file, which leads to the error message.
[CURE]
To detect empty modules, at COPYL0, check the value of AC14
to see if it contains -1 which indicates the end of a
module. If if does, don't fall into the loop which will
proceed to copy, instead set end-of-module and exit.
********************************************************************************
EDIT 1014 FOR LIBOL
[SYMPTOM]
Attempting to print two files from MTA1 after another causes
the last record of the FILE-1 to be overprinted by the first
record of the file-2.
[DIAGNOSIS]
If the last record of file-1 is written with write AFTER
ADVANCING and the first record in FILE-2 was written with
write BEFORE ADVANCING and FILE-2 is output to same line
printer immediately after FILE-1, then the last record of
file-1 will be overprinted by the first record of FILE-2.
[CURE]
Insert an extra carriage-return at the end of magtape files.
This conforms with the way disk files are handled.
NOTE: Read Beware file on extra carriage-return.
********************************************************************************
EDIT 1015 FOR LIBOL
[SYMPTOM]
Open a file for simultaneous update gives the wrong error
number, if the file does not exist. (COBOL-74 only)
[DIAGNOSIS]
The COMPT.UUO error value was set to 08 (illegal tapop)
instead of 02 (lookup) for CD of the error number.
[CURE]
Set E.MCPT to 02 (lookup).
********************************************************************************
EDIT 1016 FOR LIBOL
[SYMPTOM]
Using the CHECKPOINT EVERY n RECORDS clause with ISAM files open
for Input-Output, causes Illegal UUO errors on TOPS-10 and the data
file to grow very large on TOPS-20.
[DIAGNOSIS]
The EVERY n RECORDS phrase of the CHECKPOINT clause causes the
CKPREC routine of CBLIO to be executed. This routine tests for the
type of file and how it was opened. If the file is random or opened
for I/O execution jumps to a routine for random output. However, ISAM
files opened for I/O were also jumping to this routine which uses the
wrong pointers to output ISAM files. If the file is an ISAM file it
should drop down to the code at label CPREC1 that outputs the records
through a "FILOP. .FOURB".
[CURE]
Test for ISAM files and have them proceed to the code at CPREC1.
This is done by Edit 1016 to CBLIO.
********************************************************************************
EDIT 1017 FOR LIBOL
[SYMPTOM]
When an open error occurs on an RMS file and the open error
pertains to the file being modified, RMSIO can continue to
reopen the file until it is available. Setting the action
code to one in the declarative section causes the
declarative section to be executed everytime the open is
retried. The ERRNUM was also setup in the declarative
section but after the first display of ERRNUM all other
occurrences were wrong.
[DIAGNOSIS]
The location that stored the updated ERRNUM information was
never cleared. Thus the updated information would be added
to the previous information. etc...
[CURE]
Initialize ERRNUM location before updating.
********************************************************************************
EDIT 1020 FOR LIBOL
[SYMPTOM]
When using the CHECKPOINT EVERY n RECORDS phrase with RMS files,
the records are not being written to the disk when a checkpoint is
reached.
[DIAGNOSIS]
In COBOL, RMS files use the RMSIO module of LIBOL to perform the
required I-O functions. This module was not testing for the use of
the CHECKPOINT EVERY n RECORDS phrase. Also, it was missing the
counter and tests of the counter that determine when to force the
buffers to disk.
[CURE]
When the file is opened, determine if checkpointing is designated
in the ORGANIZATION clause and if it is, initialize the checkpoint
count. After each write to the buffer decrement the count until it
equals zero, at which point, force a write to the disk. Edit 1020 to
RMSIO performs these steps.
********************************************************************************
EDIT 1021 FOR LIBOL
[SYMPTOM]
READ NEXT statement should return the next logical record
with a key higher than the last READ executed regardless of
intervening WRITES, REWRITES, or DELETES. (THIS IS HOW IT
SHOULD WORK) Instead, READ NEXT would start reading the next
logical record with a key higher than the last WRITE, or
READ. (WHICH IS WRONG)
NOTE: Documentaion on READ NEXT (indexed files) is
incorrect in the COBOL-74 (12B) manual.
[DIAGNOSIS]
The first release fo COBOL-74, Version (12), designed READ
NEXT to be similar to COBOL-68s manipulation of an INDEXED
file sequentially. This allowed a sequential READ of an
INDEXED file to return a record with a key value higher than
the last processed WRITE, DELETE, or REWRITE. This remained
the same until the second maintenance release of COBOL-74.
In Version 12B, an attempt was made to emulate ANSI-74
standard for READ NEXT. Thus intervening REWRITES and
DELETES did not affect the pointer for READ NEXT, but
WRITES, and READS did.
NOTE: The documentation for READ NEXT was not changed to
reflect this software implementation from Version 12 to 12B.
However, a future version of the COBOL-74 documentation
will have this technical note corrected.
[CURE]
Change the WRITE code so READ NEXT is not affected. Thus
READ NEXT will only return the next logical record with a
key higher than the last READ.
********************************************************************************
EDIT 1022 FOR LIBOL
[SYMPTOM]
When a RMS file fails to OPEN because it is already in use, the
memory just allocated to it is not being released.
[DIAGNOSIS]
Before attempting to open a file, a call is made to FUNCT. for
the purpose of obtaining memory space for the file. If the file fails
to open because it is already locked through use by someone else, the
memory assigned for the file is not returned.
[CURE]
When an error occurs on an OPEN, return the allocated memory.
Edit 1022 to RMSIO accomplishes this by issuing another call to
FUNCT..
********************************************************************************
EDIT 1023 FOR LIBOL
[SYMPTOM]
The REWRITE statement clobbers a pointer so that every sequential
READ following the REWRITE always returns the rewritten record
instead of the next record to be read.
[DIAGNOSIS]
The resutl of a test for rewrite (TXNE AC16, V%RWRT) in version 12B
LIBOL causes the incorrect bypass of the code to update the pointer
to the next record.
[CURE]
Edit 1023 to CBLIO to delete the code that has been doing the
unnecessary test.
********************************************************************************
EDIT 1024 FOR LIBOL
[SYMPTOM]
A memory protection violation occurs when reading a blocked
sequential file.
[DIAGNOSIS]
When a READ is performed on a blocked sequential file, a check is
made for a carriage return to signify the end of record. However,
since the format for an ASCII file has changed, not all files end with
a carriage return. As a result, the READ proceeds past the file
boundaries causing a memory protection violation.
[CURE]
Reinstate the code which uses a counter to check for end of
record. The counter only needs to be used on the last block of the
file. This is accomplished by edit 1024 to CBLIO.
********************************************************************************
EDIT 1025 FOR LIBOL
[SYMPTOM]
An overlayed program will loop within the same five
statements, as can be seen by using control T's.
[DIAGNOSIS]
Calls to the routine FUNCBC of module COBFUN are attempting
to free up unused core. Currently, the value of HLOVL. is
being tested on to see if there are any overlays. If there
are, it is assumed CORPT. is pointing to the first block of
core in the overlay list and it is being used to scan to the
end of the overlayed area, looking for an unused block of
core to be freed. If CORPT. is zero, there is no free
core, and the routine should be exited. Instead, LIBOL is
trying to scan anyway, and gets caught in a loop.
[CURE]
Edit 1025 will put in a test on CORPT. and will exit FUNCBC
if it is zero.
********************************************************************************
EDIT 1026 FOR LIBOL
[SYMPTON]
The first five bytes of an ASCII record will be lost if the
record is the first write to an extended file whose size is
a multiple of blocks large.
[DIAGNOSIS]
The pointer into the current buffer is not adjusted if the
append FILOP. does require any data to be brought into the
buffer. Since a file which ends on a block boundary cannot
add to the last block, no data needs to be brought in from
disk, so the pointer is not adjusted to the current
location. Later routines assume it has been set up.
[CURE]
Initialize the pointer to zero before the append FILOP. .
********************************************************************************
EDIT 1027 FOR LIBOL
[SYMPTON]
A program using a RETAIN NEXT statement with a key of
low-values can gain access to the first record in the file
even if another program has locked that record using a
direct RETAIN statement.
[DIAGNOSIS]
Before doing a fake read, LSU does a read of the current
record to store some pointers. If this is then followed by
a fake read with a low-value key, LIBOL assumes sequential
processing and that it has already set up the block number
due to the prior read. Therefore, it doesn't bother to read
again even though LSU has zeroed the block number field.
This results in a block number of zero being sent back to
LSU module.
[CURE]
Zero out the buffer location field, CNTRY(I12), which the
read routine is using to determine if it needs to find block
number for a read to a sequential file.
********************************************************************************
EDIT 1030 FOR LIBOL
[SYMPTOM]
Open fails with a 'SFD not found' error when a simultaneous
update file on an ersatz device is opened from a SFD.
[DIAGNOSIS]
The open failure occurs when all three of the following
conditions are present:
1. The file being opened is a simultaneous update file.
2. The file is on an ersatz device.
3. The file is opened from a SFD.
A simultaneous update file is opened by a FILOP. monitor call. Other
files are opened with different monitor calls. The FILOP.'s argument
block is set up with information obtained from a PATH. call. The
PATH. call gets the user's default path when no PPN is specified.
Since the program is being run form an SFD, the sixbit name of the SFD
is also being returned in the path block. However, when the FILOP.
attempts to open the file it is looking for the SFD under the ersatz
device, thus causing the error 'SFD not found'.
[CURE]
Check to find out whether the file is on an ersatz device by
first comparing the device named being used with the physical device
name and secondly comparing the PPN for the device with the user PPN.
If it is an ersatz device, clear the SFD area of the path block. Edit
1030 to CBLIO accomplishes this.
********************************************************************************
EDIT 1031 FOR LIBOL
[SYMPTOM]
Some records written to an ascii file could not be read back
depending on the blocking factor.
[DIAGNOSIS]
The maximum record size does not include <CR><LF> pair in
the record count. However, it decrements the character
count when they are encountered. This can cause small
records to be skipped over depending on the Blocking factor
since a <CR> and, or <LF> maybe counted as a record.
[CURE]
Don't decrement the character per record count when
encountering a <CR> or <LF>.
********************************************************************************
EDIT 1032 FOR LIBOL
[SYMPTOM]
If the pointer points to the last byte of the
destination, the string verb will always take the overflow
path.
[DIAGNOSIS]
The check for enough characters in the destination
is off by one.
[CURE]
Change
CAIL T1,(DSTCC)
to
CAILE T1,(DSTCC)
********************************************************************************
EDIT 1033 FOR LIBOL
[SYMPTOM] System labeled tapes are forward spaced to the beginning of
the next file if a fatal error is encountered while the tape is open
for input.
[DIAGNOSIS] After LIBOL detects a fatal error, it does a normal close
on all mag tape files open for input.
[CURE] When an error is detected by LIBOL do an abort close rather
than a normal close on all input mag tapes.
********************************************************************************
EDIT 1034 FOR LIBOL
[SYMPTON]
When packing an ISAM file, the following error message is
displayed:
?Actual size of ISAM Data record nnnn > ISAM
maximum record size parameter nn
[DIAGNOSIS]
While reading through the data blocks of the ISAM file to
isolate data records to be placed in the packed output file,
headers from the first word in each record are interrogated
to determine the actual size of the record. This error
message occurs when the size of the record found in the
header is larger than the maximum specified when the ISAM
file was originally built. In this instance, the word being
used as a record header was not part of a valid record, but
was data left in the block after a record was deleted. The
delete routine had placed a null record header after the
last valid record to indicate no more records followed, but
left the rest of the record data intact. When a rewrite was
done of the last valid record and its size increased, it
overwrote the null header. Rewrite will not place a new
null record header after the expanded record because it
assumes that the rest of the block already contain nulls.
This assumption is incorrect if a record has been deleted
from that block.
[CURE]
The ISAM utility fills all unused portions of a data block
with nulls and expects the file to be maintained that way.
When packing a file, it expects to find either valid records
and headers or nulls. LIBOL's delete routine is maintaining
correct record header information, but is not maintaining
the rest of the data block consistent with this design.
Edit 1034 to CBLIO will extend the delete routine to zero
out the area of the data block that is no longer in use.
********************************************************************************
EDIT 1035 FOR LIBOL
[SYMPTOM]
READ NEXT after a DELETE on a sixbit relative file reads every other
record.
[DIAGNOSIS]
The delete routine for sixbit relatvie file puts null in the header of
the deleted record and moves the next record up to the deleted one.
However, the pointers are not updated and not pointing to the correct
headers.
[CURE]
Edit 1035 to CBLIO updates pointers after a record is deleted.
********************************************************************************
EDIT 1036 FOR LIBOL
[SYMPTOM]
Checkpointed write to a relative file causes PA1050 error on
subsequent write to a sequential file.
[DIAGNOSIS]
The checkpointed write to a relative file sets the right half of
UOUT., which is a parameter for making an output JSYS call. The right
half of UOUT. is never cleared before exiting to the user program.
Therefore, when the subsequent write uses this parameter, it assumes
that the right half is already reset to zero and gets incorrect
channel.
[cure]
Edit 1036 to CBLIO to zero the right half of UOUT. on return from
routine RANOUT.
********************************************************************************
EDIT 1037 FOR LIBOL
[SYMPTOM]
A program which attempts to use the WRITE verb on a file with
ORGANIZATION SEQUENTIAL opened for I-O gets diagnostic at run time:
FILE FOO [FOO.BAR] on DEVICE dev: is not open
for OUTPUT.
[DIAGNOSIS]
The file is indeed opened for output as well as input. What the error
message does not specify is that with the WRITE verb, the file has to
be opened for output only.
[CURE]
Edit 1037 to CBLIO to clarify the error message.
********************************************************************************
EDIT 1040 FOR LIBOL
[SYMPTON]
The following error message will appear if SORT is called
from a program which has defined its own collating sequence:
"? SRTRTO RETURN called out of sequence. SORT not active."
[DIAGNOSIS]
The compiler sets up a series of parameter fields used by
both SORT and LIBOL. One area will contain the key after
LIBOL has converted it according to the user-defined
collating sequence. The byte pointer used to transfer
sixbit characters into this field is incorrect, and results
in only 5 characters being stored per word instead of 6.
This means that more space is used to hold the key than was
allocated and results in the corruption of a parameter
following the key area.
[CURE]
Edit 1040 to KEY.MAC will change the byte pointer to the key
parameter area to allow for 6 characters to be stored.
********************************************************************************
EDIT 1041 FOR LIBOL
[SYMPTOM]
SIZE ERROR does not work properly when ACCEPTed numeric data items are
MULTIPLYed by a constant.
[DIAGNOSIS]
System flags are never cleared after an ADD operation in the module
ACCEPT, and so when the overflow bit is set, it causes the false SIZE
ERROR condition.
[CURE]
Edit 1041 to ACCEPT to clear the system flags.
********************************************************************************
EDIT 1042 FOR LIBOL
[SYMPTOM]
Opening a sequential file with OUTPUT, INPUT-OUTPUT, or EXTEND
mode that has a blocking factor not zero generates an illegal
instruction if the file is already open by another program.
[DIAGNOSIS]
When a sequential or non-blocked file is opened, .JBFF is pushed onto
the stack prior to the open FILOP. If the open failed for a
sequential blocked file, the .JBFF save is not popped off the stack,
and when a return is executed it generates an illegal instruction.
[CURE]
Check to see if the file was opened for sequential access or if
the file did not contain a blocking factor, and if so pop off the
.JBFF save.
********************************************************************************
EDIT 1043 FOR LIBOL
[SYMPTOM]
When processing a multi-volume, end-of-file errors do not
generate warning messages.
[DIAGNOSIS]
LIBOL ignores all end-of-file errors when processing magtapes.
[CURE]
Delete the code for jumping around processing of end-of-file
errors.
********************************************************************************
EDIT 1044 FOR LIBOL
[SYMPTOM]
RMS does not space fill newly created records like ISAM.
[DIAGNOSIS]
RMSIO does not initialize the record area with spaces at file open
time. Therefore the unfilled part of the data record has nulls.
[CURE]
Edit 1044 to RMSIO to space fill the record area when opening the
file.
********************************************************************************
EDIT 1045 FOR LIBOL
[SYMPTOM]
When RMS-20 with LIBOL-20 V12B is used in conjunction with such other
software as TRAFFIC-20, two pages of RMS-20 global data can be lost.
[DIAGNOSIS]
Those two pages are never actually touched when the RMS-20 entry
vector is being gotten. As a result the TOPS-20 Page Handler does not
know about them and considers itself free to assign them to someone
else in the run-unit, if requested. Those two pages contain symbols
for RMS-20 global data. The corresponding action for RMS-10 is done
by an explicit call to a PAGE. UUO. However, a TOPS-20 run-unit will
not initialize those two pages until the first call to an RMS-20 JSYS,
which will touch the pages.
[CURE]
Install Edit 1045 to RMSIO.MAC in LIBOL-20 and rebuild LIBOL-20. Edit
1045 inserts a $MESSAGE RMS-20 JSYS call into the RMSGET run-time
initialization procedure. The usual purpose of this call is to turn
on the reporting of RMS-20 internal messages. However, in this case
it also initializes the RMS-20 system in the user's address space,
causing those two pages to be touched. This is because it is now the
first RMS-20 JSYS call done by the user's run-unit.
********************************************************************************
EDIT 1046 FOR LIBOL
[SYMPTOM]
When using the CHECKPOINT EVERY n RECORDS phrase with RMS files,
the records are not being updated on the disk when a checkpoint is
reached.
[DIAGNOSIS]
LIBOL was not testing to see if a checkpoint has been reached
when delete or rewrite is executed.
[CURE]
After each delete, or rewrite to the buffer, decrement the
counter for the number of records before another checkpoint. If this
count is zero, update the disk and reset the counter back to the
initial value.
********************************************************************************
END OF COBOL-20-V12B