| > OpenVMS Alpha
> V6.1 V6.2 V7.0 V7.1
>PREALLOCATION/EXTENSION OK OK OK fail (see IPMT HPAQ30CUS)
From: SPSEG::SDT_ACE "11-Mar-1997 0816 -0500" 11-MAR-1997 08:17:48.93
To: Product dependent distribution list
CC:
Subj: Case HPAQ30CUS has been updated in the SDT_ACE database (%cob-f-bug_check, when reading sequential file) (%cob-f-bug_check, when reading sequential file)
[This update was sent from BRAFFITT on 11-MAR-1997 08:16:09.39]
[SDT Support responsible for next action, Problem is undefined]
RE: IPMT HPAQ30CUS
CLT::COBOL 3211
DEC COBOL RTL assertion on OpenVMS Alpha V7.1 with
APPLY PREALLOCATION
APPLY EXTENSION
We have verified that this problem shows up only on OpenVMS Alpha V7.1:
OpenVMS Alpha
V6.1 V6.2 V7.0 V7.1
OK OK OK fail
This failure shows up with all versions of the DEC COBOL RTL on OpenVMS Alpha
V7.1
This PREALLOCATION/EXTENSION problem shows up as an RTL internal consistency
check failure on OpenVMS Alpha V7.1 when an attempt is made to use either of
APPLY PREALLOCATION
APPLY EXTENSION
in a program which attempts to read a file more than once. The 2nd attempt to
read the file results in the internal consistency check failure. The temporary
workaround to this problem is to not use these 2 APPLY clauses if you need to
read a file twice on OpenVMS Alpha V7.1 with DEC COBOL.
The DEC COBOL RTL team has isolated the problem to RMS (on OpenVMS Alpha V7.1)
unexpectedly returning
RMS$_EOF
when the 2nd read of the file is attempted. This directly leads to the DEC
COBOL RTL assertion.
The problem can be demonstrated with the following program:
COBOL/NOCOND OK
COBOL/COND=P RTL assertion on OpenVMS Alpha V7.1
COBOL/COND=E RTL assertion on OpenVMS Alpha V7.1
This IMPT case should be transferred to OpenVMS Alpha RMS engineering so they
can do they next level of analysis of what is causing this difference in
behavior (unexpected RMS$_EOF) on OpenVMS Alpha V7.1.
IDENTIFICATION DIVISION.
PROGRAM-ID. DCB4120.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT FC-FILE ASSIGN TO "DCB4120.DAT".
I-O-CONTROL.
\P APPLY PREALLOCATION 500 ON FC-FILE.
\E APPLY EXTENSION 1000 ON FC-FILE.
DATA DIVISION.
FILE SECTION.
FD FC-FILE.
01 FC-REC PIC X.
PROCEDURE DIVISION.
P0. DISPLAY "***DCB4120***".
OPEN OUTPUT FC-FILE.
MOVE SPACES TO FC-REC.
WRITE FC-REC.
CLOSE FC-FILE.
OPEN INPUT FC-FILE.
READ FC-FILE AT END DISPLAY "?1".
CLOSE FC-FILE.
OPEN INPUT FC-FILE.
DISPLAY "About to try 2nd READ".
READ FC-FILE AT END DISPLAY "?2".
CLOSE FC-FILE.
DISPLAY "***END***".
STOP RUN.
- Don Braffitt
DEC/VAX COBOL project leader
|
| Here is the description of the COBOL/RMS and VMS V7.1 issue which
has been discussed here, and shared with customers and CSC.
-Chip Rice
Engineering Manager, COBOL...
A known problem exists between COBOL and RMS on V7.1. Additional testing is
needed by COBOL to determine if there are any additional issues for COBOL
with V7.1. This testing is planned in June/July 1997.
Until this testing can be completed, DEC COBOL V2.4 does not officially
support VMS V7.1.
Some COBOL users have moved to V7.1, despite the lack of "support". At least
one user has encountered problems, and reported them to COBOL engineering.
In addition, you have mentioned an installation/IVP failure, which we do
not have enough information to reproduce. This may have been an unrelated
system problem which occurred during installation.
The specific problem encountered is:
o COB-F-BUG_CHECK error when rereading a sequential file.
See the enclosed draft release note describing the problem.
This release note will appear in the release notes for a new
RMS remedial kit for OpenVMS Alpha V7.1, which is in
preparation and should be available through TIMA about
mid-June.
=========================================================================
Draft RMS release note
=========================================================================
COB-F-BUG_CHECK error when rereading a sequential file
Problem Description:
This problem is restricted to DEC COBOL on OpenVMS Alpha V7.1.
While a DEC COBOL application may fail with a COBOL internal consistency
error (COB-F-BUG_CHECK) for other reasons, a DEC COBOL application that
worked on an earlier OpenVMS version and is failing on Alpha V7.1 with
a COB-F-BUG_CHECK is likely to be remedied by this remedial kit if ALL
of the following conditions are met:
o The DEC COBOL application fails with the COB-F-BUG_CHECK error
when it is reading data records in a sequential file.
o The sequential file is opened allowing no write sharing.
o The sequential file has a maximum record size greater than zero.
A fixed-length record format always has a maximum record size
greater than zero. A zero maximum record size is typically
associated with a variable or stream record format.
o All the data records in the sequential file are read up to the
end-of-file by the DEC COBOL application.
o And the DEC COBOL application reads all the data records in the
same sequential file more than once.
The DEC COBOL application is either run multiple times within
a short time period on the same system or within the application
itself all the data records in the same sequential file are read
up to the end-of-file more than once.
If the data records are only read once, then even if all the other
conditions are met, the problem will not occur.
o Presumption: The OpenVMS virtual I/O cache (VIOC) is enabled
(and since it is enabled by default, it will be unless someone
has explicitly disabled it).
A change in behavior between RMS and the VIOC cache was added as a
performance enhancement for RMS in Alpha V7.1 (see section 5.18 of
the OpenVMS V7.1 Release Notes). VIOC now lets RMS know if it is
able to satisfy one of RMS's read requests from blocks already in its
cache. This allows RMS to avoid stalling, which reduces overhead and
improves performance. Some RMS operations that always stalled previously
now may never stall.
In the case of an unshared sequential file (with maximum record size > 0),
DEC COBOL does not use RMS record I/O ($GETs) to read the records in the
file. DEC COBOL uses asynchronous block I/O ($READs) and intermediate
buffers of its own to do its own record processing.
After reading all the data records in an unshared file, a number of the
blocks may be cached by VIOC, including data blocks beyond the logical
end-of-file. In coding the error checking for the asynchronous block I/Os,
DEC COBOL presumed that an end-of-file (EOF) status would always be
returned as a completion status after a wait and never as an immediate
status for the asynchronous block I/O read. With the V7.1 RMS/VIOC
enhancement, if the file is reread while the blocks are still cached, it
is possible for an EOF status to be appropriately returned by RMS as an
immediate status. In the case of an unexpected immediate error status,
DEC COBOL returns the COB-F-BUG_CHECK. In other words, DEC COBOL is
returning the COB-F-BUG_CHECK for an EOF status -- when in fact the read
is beyond the logical end-of-file.
The RMS/VIOC enhancement is a compatible extension of the definition of
the RMS services; a block I/O read ($READ) may (as has always been true)
complete with a status of RMS$_EOF. However, to expedite delivery of a
solution for any DEC COBOL users who may be impacted, RMS has restored
the old status behavior that DEC COBOL presumed. Namely, in the case
of an asynchronous block I/O read that completes synchronously and
the transfer is beyond the logical end-of-file, RMS$_PENDING will be
returned as the immediate status and RMS$_EOF as the completion status.
Work-arounds:
Under no conditions should it be suggested that VIOC be disabled as a
workaround.
Alternative workarounds when a nonshared sequential file has to be
read multiple times within a DEC COBOL application:
o Apply this remedial kit.
o Until the kit is installed, DEC COBOL engineering recommends
modifying the application's source code to temporarily remove
any APPLY PREALLOCATION and APPLY EXTENSION statements. There
is no guarantee that this will provide a workaround in all cases.
Underallocating the file simply decreases the probability of this
problem occurring in some cases. Since not preallocating a file
(or using a reasonable extension size) can degrade performance, this
should be viewed only as a temporary workaround to this specific
problem.
|