DB2 to COBOL translation
Gonzo
I was given a DB2 layout without the benefit of a DCLGEN translation, and
I've got field definition of DECIMAL(22,7). How would you change this to a
COBOL PIC? I'm working with COBOL OS/390, and according to the doc I have,
the rule is supposed to be:
DECIMAL(p,s) -> PIC S9(p-s)V9(s) COMP-3.
As I plug it in, I obviously get PIC S9(15)V9(7) COMP-3. My maximum length
for COMP-3 fields is 18 digit positions, and I bust that by 4 positions.
I was just going to pad the first two bytes as filler and handle the excess
in the procedure division, but I was hoping someone might have another idea
at hand.
--
Gonzo - yes, the one with the curly nose...
Remove '.nospam' in address for email
Harley
"Gonzo" <ckhamel19...@yahoo.com> wrote in message
news:%r18b.88$iT5...@newssvr24.news.prodigy.com...
| Hi folks,
|
| I was given a DB2 layout without the benefit of a DCLGEN translation, and
| I've got field definition of DECIMAL(22,7). How would you change this to a
| COBOL PIC? I'm working with COBOL OS/390, and according to the doc I have,
| the rule is supposed to be:
|
| DECIMAL(p,s) -> PIC S9(p-s)V9(s) COMP-3.
|
| As I plug it in, I obviously get PIC S9(15)V9(7) COMP-3. My maximum length
| for COMP-3 fields is 18 digit positions, and I bust that by 4 positions.
|
| I was just going to pad the first two bytes as filler and handle the
excess
| in the procedure division, but I was hoping someone might have another
idea
| at hand.
Operating system, compiler & version would be helpful.
Harley
do you have ARITH(EXTEND) in your manual?
"Gonzo" <ckhamel19...@yahoo.com> wrote in message
news:%r18b.88$iT5...@newssvr24.news.prodigy.com...
Gonzo
Sorry, ARITH is not available to me on this version. Sounds like just what I
needed, tho...
> "Gonzo" <ckhamel19...@yahoo.com> wrote:
> | I'm working with COBOL OS/390, <snip>
Pardon me, I get a little too focused sometimes....
I'm working with IBM COBOL for MVS & VM 1.2.2, operating on an IBM OS/390
MVS system.
William M. Klein
people WHY they have upgraded to a version of DB2 that supports 31-digit
numeric fields but have NOT updated your COBOL to such a release.
--
Bill Klein
wmklein <at> ix.netcom.com
"Gonzo" <ckhamel19...@yahoo.com> wrote in message
news:o0l8b.283$rS3...@newssvr24.news.prodigy.com...
Don Leahy
convert it to character. Then you can fetch the column into a PIC
X(whatever) field.
EXEC SQL
SELECT DIGITS(DECIMAL_COL)
FROM some_table
INTO :WS-CHAR-FIELD
END-EXEC
"Gonzo" <ckhamel19...@yahoo.com> wrote in message
news:%r18b.88$iT5...@newssvr24.news.prodigy.com...
Gonzo
"William M. Klein" <wmk...@nospam.netcom.com> wrote:
> Then you are out of luck, <snip>
Yep, Bill... fortunately just OOL and not SOL.... for the moment. Writing
specs for a conversion, and right now it's just a straight move. Hopefully
it'll stay that way, otherwise I'm in for some extra coding.
Contracting means you take what they give ya.... 'tis a good question,
though, why they haven't updated their compiler. My client is so big I doubt
I'd ever find the right person to ask in the timeframe I have, much less do
anything about it.
Gonzo
jce
Depending on what they do, this could be an auditable business exposure. You
could always tell them to call IBM for help to support this and get IBM to
tell them they need to upgrade :-)
JCE
jce
data definition?
If the fields are all 15,5 then you could do similar and try casting to a
DECIMAL(15,5) in the same manner as this DIGITS select only it leaves the
same value.
Of course if you are doing math with the numbers and they are big (ie.
adding) there is always the chance that you will still exceed the internal
storage anyway. In this case the DIGITS scalar f. works well because you
can store the lod and rod separately....
It wouldn't be the first time that a DBA and application guy didn't talk.
JCE
"Don Leahy" <dle...@rogers.com> wrote in message
news:1Tp8b.4160$Nx6.6...@news20.bellglobal.com...