× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The CPYFRMIMPF uses the SQL CLI which may not _play nice_ with other applications using that feature. IIRC avoided only if every application uses 'server mode'? Anyhow look for prior SQL activity in the job [may not be obvious, except when running in debug] and review APAR= SE22682 for at least one specific case of colliding SQL CLI applications.

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

Peter Vidal wrote:
Hi list!

I have this error on a CLLE:

34400 - CPYFRMIMPF FROMFILE(QTEMP/TEMPFILE) TOFILE(GELCO_GLH) MBROPT(*REPLACE) RCDDLM(*ALL) DTAFMT(*DLM) STRDLM('"') RMVBLANK(*NONE) FLDDLM(',') RPLNULLVAL(*FLDDFT)
Ownership of object QCPIMTEMPS in QTEMP type *USRSPC changed.
Ownership of object QACPTEMP01 in QTEMP type *USRSPC changed.
Ownership of object QACPTEMP01 in QTEMP type *USRSPC changed.
Query options retrieved file QAQQINI in library QUSRSYS. Ownership of object QCFT572425 in QTEMP type *USRSPC changed.
Connection to relational database FL400 already exists. Error Occurred in SQL Call Level Interface Copy command ended because of error.
The message description says:

Additional Message Information Message ID . . . . . . : SQ99999 Severity . . . . . . . : 30 Message type . . . . . : Diagnostic Date sent . . . . . . : 05/30/07 Time sent . . . . . . : 11:48:49 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. -- Error type 12 is transaction operation state not valid. -- Error type 13 is memory management problem. -- Error type 14 is maximum number of handles allocated. -- Error type 15 is no cursor name available. -- Error type 16 is handle type for operation not valid.
-- Error type 17 is connection no longer available.
Recovery . . . : Refer to the DB2 UDB for iSeries SQL Call Level Interface topic in the Information Center book for a complete description of the error. Specifically, look under the procedure that sent the error.

I tried to check on the Info Center but I can't find any easy way out yet. I searched on the Internet looking for "SQ99999 CPYFRMIMPF" and I got just one hit and this looks like German to me.

Looks like is the feed but is weird because is the first time (after a year or so that the application is running) that I have this issue.
Any ideas of what might be happening?
TIA,


Peter Vidal PALL Corporation / SR Programmer Analyst, IT Development Group
10540 Ridge Rd., Ste 203, New Port Richey, FL 34654-5111
http://www.pall.com

"Nothing is a waste of time if you use the experience wisely."
Rodin (1840 - 1917)




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.