Joel, was there a resolution?
Was this a simple matter of recreating the production program? Or was there
On Wed, Jul 2, 2014 at 7:41 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:
On 02-Jul-2014 16:49 -0500, Stone, Joel wrote:
DCL &NrecsB4 *dec LEN(10 0) value(0)
RTVMBRD FILE(libname/filename) NBRCURRCD(&NRECSB4)
Started failing recently when #recs in file exceeded 10,000,000.
When I run the command alone in a new CL, it works well.
But in a production job, it throws an error with CPF0819.
Presumably that is the symptom msgCPF0819 F/QCLCNVNC, and follows the
logged request message for the /same/ RTVMBRD? The lack of the details
having been provided in the OP, taken from the spooled LOG(4 0 *SECLVL)
LOGCLPGM(*YES) joblog, means the symptom is merely an assumption.
Can the program source for the production program be used successfully
to recompile the same program, but into QTEMP; i.e. without an error msg
CPD0783 "Variable &3 for parameter NBRCURRCD must be TYPE(*DEC),
LEN(10,0)."? And is the source line of the DCL statement for the variable
that is specified on the RTVMBRD of the production program unchanged; and
of course that the CL source is the match?
If the failing program is not invoked library-qualified, then the
alternate compiled into QTEMP can be tested for the same error; or if
similarly to the "new CL", that recompiled source also no longer exhibits
the problem. The dumps and\or disassembled listings of the two programs
could be compared for possible origin for a difference if the newer compile
no longer experiences the issue.
Prior to recently, it worked perfectly.
Seems that if somehow the CL compiler had ¿incorrectly? allowed the
The only thing that seems to have changed is that the file recently
exceeded 10 million records (5 days ago, the same day that the
errors started appearing).
Any ideas why this could be throwing this error CPF0819 and how to
program to be compiled with the variable declared as TYPE(*DEC) LEN(07 00)
[or smaller] would be a likely cause. That would be /correct/, only if the
invocation was [implicitly] compiled against *LIBL/RTVMBRD [for lack of the
request being specified without library-qualification] and there was a
version of the RTVMBRD allowing for the smaller declaration; or of course,
if the request is qualified to a version of the RTVMBRD request that has
smaller requirements defined for the Number Of Current Records (NBRCURRCD)
I am not sure what the definition of the command for the S/38
environment is, but the command RTVMBRD.QSYS38 may have that /shorter/
return variable size definition, such that a compile [e.g. as implied by
the source type CLP38] might impose that alternate limitation.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives