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; 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>>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.