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



Jim,

The system's telling you the problem. I'm guessing you've got a data record somewhere with a bad
value in BRQDVA. Look for a prior message in the job log that tells you which record.

Or add some code in your program to tell you the last record you got successfully.

STRSQL may be working because it hadn't hit the bad record yet, unless you've paged through all the
records.

HTH,
Charles


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Essinger
Sent: Friday, August 17, 2007 12:29 AM
To: Midrange Systems Technical Discussion
Subject: SQL Statement failing in COBOL program

I asked this in the WDSc list, but none of the responses
helped me find the problem. I have the following statement;

Exec SQL
Declare LTRC1 cursor for
with t1 as (Select distinct lnbss, lnbond
from slsfiles/sllnrep
WHERE lnlsts < "P90" )
select
Distinct ZIP_CODE,
PLUS_FOUR,
CAR_RTE_CD,
CAR_RTE_CD,
PLUS_SIX,
PAGE_INFO,
ADDR_LINE1,
ADDR_LINE2,
ADDR_LINE3,
ADDR_LINE4,
BORR_NAME,
BORR_SSN,
RTN_CODES,
LNBOND
from BCTEST/BCSRREP,
SLSFILES/SLBRREP Join T1 on BrBSS = LNBSS
WHERE Dec(BORR_SSN,9,0) = Dec(BRQDVA *100,9,0)
Order by LnBond, Zip_Code
END-EXEC

The select statement works in STRSQL and selects the records
I want to process. When I run it in the program, the open
cursor statement completes normally, but the fetch gets me a
SQLSTATE of 22018 with a SQLCODE of -420.
The code book says;

"The character value for the CAST, DECIMAL, FLOAT, or INTEGER
scalar function is invalid."

Every column selected is alpha except the LNBOND which is a
packed decimal 3 long in the file. I have the receiving
field for the LNBOND field set as a Signed Packed Decimal 3
long. BRQDVA in the "WHERE" clause is a number in
9,999,999.99 format, and so to compare with the account
number (not really SSN, but was at one time) I have to move
decimal to the right like 999,999,999. The BORR_SSN is
actually a number, just stored as character.

This statement happens to be in ILE COBOL SQL, but the
question is more SQL based then program based. Also I know
that in this example, taken from the program the constant
'P90' has double quotes, required by COBOL, and not single as
required by STRSQL.

I'm not sure what I am being told by the message.

Any thoughts/Help?

Thanks!

Jim
--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.




This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.