Error Occurred in SQL Call Level Interface CPYTOIMPF command

Kristi

unread,

Mar 7, 2008, 8:32:12 AM3/7/08

to

This is the Command:

CPYTOIMPF FROMFILE(LSPMPRDTA/LS600F) +

TOSTMF('\KWIKTAG\KWIKTAG.TXT') +

MBROPT(*REPLACE) STMFCODPAG(*PCASCII) +

RCDDLM(*CRLF) STRDLM(*NONE) FLDDLM(X'05')

When this is run in a nightly batch job, i get this error:

Message . . . . : CPF2817 received by LS600C at 2300. (C D I
R)

Cause . . . . . : Control language (CL) program LS600C in library
LSPMPROBJ

detected an error at statement number 2300. Message text for
CPF2817 is:

Copy command ended because of
error.

Error Occurred in SQL Call Level Interface

No records copied from file LS600F in LSPMPRDTA.

Copy command ended because of error.

Function check. CPF2817 unmonitored by LS600C at statement 2300

instruction X'0026'.

CPF2817 received by LS600C at 2300. (C D I R)

If i run this CL Program from a command line, i do not get any
errors.

Please Help.... Thank you,

Kristi Kittell

Karl Hanson

unread,

Mar 7, 2008, 10:15:11 AM3/7/08

to

You probably should contact your IBM Service provider, as there may be a
PTF that fixes the problem. It appears that CPYTOIMPF uses SQL CLI, and
message SQ99999 is unexpected. SQ99999 has a reason code (check the job
log), which may be of help in analyzing the problem when you report it,
and (perhaps) finding an existing fix.

===> dspmsgd SQ99999 qsqlmsg

--
Karl Hanson

Jonathan Ball

unread,

Mar 7, 2008, 10:26:16 AM3/7/08

to

That makes it seem as if it might be an authority
issue. The job might be running under a profile that
doesn't have authority to the IFS file or the database
file. Try changing the logging level of the batch job
to show more information.

CRPence

unread,

Mar 7, 2008, 10:30:22 AM3/7/08

to

In a job where a prior invocation was made to the CLI, the CPYTOIMPF
will not work; I think, unless the prior invocation of the CLI were done
with server mode. In earlier releases the only resolution was to change
the prior invocation, or when the prior invocation was done by vendor
code [i.e. code which is unable to be changed; including IBM code], then
the resolution is to submit the export activity in a different unit of
work. By v5r4 there may be some enhancements, if only for correcting
some uses of IBM code to ensure server-mode; e.g. by BRMS (performed
earlier in the same job).

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

Kristi wrote:
> This is the Command:

> CPYTOIMPF <<SNIP>>

>
> Error Occurred in SQL Call Level Interface
>

> <<SNIP>>
>
> If I run this CL Program from a command line, i do not get any errors.

jse...@yahoo.co.nz

unread,

Mar 10, 2008, 5:03:45 PM3/10/08

to

Couldn't make head nor tail out of what Chuck wrote (sorry Chuck)
however, I have experienced SQL failures with this command when run
after certain BRMS functions after migrating to V5R3. IBMs response
was that the CPYTOIMPF command had changed to use SQL and the SQL
errors I was receiving were a permanent restriction. Anyway, if your
CL program is issuing BRMS functions beforehand this is likely the
cause - if the CL program is no longer using BRMS functions, you can
reclaim the Q1ABRMS

jse...@yahoo.co.nz

unread,

Mar 10, 2008, 5:06:39 PM3/10/08

to

On Mar 8, 4:30 am, CRPence <crpe...@vnet.ibm.com> wrote:

OK, my last post got accidentally sent before completing/reviewing (no
idea what keyboard combination did that!) :-(
What I was going to say is you could reclaim the Q1ABRMS activation
group if the CL program is no longer using BRMS functions.

rpg4...@yahoo.com

unread,

Mar 11, 2008, 8:04:25 PM3/11/08

to

The user of the batch job needs authority to the SQL Create Alias sub-
command.
IBM changed CPYTOIMPF after V5R2 to bring us this "functionality"

Rico