Google
 

Trailing-Edge - PDP-10 Archives - bb-bt99g-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