Re: Data not getting written to /tmp

Chuck, Thank you very much for all the information you discovered.

I found a solution to the problem.

I discovered that reducing the number of characters in TOSTMF for a file name solved
the issue. The program has been running for years with the file name being 41
characters. For this application the number of characters changes depending on how
many characters are in a persons name. This person was printing just fine when the
entire list was printed. This person does have a long name. (I shortened it for this list)
For some reason when a subset of the list was printed and it started with this name it
wouldn't write any records to the file. When I shortend the number of characters in
the TOSTMF file name to 17 it started printing all files. It could easily be that the
number of characters can be larger than 17. I just chose that at random.

Thank you all for your help.

Gary

CPYTOIMPF FROMFILE(ENVELOPE) TOSTMF('/tmp/ALEXANDER.xml')
MBROPT(*REPLACE) TOCCSID(437) RCDDLM(*CRLF)

DTAFMT(*FIXED)


On 7 Apr 2013 at 9:53, CRPence (CRPence <midrange-l@xxxxxxxxxxxx>) commented
about Re: Data not getting written to /tm:

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.

--
Regards, Chuck