×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
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
correct?
Seems that if somehow the CL compiler had ¿incorrectly? allowed the
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) parameter.
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.
midrange.com
