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

Since I can't figure out why with one set of data it works and another set it doesn't
I'd like to try a different approach.

I had:
C MOVEL CmdA Command
C Eval CmdLength = %Len(%Trim(Command))
C Call 'QCMDEXC' 50
C parm cmda
C parm cmdlength
So it ran the cmd inside RPGLE
I change it to:
C MOVEL CmdA Command
C Eval CmdLength = %Len(%Trim(Command))
C Call 'runcmd' 50
C parm cmda
C parm cmdlength

Hopping it would call a CLLE program that looks like this:

PGM PARM(&CMD &cmdlen)
DCL VAR(&CMD) TYPE(*CHAR) LEN(254)
DCL VAR(&CMDlen) TYPE(*CHAR) LEN(4)

CALL PGM(QCMDEXEC) PARM(&CMD 254)
EndPgm

I'm getting an error saying:
Message ID . . . . . . : MCH3401 Severity . . . . . . . : 40
Message type . . . . . : Escape
Date sent . . . . . . : 04/06/13 Time sent . . . . . . : 20:03:31

Message . . . . : Cannot resolve to object runcmd. Type and Subtype X'0201'
Authority X'0000'.
Cause . . . . . : Either a system pointer or a data pointer can not be
resolved.
For a system pointer, it can not be resolved to object runcmd, type and
subtype X'0201', authorization X'0000', because either the named object was
not in any context referred to or the correct object was located but the
user profile did not have the required authority.
The object types for common type or subtype codes follow:
-- 0100-Access group, 0201-Program, 0401-Library,

The program runcmd is in the liblist with *Public *all

Any ideas why it can't find the CL pgm?

Thanks,

Gary

On 6 Apr 2013 at 16:54, Midrange (Gary Kuznitz <docfxit@xxxxxxxxxxxx>) commented
about Re: Data not getting written to /tm:

Thanks for looking this up.

Comments below...

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

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 ..."

More comments inline:

On 05 Apr 2013 21:17, 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.

Given the spooled joblog showing the message identifier and the
context, the reason for the file creation may be more obvious. Per only
the copied text of the message being given, no context for why it was
issued is possible other than a guess. However I recall in the old
implementation of the export, that the feature first output to a
temporary database file and then used CPYTOSTMF to effect the
translation of the text data according to the requirements of the
STMFCODPAG, and in that implementation, that the messages for the
temporary files were visible. However in a quick test on v5r3, I saw no
such messages. I do not recall if perhaps the v5r2 was the /old/
implementation.

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*

And then I get this error:
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.
Cause . . . . . : 1. You attempted to open a file for reading,
but the file does not exist. 2. You attempted to open a file for an
output operation, but the library does not exist. 3. You attempted to
close a file that is not open. 4. The open function ran out of
internal memory. Recovery . . . : 1. When you use fopen or freopen,
specific information on the exception message is contained in
_EXCP_MSGID declared in<stddef.h>. 2. When you use _Ropen, handle I/O
exceptions by specifying a signal handler for the SIGIO signal.
Technical description . : The value of errno is set to ENOTOPEN.

<<SNIP apparent completion message>>

I hope someone on the list will know why the error comes up. Maybe
that's why there aren't any records written to the Tmp folder.

I do expect that error 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.

Thanks for all the info.

Gary

--
Regards, Chuck