CPYTOIMPF from UBE works locally but not on server

[HolderAndrew]

Hello All,

I think this is a nice one for the iseries expert (not me!)

We are trying to copy data from an E1 (or Xe) table to the IFS via the following command which is submitted from ER inside a UBE:

CPYTOIMPF FROMFILE(Libname/File1) TOSTMF('/Folder1/Filenam') MBROPT(*ADD) STMFCODPAG(1257) RCDDLM(*LF) STRDLM(*NONE)

If the UBE is running locally on dev client then command works ok. If the UBE runs on the server (iseries) then the command does not work. Unfortunately in the debug log I cannot see any details of why this is not working.

If we issue a different command such as:
CPYF FROMFILE(Libname/File1) TOFILE(Libname2/Filenam) TOMBR(Filenam) MBROPT(*ADD) CRTFILE(*YES)

then this works ok everywhere (local or on server) The problem with the CPYTOIMPF command exists both within our E1 8.11 TR 8.95_O1 and on our OneWorld Xe SP23 systems both running V5R3 on iseries, so I guess that the problem is OS/400 related and not E1/Xe?

[Btw-The commands are issued from a custom BSFN which is mapped to always run serverside on OCM. We only get back a 'success' or 'error' message if the command works or not.]


So, it seems that the CPYTOIMPF has some restrictions when running on the server? The userid in Xe on serverside is JDE (or ONEWORLD) and I have checked that the authorites on the 'Fromfile' are ok (ie. *ALL). I have also checked that the permissions on the IFS target are ok for all the userids that I can possibly think of!

We have reviewed APARS and associated PTFs concerning the CPYTOIMPF command as recommended on IBM site and everything looks ok.

Here is a description of the CPYTOIMPF:


Command . . . . . . . : CPYTOIMPF Library . . . . . . . : QSYS
Program to process . . . . . . :QCPEXPRT
Library . . . . . . . . . . . . . . : QSYS
State used to call program . . . . . : *SYSTEM
Validity checking program . . . . . . : *NONE
Mode(s) in which valid . . . . . . . . :*PROD *DEBUG *SERVICE
Where allowed to run . . . . . . . . . : *IMOD *BMOD *IREXX *BREXX *BPGM *IPGM *EXEC *INTERACT *BATCH
Allow limited user . . . . . . . . . . : *NO
Maximum positional parameters . . . . :3

We would be extremely grateful if somebody could offer some advice of solving this problem or perhaps offering an alternative solution.

Regards

Andrew

 

[Null Value]

Andrew,

Maybe re-posting your queries to the 'World Discussions' section of JDELIST will help.

Experts of both worlds (E1 and World) rarely visit other's domains

Regards,

Shailesh

 

[rcoxon]

Dear Andrew,

I have made extensive use of the CPYTOIMPF command on an iSeries Enterprise Server, called from a UBE via ER.

First things:
1) Have you built a package and deployed the UBE to the Server?
2) Are you using the ExecuteExternalProgram (B34A1030) BSFN?

If the answer is yes, here are a couple of things I have found:
1) Make sure you can execute the command from an iSeries Command Line (Green Screen) using the same UserID, same from FROMFILE and TOSTMF and other options. Especially effective if you can cut and paste the command from the UBE to the Command Line. If this does not work, it will not work from the UBE.
2) Run the UBE on the server and do a CHGJOB on the iSeries job that is running it to LOG the TEXT "*SECLVL" and LOGCLPGM = "*YES". This will show you the error occurring on the Call to CPYTOIMPF.

Message logging:
Level . . . . . . . . . . . . 4
Severity . . . . . . . . . . . 00
Text . . . . . . . . . . . . . *SECLVL
Log CL program commands . . . . *YES

3) One problem I ran into was the length of the parameter for the TOSTMF. It is 50 characters long, and if I called the CPYTOIMPF as you do:
CPYTOIMPF FROMFILE(Libname/File1) TOSTMF('/Folder1/Filenam') MBROPT(*ADD) STMFCODPAG(1257) RCDDLM(*LF) STRDLM(*NONE)
I would get errors where the TOSTMF had been parsed as:
“'/Folder1/Filenam') MBROPT(*ADD) STMFCODPAG(1257) “
or something similar. I don’t know why, it is just what the Logging of the CL would show.
4) I resolved this by writing a CL Program that was called from the UBE ERs via the ‘ExecuteExternalProgram’ BSFN and passed in the parameters, which were then used inside the CL program to execute the CPYTOIMPF.

If you need further clarification, let me know.

Sincerely,

Roger
ConsultCoxon.com

 

[HolderAndrew]

Hi Roger,

many thanks for the reply.

Yes, I can cut and paste the CPYTOIMPF command from debug session into green screen and it works ok when signed on as myself, JDE or with ONEWORLD userid. As I mentioned we are using a custom BSFN to do the external calls, something that we have used in OW for 8 years now without any problems.

I switched on logging on a scheduled job running the UBE and got some (as you say) weird messages which I am not sure if I can decipher, such as:


SQ99999 Diagnostic 30 23/10/06 09:52:28.996760 QSQCLI QSYS *STMT QCPEXPRT QSYS *STMT
From module . . . . . . . . : SQLSEA
From procedure . . . . . . : SQLSetEnvAttr
Statement . . . . . . . . . : 5467
To module . . . . . . . . . : QCPEXPRT
To procedure . . . . . . . : Copy_The_Records
Statement . . . . . . . . . : 122
Message . . . . : Error Occurred in SQL Call Level Interface
Cause . . . . . : You have issued a procedure call that encountered an
error. The error code is 10. Error codes are as follows: -- Error type 3 is
program type out of range. -- Error type 4 is SQL data type out of range. --
Error type 9 is argument value not valid. -- Error type 10 is function
sequence error.


We do make use of CL calls from time to time and so I can use this method if I have to. I will look into the error messages in more detail later.

Thanks again.

Andrew