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.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.