View previous topic :: View next topic |
Author |
Message |
anettis Beginner

Joined: 08 Nov 2004 Posts: 15 Topics: 5
|
Posted: Tue Jul 19, 2005 3:44 pm Post subject: COBOL and Dynamic SQL |
|
|
Hello. I wanted to get verification on the maximum length of text that can be passed as dynamic SQL to DB2 in a COBOL program. All examples I have come across use a length field defined as PIC S9(4) COMP, which seems to indicate a maximum supported length of 9,999 characters of text. Can anyone confirm this for me?
Thanks,
Tony |
|
Back to top |
|
 |
Cogito-Ergo-Sum Advanced
Joined: 15 Dec 2002 Posts: 637 Topics: 43 Location: Bengaluru, INDIA
|
Posted: Wed Jul 20, 2005 12:15 am Post subject: |
|
|
Tony,
Your question can be directly answered from the manual.
However, are you implying that S9(4) COMP will hold 9999 characters at the max? The data in a S9(4) COMP is held in binary. Thus, the highest value is when all the bits are on i.e. X'FFFF'. But, since the high order bit is used to hold the sign, the highest value would be X'7FFF' which is 32,767 in decimal. _________________ ALL opinions are welcome.
Debugging tip:
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
-- Sherlock Holmes. |
|
Back to top |
|
 |
anettis Beginner

Joined: 08 Nov 2004 Posts: 15 Topics: 5
|
Posted: Wed Jul 20, 2005 12:34 am Post subject: |
|
|
Well it sounds like you know the answer but didn't want to share . . . gee thanks. (I did look in the DB2 Application Programming and SQL Guide but did not come across any clear specification of the limits of the length field for dynamic SQL although it is certainly possible I missed it.)
As for your second remark you are incorrect. Theoretically a S9(4) COMP field can hold up to 32,767 but in practicality you cannot MOVE such a value into this field as COBOL will truncate the result down to 2767, which is logical since by specifying S9(4) you are telling the compiler you wish the field to be able to hold values in the range of 0001 - 9999 (positive or negative). |
|
Back to top |
|
 |
Cogito-Ergo-Sum Advanced
Joined: 15 Dec 2002 Posts: 637 Topics: 43 Location: Bengaluru, INDIA
|
Posted: Wed Jul 20, 2005 12:51 am Post subject: |
|
|
Quote: | Well it sounds like you know the answer but didn't want to share . . . gee thanks. |
No!!!
This is a new machine I am working with. I am yet to copy most of the manuals from my CD. Tony, I have answered a good deal of questions here and elsewhere. Please do not assume that, I wanted to hide the answer.
As for the S9(4) thing, please have a look at Example 2 here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igya1101/5.2.3.40?SHELF=&DT=19930312141355& _________________ ALL opinions are welcome.
Debugging tip:
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
-- Sherlock Holmes. |
|
Back to top |
|
 |
anettis Beginner

Joined: 08 Nov 2004 Posts: 15 Topics: 5
|
Posted: Wed Jul 20, 2005 1:17 am Post subject: |
|
|
OK - sorry if I jumped the gun. It sounded to me like you simply did not want to be forthcoming with an answer that you knew off the top of your head.
In any event it looks like what I said is correct when using TRUNC(STD) and sometimes when using TRUNC(OPT) (depending upon the code the compiler decides to generate). And what you said is correct when using TRUNC(BIN) and potentially TRUNC(OPT), again depending upon the code the compiler uses. Therefore the only time one could count on being able to always move 32767 into a PIC S9(4) COMP would be if the compler option TRUNC(BIN) was in effect.
So this leads me back to my original question with an added assumption - if we assume TRUNC(STD) or TRUNC(OPT) it appears to me that we are limited to passing 9,999 bytes to DB2 as dynamic SQL in a COBOL program. Can anyone confirm or deny? |
|
Back to top |
|
 |
|
|