Re: Data not getting written to /tmp -- MIDRANGE-L

Another brilliant idea. Thanks.

Comments below...

On 5 Apr 2013 at 22:18, CRPence (CRPence <midrange-l@xxxxxxxxxxxx>) commented
about Re: Data not getting written to /tmp:

On 05 Apr 2013 21:28, Bradley Stone wrote:

Debug the program

Right after the command is built, eval it. Copy and past the command
that is run. This means the entire command with all the values
replaced, etc. The exact command that is run.

Paste it to a command line. Press enter. See what happens. That will
tell you what's going on.

A lot of times it is assumed you created the command right, but until
you debug it and see what's wrong you'll never know why the error is
happening

FWiW: In that specific scenario, the command could easily be forced
into prompting to find out what the command string looks like; with a
simple change and a re-compile... if the testing is performed
interactively. That is because it is a known, that the command gets
invoked, so the prompted command can be forced by preceding the CL
request with a question mark character. Thus when the prompted command
is presented, just use F14=Display Command String; that can be copied
and pasted outside of the program invocation to review the failure, as
suggested above.

Further comments inline below.

On Fri, Apr 5, 2013 at 11:17 PM, Gary Kuznitz wrote:

** I changed the Callp to Call 'QCMDEXC'
And I am getting more info in the joblog now.

I don't know why the system is creating this file in QTEMP

File QACP173785 created in library QTEMP.

And then I get this error:

Uhh... /this/ error is, although well defined in text and context,
does not offer the error *message identifier* , so searching for a
possible matching problem description is more difficult;

I'm very sorry I didn't provide the Message ID. I certainly didn't want to make it
difficult on anyone. The Message ID is C2M3004

esp. if another
occurrence that someone had and resolved was in a different language.
While I could [and often have] look up the message identifier from the
provided text... I am too lazy tonight to do so. This is also a message
sent to the export facility, so that could easily explain the effects
seen; i.e. the file was created but with no data... the file was
apparently created, but could not be opened. However why that error was
not manifest as an error to the requester of the CPYTOIMPF is not
obvious. As an I/O error, the expectation might be that the error level
and error record file specifications would come into play; but that is
an open error.

FWiW I would try another directory other than /tmp to eliminate the
possibility that the common restriction on that directory is the origin
for the difficulty.

40 04/05/13 19:11:17 QC2IO QSYS *STMT QCPEXPRT QSYS
From module . . . . . . . . : QC2RIOC1
From procedure . . . . . . : _Ropen
Statement . . . . . . . . . : 28
To module . . . . . . . . . : QCPEXPRT
To procedure . . . . . . . : Check_tofile_parameter
Statement . . . . . . . . . : 1130 *PRCLT
Message . . . . : File is not opened.
<<SNIP>>
On 4 Apr 2013 at 15:54, Gary wrote:

<<SNIP>> This is my code:
D Path s 11 Inz('/tmp/')
C Eval CMDA = 'CPYTOIMPF ' + <<SNIP>>

The code change described above [add "?" as prompt character]:

D Path s 11 Inz('/tmp/')
C Eval CMDA = '? CPYTOIMPF ' + <<SNIP>>

It's been a lot of years since I learned that in class. I didn't think of using it. Thanks
for the great idea.

--
Regards, Chuck

Thank you for looking at and giving me suggestions on this problem.

Gary