On 29-Nov-2013 17:32 -0800, Tom Hightower wrote:
Copied the data as you suggest - same error, same bogus record number
(there are only 864774 record in the file).
I believe the error will re-create, even with zero records; i.e. the
program run against an empty file. Could you verify?; if the /copied/
files and data still exist, just CLRPFM.
I suspect the "record number 4294967295" as [the intended] special
value of negative one (-1) for unsigned 4-byte integer with value
2**32-1 indicates that the read was by key, but no position was
obtained; in this case, apparently due to the key position value being
an invalid date representation.
And I suspect the error following the CPF5035 RC17, was msg CPF5097
"Key mapping error" with the same information for its replacement
variables; i.e. instead of the CPF5029 that I had alluded would have
"all of the same information for its replacement variables".?
Confirmed by your reply to Michael the value of BEGIN-DATE is blanks,
and as alluded by Michael the BEGIN-DATE variable would need to be set
for a /key-position request/ because that variable serves as the value
for the key sent to the database. The value of all blanks is not a
valid string-representation of an ISO date, so the database balks;
signaling the msgCPF5035 RC17 with the implication that no position
could be obtained [i.e. the RRN being that 4-billion+ number].
If so, depending on the requirements of the program, changing to use
ACCESS MODE SEQUENTIAL instead of ACCESS MODE DYNAMIC and then repeated
READ until end-of-file, or if specifying a starting key is desired then
*initialize the starting key values* [at least for its BEGIN_DATE; other
values as their data-type defaults may be appropriate.?] and then
perform repeated READ NEXT or issue READ KEY IS data-name-1. Note: As a
DESCENDING key, the most appropriate start for BEGIN-DATE may be an
effective *highval when no specific date is required, or a partial key
should be used; e.g. to set an effective *hival:
MOVE '9999-12-31' TO BEGIN-DATE.
If that does not resolve the issue, then:
Please post the DDS for the EVENTS, JE027000, and JE027006 files; at
least the BEGIN_DATE field, key fields, and both file-level and
record-level specs. Also the full START statement and any READ
statement from the CBL program for that file.
Could you run the request with debug active, and post the spooled
joblog to include all messages from the start of the request [e.g. CALL
IDOCKETGY/CCEXTRACT] until and including the LNR7057 diagnosing the FS90?
As an Amazon Associate we earn from qualifying purchases.