Re: Data not getting written to /tmp

On 06 Apr 2013 16:54, Gary Kuznitz wrote:

On 5 Apr 2013 at 23:44, CRPence commented:

No mention of release was noted [that part of the joblog, along
with the message identifiers were omitted],

Sorry about that again. V4r4

but the following describes the /same/ symptom string assuming my
guess about the first MsgId is correct. The symptom string as I
would have written it:

msgC2M3004 F/QC2IO FM/QC2RIOC1 FP/_Ropen stmt/28
T/QCPEXPRT TM/QCPEXPRT TP/Check_tofile_parameter stmt/1130

The V5R3M0 APAR SE23148 has the symptom string quoted from the
following link:
http://www.ibm.com/support/docview.wss?uid=nas2131452d21aaf08d5862570bb004215ad
"OSP-DB-MSGC2M3004-F/QC2IO-T/QCPIMPRT FILE NOT OPENED ..."

<<SNIP>>

Note: in newer releases, there are data area objects with naming
QCP* that can be utilized to make the /old implementation/ of the
database import and export facility be invoked instead of properly
using the currently installed release-level of the features. Best
to ensure no such data area is on the system causing an issue.

I don't have any data area QCP*

<<SNIP>>

I do expect that error [<ed> described in the APAR] is the origin
for the issue, and that the export feature is failing to manifest
that error it receives as an indication that the overall copy
request failed; i.e. it sends a completion message [for its copy
activity], even though it had failed to export any data [into a
temporary file].

I have done some further testing. It works fine when I select the
same data that gets run every month. It must have something to do
with the data. So far I can't figure it out.

The data areas came into existence since v5r3, thus for v4r4 there is no relevance. Links to some KB articles in another reply, explain the details about the export\import features changing; applicable only if this export needs to be supported on later releases.

The APAR SE23148 shown for V5R3 was reported at v5r2, and the same issue likely existed since many releases before; i.e. probably is still an unaddressed problem with v4r4. A variant of that defect likely existed also in the export, just as with the import; the programs are likely [I recall they are] very similar, sharing code. That defect in the code is manifest with a nonsensical but fatal error; an error which supposedly persists once it is encountered for import. The correction for the defect, as described, is to be preventive for the condition which gave rise to the symptom, and corrective was to properly release storage that had been allocated. And although the problem alludes the origin is from invoking the import feature many times in a job, it is very possible that something as silly as a missing delimiter in a record of the /from/ file data might give rise to the same condition when using the import. It may be that, unlike for export, when the condition occurs in the import, the problem does not persist for any new import requests within the job. Or the condition may be specific to the invocation via the RPGLE due to the allocations being scoped to the activation group. Perhaps when run on the command line, thus running in the default activation group and without the user program in the stack, the failures to properly release the storage are merely by chance or specifically due to that type of activation, does not manifest itself with the same error.

But that is all really useless speculation. Whatever the issue, unless there is something obvious or at least something that can be eventually detected as /wrong/ with the /from/ file data, there is likely no simple resolution if the v4r4 CPYTOIMPF is a requirement. The release is long-since out of support, and so only changes you can make will be able to assist.

One possible change, for the new approach that was taken using a CLLE to invoke the export, perhaps making that program run in ACTGRP(*NEW) or making that a CLP instead of a CLLE could assist; i.e. have the request complete without the error, even if the underlying origin for the issue is specific to the data.