Trailing-Edge
-
PDP-10 Archives
-
bb-bt99e-bb
-
cbl12b.d05
There are 2 other files named cbl12b.d05 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR COBOL-10-V12B
EDIT 40 FOR COBDDT
[SYMPTOM]
On TOPS-20, 12B only, COBDDT does not like subscripting and
qualification unless you type an escape after the dataname.
[DIAGNOSIS]
Break character was specified incorrectly.
[CURE]
Use correct break characters when parsing a dataname.
Install Edit 40 to COBDDT.
********************************************************************************
EDIT 41 FOR COBDDT
[SYMPTOM]
In COBDDT, qualification of a data-name fails.
[DIAGNOSIS]
In the qualification procedure, an AC was not properly
cleared.
[CURE]
Install edit 41 to COBDDT.
********************************************************************************
EDIT 42 FOR COBDDT
[SYMPTOM]
On TOPS-20, 12B only, COBDDT does not like subscripting and
qualification unless you type an escape after the dataname.
[DIAGNOSIS]
Break character was specified incorrectly.
[CURE]
Use correct break characters when parsing a dataname.
Install Edit 40 to COBDDT.
********************************************************************************
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 1300 FOR COBOL
[SYMPTOM]
If a Subprogram has a Redefines data item in its Linkage
Section and the Using clause of the Procedure Division
header or of any Entry statement references only the
Redefines item and does not explicitly reference the
original Redefined item but the original data item is
referenced elsewhere in the Procedure Division code, the
reference to the original data item will be flagged with the
Fatal diagnostic message "Not declared in an ENTRY or PD
USING clause".
[DIAGNOSIS]
In Phase E of the compiler, the routine CMNGEN is not
checking for the existence of the original "brother" of the
Redefines data item.
[CURE]
Install edit 1300 to the compiler to do this checking, and
use the "brother" if available. Note: This is the official
version of this edit. Any other version is to be
disregarded.
********************************************************************************
EDIT 1301 FOR COBOL
[SYMPTOM]
Some cases of optmizing SKIP instructions cause the compiler
to abort with an Illegal Memory Reference at 0 on KI-10s.
[DIAGNOSIS]
AOS instruction incorrectly coded to adjust stuck pointer
instead of current stack entry pointed to.
[CURE]
Install Edit 1301 to the compiler.
********************************************************************************
EDIT 1302 FOR COBOL
[SYMPTOM]
Catastrophe in Phase E of the compiler with a Bad Table Link
with RMS Indexed files in some cases where the Record Key is
not specified in the SELECT statement. These cases involve
the WRITE, REWRITE, and DELETE verbs and the READ verb where
the Record Key clause is missing.
[DIAGNOSIS]
The routine UKADR in the module IOGEN is not checking for a
valid reference address for the Record Key specification for
the verb before calling LKNSET in order to obtain the Record
Key specs. A Fatal diagnostic message should be given if
this address is not available.
[CURE]
Install edit 1302 to the COBOL-74 compiler, which will cause
it to give the Fatal diagnostic.
********************************************************************************
EDIT 1303 FOR COBOL
[SYMPTOM]
Bad code generated for RMS variable length records, so that
the "Depending On" Error return is taken. If the compile
goes to completion the run-time message "Attempt to change
record size on rewrite" may be seen following an attempt to
write a record. In other cases the compile may fail with
the message "Transmission Error .. ?Cannot continue".
[DIAGNOSIS]
In the routine WRTM in IOGEN, the instruction to create the
variable length code sets up the proper value in the AC TE,
and this value is overwritten by other instructions prior to
calling the sizing routine SZDPVA. The instruction should
be moved down three positions so that it is just prior to
the call to the sizing routine.
[CURE]
Install edit 1303 to the COBOL-74 compiler.
********************************************************************************
EDIT 1304 FOR COBOL
[SYMPTOM]
COBOL-68 to COBOL-74 converter cannot convert a program if
the very first word of a copy library is a word that must be
converted to COBOL-74 syntax.
[DIAGNOSIS]
A byte pointer is left pointing to the right of the current
word in the line buffer. When a new library is seen,
initialize two more byte pointers.
[CURE]
Install edit 1304 to the COBOL compiler, and rebuild the
68274 Utility.
********************************************************************************
EDIT 1305 FOR COBOL
[SYMPTOM]
COBOL generates incorrect code for WRITE of variable length
record where there is an ADVANCING data-name clause.
[DIAGNOSIS]
No check is made for a depending variable in this case.
[CURE]
Install edit 1305 to the COBOL compiler to add test.
********************************************************************************
EDIT 1306 FOR COBOL
[SYMPTOM]
Bad table link at 526 214 catastrophe in Phase E.
[DIAGNOSIS]
In scan of data-itmes, AC TA is initialized with garbage
instead of the correct table address in some cases involving
the linkage section.
[CURE]
Install edit 1306 to the compiler.
********************************************************************************
EDIT 1307 FOR COBOL
[SYMPTOM]
MOVE of literal ZEROS to a signed COMP-3 data field does not
produce the same result as a MOVE of another field
containing COMP-3 ZEROS to the field.
[DIAGNOSIS]
The code at C3ZRO. in the module CMNGEN.MAC does not
distinguish between signed and unsigned COMP-3 receiving
operands, and always moves unsigned COMP-3 ZEROS to the
generated literal which is to be the source operand. The
preceding comments indicate that the code assumes the COMP-3
ZEROS are always signed, and then the code always puts in
the unsigned version. Also, the code assumes that if there
is a series of receiving operands they will all be unsigned.
Thus, the code also has to be changed so as to allow each
literal for the source operand to be generated separately.
[CURE]
Install edit 1307 to the compiler and re-build.
********************************************************************************
EDIT 1310 FOR COBOL
[SYMPTOM]
When two or more source copy Libraries are used in a COBOL
compile and each Library is on a different logical device
which in fact represents a different directory, for example:
R COBOL
*=COB:LIB1/L,DSK:LIB2/L PROG
the compiler will lose track of the first one in Phase C and
issue the message "%Library file DSK:LIB1.LIB not found -
continuing".
[DIAGNOSIS]
The word which stores the file extension, or type, has two
uses. The left half contains the file extension and the
right half contains a "dot seen" flag. When this flag is
on, a compare on this word will fail. Thus, we should
compare only the left half of the extension word. Also, we
should allow the null extension to match with .LIB in this
case.
[CURE]
Install edit 1310 to the compiler.
********************************************************************************
EDIT 1311 FOR COBOL
[SYMPTOM]
When a paragraph name appears twice in the same section, and
a reference is made to that paragraph, diagnostic 179 is
generated but placed at the end of the listing, rather than
immediately following the reference.
[DIAGNOSIS]
In some cases, when the diagnostic is generated, TA contains
the CURPRO value rather than the CURFLO value, causing
garbage line count and character position numbers to be
associated with the diagnostic.
[CURE]
When generating the diagnostic, insure that TA contains the
CURFLO value (edit 1311).
********************************************************************************
EDIT 1312 FOR COBOL
[SYMPTOM]
The following conditions:
02 EDIT-ITEM PIC -,---,---.99.
MOVE 200 TO EDIT-ITEM
DISPLAY EDIT-ITEM.
yield the output ", 200.00".
[DIAGNOSIS]
In the above picture clause, there is no room for a
significant digit before the first comma. It is therefore unclear
what to do about the comma.
[CURE]
Add a warning message to PSCAN, the picture scanner, to
notify the user in this situation. This is done by edit 1312 to
COBOL.
********************************************************************************
EDIT 1313 FOR COBOL
[SYMPTOM]
No diagnostic error message is reported in cases where the
conditional clause of an IF statement is followed by a
Carriage-return Line-feed pair and a section name or
paragraph name beginning in A-margin of the following line.
This problem also occurs for the special conditionals, such
as the WHEN clause of the SEARCH verb, the AT END clause of
the READ verb and the INVALID KEY clause of file record
access verbs.
[DIAGNOSIS]
When the syntax processor sees the A-margin flag, it
terminates the preceding conditional statement without
checking to see if a conditional clause was the last clause
being processed. It also forces a GO TO to the first
executable statement of the new paragraph or section as the
"True" object clause of the conditional.
[CURE]
Install edit 1313 to the COBOL compiler to cause a fatal
diagnostic message to be reported for these cases. The
diagnostic to be reported is "FATAL - STATEMENT EXPECTED".
********************************************************************************
EDIT 1314 FOR COBOL
[SYMPTOM]
Database schema contains a record description that includes a
subscripted item. When generating a BIND statement for this record,
if the compiler continues the line after the open parenthesis for the
subscript, a compiler error occurs. For example:
ENTER MACRO BIND USING ..... dataname (
- 1), .....
will cause a fatal error.
[DIAGNOSIS]
The compiler fails to treat the hyphen as a continuation
character, and instead assumes it is part of the subscript value.
[CURE]
Allow the GETWRD routine in GETITM to sense a continuation
character when looking for the first character of a word. This is
done by edit 1314 to COBOL version 12B.
********************************************************************************
EDIT 1315 FOR COBOL
[SYMPTOM]
While compiling a SEARCH statement, an illegal instruction is
encountered.
[DIAGNOSIS]
When saving A and B parameters while compiling the SEARCH,
EFLAGB is not saved, due to a bad ending address in the BLT
instruction. The macro that generates the ending address is using the
offset to the last location in the block, rather than the size of the
block which is one greater.
[CURE]
Increase the BLT ending address to include EFLAGB. This is
done by edit 1315 to COBOL.
********************************************************************************
EDIT 1316 FOR COBOL
[SYMPTOM]
There are three conditions necessary to cause the problem
symptom to appear. First, in a COBOL Library module a *
comment line appears at a point in the module other than at
the first line. Second, it is followed by a paragraph name
on the next line of the module. Third, the paragraph name
is subject to a replacement in the user's COBOL program.
The result is that the replacement paragraph name would be
appended to the * comment line in the output listing file
and it would be flagged with the fatal diagnostic message
"Statement Expected".
Although this problem is very similar to that handled by
edit 1063 to the COBOL compiler, it turned out to be a
different problem. Our investigation showed that edit 1063
handled only the case where the * comment line was the first
line of the Library copy member and was followed immediately
by a paragraph name subject to replacement on the next line
of the member.
[DIAGNOSIS]
The routine in GETITM which processes the characters of the
user's source program text was not recognizing a line-feed
at the end of a * comment line as indicated in the symptom
above as a legitimate end-of-line. In the case of a
replaced paragraph name which followed immediately on the
next line, the result was that it was not recognized as
being in A-Margin and it was appended to the comment line
and flagged with the fatal diagnostic message.
[CURE]
Install edit 1316 to the COBOL compiler to check for this
particular circumstance, and to force it to recognize the
replaced paragraph name as being in A-Margin.
********************************************************************************
EDIT 1317 FOR COBOL
[SYMPTOM]
If statement takes incorrect path when the items being
compared are larger than 2040 characters.
[DIAGNOSIS]
In comparisons larger than 2040 characters, the compiler is
generating multiple comparisons of 2040 characters or less, but not
linking them correctly to accomplish the overall comparison. In a
comparison against spaces, the true path will be taken if the first
2040 characters are spaces, even if there are nonspaces in the rest of
the item. Also, in some cases, the compiler is generating a multipart
comparison when it should be using a single comparison.
[CURE]
Change the linkage between multipart comparisons, and allow
the compiler to use a single part comparison whenever it can. This is
done by edit 1317 to COBOL version 12B.
********************************************************************************
EDIT 1320 FOR COBOL
[SYMPTOM]
COBOL-68 Version 12B does not conform strictly to the
ANSI-68 Standard regarding references to group data items
which contain data items which have the Occurs Depending
clause. Specifically for the arguments of MOVE statements
and conditionals, COBOL-68 uses the current number of Occurs
elements as indicated in the Depending data-name as the
basis of a group reference rather than the maximum length of
the Occurs data item. (See the ANSI-68 Standard, pages
2-109 and 2-110 of Table Handling Level 3. Refer especially
to item (5) at the bottom of page 2-110.)
[DIAGNOSIS]
COBOL-68 Version 12B does conform more closely to the
ANSI-74 Standard in this regard. The last version of
COBOL-68 to adhere to the ANSI-68 Standard was version 11.
Thereafter, it appeared more reasonable to adhere to the
specification of the ANSI-74 Standard in this regard. (See
the ANSI-74 Standard, pages III-2 thru III-4, especially
item (4) on page III-4.)
[CURE]
Install edit 1320 to version 12B of the compiler. Note: it
is strongly recommended that you do not install this edit
for COBOL-68 unless you require this usage. This edit is
supplied merely as a convenience to users who wish to have
continuity for this functionality when going directly from
COBOL-68 Version 11 to COBOL-68 Version 12B.
********************************************************************************
EDIT 1321 FOR COBOL
[SYMPTOM]
USE AFTER STANDARD {EXCEPTION} PROCEDURE
or
USE AFTER STANDARD {ERROR} PROCEDURE
on file-name-1 OPEN, file-name-2 OPEN...
fails after the first OPEN.
[DIAGNOSIS]
Syntax is wrong, it does not expect to see another
file-name.
[CURE]
Fix it.
********************************************************************************
EDIT 1322 FOR COBOL
[SYMPTOM]
If a COBOL program contains a paragraph which is performed
and which ends with a STOP RUN, and if that paragraph is not the last
paragraph in the program, a warning error occurs on compilation. The
same paragraph at the end of the program will not cause a warning.
[DIAGNOSIS]
The compiler fails to perform a check on the last paragraph
in the program to see if it ends with an unconditional transfer. A
warning should be issued whenever a PERFORMed paragraph ends with an
unconditional transfer.
[CURE]
Supplement the PROCEDURE DIVISION scan code executed at the
end of the program source, to check the last paragraph for
unconditional transfer termination. This is done by edit 1322 to
COBOL 12B.
********************************************************************************
EDIT 1323 FOR COBOL
[SYMPTOM]
When a larger alpha-numeric display field is moved to a
smaller edited alpha-numeric field with at least one X in
its picture clause, no truncation warning message is given.
[DIAGNOSIS]
In MOVGEN the code for generating the move to the
alpha-numeric edited field does not check the sizes of the
sending and receiving fields before it falls into the
generalized code for generating a move to an edited field of
either the numeric or alpha-numeric types.
[CURE]
Install edit 1323 to the compiler to do this test while
considering only alpha-numeric edited receiving fields.
********************************************************************************
EDIT 1324 FOR COBOL
[SYMPTOM]
Source data is passed to the .LST file buffer, but will not
be written out to the file if the buffer is full.
Subsequent source data is lost until the proper flags get
reset.
[DIAGNOSIS]
A new flag, DCCFLG, was created to determine if a
DATE-COMPILED statement is being processed. If so, the
comment entry is not supposed to be written out to the .LST
file. This should be overridden if a source line has an "*"
is column 7. Currently, the data is being sent to the print
buffer, but when the buffer is full, the write is not being
done if DCCFLG is on. The scanner continues reading and
processing source, but does no writes to the print file
while this flag is on.
[CURE]
In the module COBOLB, shut off the flag DCCFLG before
continuing to scan source that follows the DATE-COMPILED
comment entry.
********************************************************************************
EDIT 1325 FOR COBOL
[SYMPTON]
Source data is passed to the .LST file buffer, but will not
be written out to the file if the buffer is full.
Subsequent source data is lost until the proper flags get
reset.
[DIAGNOSIS]
A new flag, DCCFLG, was created to determine if a
DATE-COMPILED statement is being processed. If so, the
comment entry is not supposed to be written out to the .LST
file. This should be overridden if a source line has an "*"
in column 7. Currently, the data is being sent to the print
buffer, but when the buffer is full, the write is not being
done if DCCFLG is on. The scanner continues reading and
processing source, but does no writes to the print file
while this is on.
[CURE]
In the module COBOLB, shut off flag DCCFLD before scanning
source that follows the DATE-COMPILED comment entry.
********************************************************************************
EDIT 1326 FOR COBOL
[SYMPTOM]
Installing edit 1322 to COBOL version 12B causes the
cross reference portion of the output listing to be dropped.
[DIAGNOSIS]
The additional checking done on the last paragraph
in a program, after installing edit 1322, includes a call to
the PUTCRF routine. Since the cref file was already closed,
this call has the effect of writing a new null file over the
file that actually has the cref information.
[CURE]
Before executing the code added by edit 1322, turn
off CREFSW, which will cause the call to PUTCRF to return
immediately.
********************************************************************************
EDIT 1327 FOR COBOL
[SYMPTOM]
The IDENTIFICATION DIVISION statement is flagged with a
syntax error stating "Fatal - Must be subscripted".
[DIAGNOSIS]
A RELEASE statement was within an IF statement that was
testing a subscripted field. Since Edit 1126 to SRTGEN
causes RELEASE code to be followed by code to clear the
input buffer, this code was being generated, but without
setting up the new "B" operand. The MOVGEN code was using
the characteristics of the previous "B" operand which
specified that it requires a subscript. This caused the
compiler to expect a subscript.
[CURE]
Edit 1327 to SRTGEN will call the routine SETOPB to set up
the "B" operand before continuing on to the MOVGEN code.
********************************************************************************
EDIT 1330 FOR COBOL
[SYMPTOM]
A warning is printed on the user's console, "%MEMORY SIZE
exceeded in object program", even though the generated
program may not be larger than the declared memory size.
[DIAGNOSIS]
Phase B computes the memory size based on the value
specified in the OBJECT-COMPUTER statement if there is one.
This value is stored in OBJSIZ. Phase G uses this value to
compare it with the size of the resulting program and if the
program is larger, prints the warning on the console. This
message may be erroneous because Phase G is looking at only
the right half of the value of OBJSIZ.
[CURE]
COBOLB has been changed to test on the values generated for
memory size. A warning will be produced if the result is
greater than 777777 words octal and this value will be
assigned as the memory size. This will eliminate an
incorrect warning from being produced later at the end of
the compilation.
********************************************************************************
EDIT 1331 FOR COBOL
[SYMPTOM]
Compiler fails in phase E with an Illegal UUO on TOPS-10 or
an Illegal instruction on TOPS-20.
[DIAGNOSIS]
While generating code to handle the WRITE statement, IOGEN
called SETOPN, which noted the data item associated with the
ADVANCING phrase had been syntaxed. An error flag was set,
and control passed back to the routine WADVGB. This routine
did not check the error flag and continued processing until
the compiler failed.
[CURE]
Edit 1331 to IOGEN will put a test in routine WADVGB and
jump to an error routine to syntax the WRITE statement
before continuing to process.
********************************************************************************
EDIT 1332 FOR COBOL
[SYMPTOM]
An error is given if PROGRAM COLLATING SEQUENCE clause is
present and is not the last clause in the OBJECT-COMPUTER
paragraph.
[DIAGNOSIS]
The PROGRAM COLLATING SEQUENCE clause advances over the
comment and the next token. This does not give an error at
end of the paragraph since all that is removed is the
period. If it is not at the end of the paragraph then the
first token of the next clause is removed thus giving the
error.
[CURE]
Don't advance over the next token.
********************************************************************************
EDIT 1333 FOR COBOL
[SYMPTOM]
Syntax error using "ORGANIZATION IS RELATIVE WITH CHECKPOINT
OUTPUT".
[DIAGNOSIS]
The syntax tree for the above syntax did not allow "with
checkpoint output" for files whose organization is relative
or sequential.
[CURE]
Fix syntax tree to allow "with checkpoint output" for files
whose organization is relative or sequential.
********************************************************************************
EDIT 1334 FOR COBOL
[SYMPTOM]
If a COBOL program contains a paragraph which is
performed and which ends with a STOP RUN, and if that
paragraph is not the last paragraph in the program, a
warning error occurs on compilation. The same paragraph at
the end of the program will not cause a warning.
[DIAGNOSIS]
The compiler fails to perform a check on the last
paragraph in the program to see if it ends with an
unconditional transfer. A warning should be issued whenever
a PERFORMed paragraph ends with an unconditional transfer.
[CURE]
Supplement the PROCEDURE DIVISION scan code executed at
the end of the program source, to check the last paragraph
for unconditional transfer termination. This is done by edit
1334 to COBOL 12B.
********************************************************************************
EDIT 1335 FOR COBOL
[SYMPTOM]
A Report Writer statement specifying a SOURCE field which is
subscripted by an implicitly defined index will be given a
syntax error of "FATAL - CBL251 Improper subscript".
[DIAGNOSIS]
Implicitly defined subscripts are held in HLDTAB until the
entire DATA DIVISION has been scanned, and are then
transferred into DATAB by CLEANC. This is too late for the
Report Writer routines which expected to find the items in
DATAB and declared them as invalid subscripts when they
weren't there.
[CURE]
If REPORT SECTION is scanned, set a flag and call up the
routine in CLEANC to make DATAB entries for all indexes.
Then proceed with the Report Writer routines.
********************************************************************************
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 200 FOR ISAM
[SYMPTOM]
THE PAGE COUNT PRINTED ON A REPORT WRITER PAGE OTHER THAN A PAGE
HEADER IS ONE TOO HIGH
[DIAGNOSIS]
THE PAGE COUNT IS INCREMENTED AFTER THE PAGE HEADING ROUTINE.
AS A RESULT THE PAGE COUNT IS CORRECT WHEN IT IS REFERENCED
IN THE PAGE HEADER LINES, BUT IT IS ONE TOO HIGH ANY OTHER TIME
( SUCH AS ANY DETAIL OR PAGE FOOTER LINES).
[CURE]
1. DURING THE INITIATION OF REPORT SET PAGE COUNT TO ZERO INSTEAD OF ONE
2. INCREMENT PAGE COUNT AT THE BEGINNING OF PAGE HEADING ROUTINE INSTEAD
OF AT THE END OF IT.
THE CODE CHANGE IS IN THE REPORT GENERATOR ROUTINE, RPWGEN
********************************************************************************
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 202 FOR ISAM
[SYMPTOM]
FOR REPORT WRITING THE GENERATE STATEMENT CAUSES RUN TIME ILLEGAL
UUO AT USER PC = 000000. THIS OCCURS IF USER HAS A CONTROL FOOTING.
[DIAGNOSIS]
THE REPORT WRITER GENERATE CODE RPWGEN GENERATES
PUSHJ 17,0 FOR CALL TO CF ROUTINE.
[CURE]
PUT IN PROPER CODE TO GENERATE CF ADDRESS.
***THIS WILL BE INCLUDED IN VERSION 6A RELEASE***
********************************************************************************
EDIT 203 FOR ISAM
[SYMPTON]
If ISAM comes across a duplicate key or keys out of order,
only the first character of the key is displayed with the
appropriate error message, e.g.,
? ISMDPK Two key with equal value = 3
[DIAGNOSIS]
The AC containing the byte-pointer is clobbered after
displaying the first character of the key. This occurs
because the AC being used to set up the byte-pointer is also
used to output to the terminal.
[CURE]
Use another AC to set up the byte-pointer.
********************************************************************************
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 1000 FOR LIBOL
[SYMPTOM]
In COBOL-74 Retain of a Relative File Record by Key fails with a
Memory Protection Violation.
[DIAGNOSIS]
The code for determining the block number to retain for the Relative
File record falls into the code for ISAM file block number.
[CURE]
Install edit 1000 to LIBOL for COBOL-74.
********************************************************************************
EDIT 1001 FOR LIBOL
[SYMPTOM]
In a COPY REPLACING, if there is an "ALL" literal that does
not get replaced then the "ALL" is lost.
[DIAGNOSIS]
The "ALL" seen flag was being lost.
[CURE]
Check for this case and make sure the "ALL" flag is put back
on.
********************************************************************************
EDIT 1002 FOR LIBOL
[SYMPTOM]
A program that has a CALL or ENTER USING with an illegal or
missing data-name gets poor diagnostics out of Phase D and
gets "Wrong number of operands passed from Phase D" message
in Phase E.
[DIAGNOSIS]
The syntax trees do not detect any operands after USING is
seen. If only illegal operands are seen, then it looks like
no operands were seen. Phase E checks for no operands and
gives a catch-all error message.
[CURE]
Detect missing and illegal arguments in DTREE. Then in
Phase E, just return if no arguments have been seen since
DTREE will have given a better error message already.
********************************************************************************
EDIT 1003 FOR LIBOL
[SYMPTOM]
Certain data-names appear twice in the cross-reference table
as being defined on the same line.
[DIAGNOSIS]
This was broken several years ago by edit 373. The
data-name is initially defined and CREFed. If it is then a
lower level number than the previous data-item, it gets sent
back to DA29 where it gets CREFed again. Previously, if the
data-name was already defined it never got CREFed again.
[CURE]
Go back to DA29.0 (which is where it ends up) which bypasses
the second CREFing.
********************************************************************************
EDIT 1004 FOR LIBOL
[SYMPTOM]
With input from a signed integer field and a COMP-1 field a
multiplication which places the result into the signed
integer field produces a strange result in cases where one
of the inputs is negative and the absolute value of the
product is less than 1.
[DIAGNOSIS]
With BIS turned on, such arithmetic is done as double
precision. If the product is negative, the FIX routine is
supposed to extend the sign bit of the first word of the
product to the second word. However, due to a coding error,
it was failing to do this. In cases where the absolute
value of the product is 1 or greater, this error was causing
no problem with the output result.
[CURE]
Install edit 1004 to LIBOL to cause the FIX routine with BIS
turned on to extend the sign properly to the second word of
the operand.
********************************************************************************
EDIT 1005 FOR LIBOL
[SYMPTOM]
In COBOL-68 and COBOL-74 when IF or SEARCH are contained
within the WHEN clause of the SEARCH verb, the COBOL
compiler generates bad executable code.
[DIAGNOSIS]
IF and SEARCH are conditional statements, and the ANSI
standards for COBOL-68 and COBOL-74 explicitly disallow them
from the WHEN clause of the SEARCH verb. Thus, in order to
conform to those versions of the ANSI standard, such
syntactical usage should not be allowed. If the user feels
that he requires such usage, he should investigate the
possibility of utilizing the PERFORM verb within the range
of the WHEN clause.
[CURE]
Install edit C1005 to the COBOL-68 and COBOL-74 compilers,
which will specifically flag such usage as a fatal
compile-time error. Accordingly, any ELSE clause following
such a WHEN clause will be interpreted as terminating the
range of control of the SEARCH verb.
********************************************************************************
EDIT 1006 FOR LIBOL
[SYMPTOM]
Fatal error "Fatal - Conflicts with a use procedure in
section section-name" is printed at end of compile.
[DIAGNOSIS]
If a use procedure was declared for error on file open and
any general error use procedures were also declared, the
compiler would generate a fatal error, even though there was
no conflict.
[CURE]
Eliminate test that declares a conflict exists.
********************************************************************************
EDIT 1007 FOR LIBOL
[SYMPTOM]
`LINE NEXT PAGE' in a report causes a formfeed, but
PAGE-COUNTER is not incremented.
[DIAGNOSIS]
No code to do so is generated.
[CURE]
Have WRIGGO in RPWGEN, which handles `LINE NEXT PAGE',
generate an `AOS PAGE-COUNTER'.
********************************************************************************
EDIT 1010 FOR LIBOL
[SYMPTOM]
When compiling a program with /O using the combination no
REL file and no listing file, AS1.TMP is not deleted.
[DIAGNOSIS]
Channel 12, which is used by NNNAS1.TMP, is also being used
as a secondary channel for NNNAS2.TMP. When AS2.TMP is
finished with channel 12, no one tries to specify channel 12
back to AS1.TMP. Therefore, AS1.TMP is never deleted.
[CURE]
When AS2.TMP is through with its secondary channel (12),
specify the channel back to AS1.TMP.
********************************************************************************
EDIT 1011 FOR LIBOL
[SYMPTOM]
If an FD has a RECORD CONTAINS clause, COBOLC version 12A
believes it must have a DATA RECORD, even if it has a
REPORTS clause.
[DIAGNOSIS]
This case was not considered.
[CURE]
Check for a REPORTS clause. If there is one, do not
complain that there is no DATA RECORD.
********************************************************************************
EDIT 1012 FOR LIBOL
[SYMPTOM]
COBOL-74 was not handling END something where something was
not legal.
[DIAGNOSIS]
Missing syntax causing compiler to loop.
[CURE]
Add extra nodes to solve the problem in DTREE.
********************************************************************************
EDIT 1013 FOR LIBOL
[SYMPTOM]
If the = = delimiting the end of pseudo-text in a COPY
REPLACING is missing then the compiler will loop forever.
[DIAGNOSIS]
The compiler is not recognizing that it has encountered
end-of-file.
[CURE]
Test for end-of-file and give a fatal error message.
********************************************************************************
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 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-10-V12B