| Author |
Fill a comp-3 variable
|
|
| jferreira80@gmail.com 2006-07-24, 7:55 am |
| Hi...just a hand-pocket question...... :)
i have a variable
01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
and i need to fill all the fields with value 9 .
I don't know why but if i defines de variable as
01 ws-con-variable1 PIC 9(13)V9(02) COMP-3 VALUE ALL 9.
it doesn't work...
any clue ?
Cheers
| |
| Michael Mattias 2006-07-24, 6:55 pm |
| <jferreira80@gmail.com> wrote in message
news:1153749015.404152.23700@m79g2000cwm.googlegroups.com...
> Hi...just a hand-pocket question...... :)
>
> i have a variable
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
>
> and i need to fill all the fields with value 9 .
>
> I don't know why but if i defines de variable as
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3 VALUE ALL 9.
>
> it doesn't work...
>
> any clue ?
VALUE "ALL <anything>" is (was?) only allowed for character (PIC X(n) or
A(n)) data items.
| |
| HeyBub 2006-07-24, 6:55 pm |
| jferreira80@gmail.com wrote:
> Hi...just a hand-pocket question...... :)
>
> i have a variable
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
>
> and i need to fill all the fields with value 9 .
>
> I don't know why but if i defines de variable as
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3 VALUE ALL 9.
>
> it doesn't work...
"ALL" works only on alphanumeric fields. You need:
PIC 9(13)V9(02) VALUE 9999999999999.99.
| |
| jferreira80@gmail.com 2006-07-24, 6:55 pm |
|
HeyBub escreveu:
> jferreira80@gmail.com wrote:
>
> "ALL" works only on alphanumeric fields. You need:
>
> PIC 9(13)V9(02) VALUE 9999999999999.99.
Ok.....
but if your variable as 99 fields, like
01 ws-con-variable1 PIC 9(99)v9(02) COMP-3.
you don't define the value as 999.......999
any clues for this problem??
cheers
| |
| Donald Tees 2006-07-24, 6:55 pm |
| jferreira80@gmail.com wrote:
> HeyBub escreveu:
>
> Ok.....
>
> but if your variable as 99 fields, like
>
> 01 ws-con-variable1 PIC 9(99)v9(02) COMP-3.
>
> you don't define the value as 999.......999
>
>
> any clues for this problem??
>
>
> cheers
>
There are no such fields, by definition.
Donald
| |
| William M. Klein 2006-07-24, 6:55 pm |
| Not (probably) a solution for this poster, but for those interested in this type
of problem, check out the '02 Standard
Highest-Algebraic
Intrinsic Function. Also interesting is how that works compared to
Lowest-Algebraic
for fields like this with no "S" in the Pic.
--
Bill Klein
wmklein <at> ix.netcom.com
<jferreira80@gmail.com> wrote in message
news:1153749015.404152.23700@m79g2000cwm.googlegroups.com...
> Hi...just a hand-pocket question...... :)
>
> i have a variable
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
>
> and i need to fill all the fields with value 9 .
>
> I don't know why but if i defines de variable as
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3 VALUE ALL 9.
>
> it doesn't work...
>
> any clue ?
>
>
>
> Cheers
>
| |
| HeyBub 2006-07-24, 6:55 pm |
| jferreira80@gmail.com wrote:
> HeyBub escreveu:
>
>
> Ok.....
>
> but if your variable as 99 fields, like
>
> 01 ws-con-variable1 PIC 9(99)v9(02) COMP-3.
>
> you don't define the value as 999.......999
>
>
> any clues for this problem??
What do you mean "you don't define the value as 999....999"? Are you
absolutely certain of that? It's not wise to venture an opinion whether
something is or is not possible when you, yourself, don't know how to do it.
That said, COBOL doesn't permit numeric fields that big. And if COBOL did
allow fields that big you DO define the initial value exactly as before
(except for more digits, of course).
Just what are you trying to do anyway?
| |
| jferreira80@gmail.com 2006-07-25, 3:55 am |
| i reformulated my question....
i have a variable
01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
and i need that the initial value is all the fiels filled with nines.
i see the one solution is to use
PIC 9(13)V9(02) VALUE 9999999999999.99.
but my question is when we got to fill this kind of variable with
larger fields.
even that cobol don't allow numerics fields so big, i think there is a
better solution than define the value with all the nines.
cheers...
HeyBub escreveu:
> jferreira80@gmail.com wrote:
>
> What do you mean "you don't define the value as 999....999"? Are you
> absolutely certain of that? It's not wise to venture an opinion whether
> something is or is not possible when you, yourself, don't know how to do it.
>
>
> That said, COBOL doesn't permit numeric fields that big. And if COBOL did
> allow fields that big you DO define the initial value exactly as before
> (except for more digits, of course).
>
> Just what are you trying to do anyway?
| |
|
| In article <1153816428.234711.246510@p79g2000cwp.googlegroups.com>,
<jferreira80@gmail.com> wrote:
>i reformulated my question....
>
>i have a variable
>
>01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
>
>and i need that the initial value is all the fiels filled with nines.
The processing requirement - or 'job' - that generates this need is...
what, pray tell?
>i see the one solution is to use
>
>PIC 9(13)V9(02) VALUE 9999999999999.99.
>
>but my question is when we got to fill this kind of variable with
>larger fields.
>even that cobol don't allow numerics fields so big, i think there is a
>better solution than define the value with all the nines.
This is what caused me to ask the previous question. You want to do
something for fields so large 'even that cobol don't allow numerics fields
so big' - never mind the facts about what the latest versions do or don't
allow - because your processing needs are... what?
DD
| |
| Michael Mattias 2006-07-25, 7:55 am |
| <jferreira80@gmail.com> wrote in message
news:1153816428.234711.246510@p79g2000cwp.googlegroups.com...
> i reformulated my question....
>
> i have a variable
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
>
> and i need that the initial value is all the fiels filled with nines.
> i see the one solution is to use
>
> PIC 9(13)V9(02) VALUE 9999999999999.99.
>
> but my question is when we got to fill this kind of variable with
> larger fields.
> even that cobol don't allow numerics fields so big, i think there is a
> better solution than define the value with all the nines.
Yes, there is a better solution. Don't even try to initialize the field
with a VALUE clause. Write appropriate code at the appropriate point in the
procedure dovision instead.
While I consider myself a fairly imaginative guy, seems to me initializing a
numeric *variable* (and "ws-con-variable1" sure sounds like a *variable*
rather than a *constant* ) to anything other than zero is silly.
Not to mention, "all nines" is a silly initial value for a numeric as it is
totally meaningless and useless.
MCM
| |
| HeyBub 2006-07-25, 6:55 pm |
| jferreira80@gmail.com wrote:
> i reformulated my question....
>
> i have a variable
>
> 01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
>
> and i need that the initial value is all the fiels filled with nines.
> i see the one solution is to use
>
> PIC 9(13)V9(02) VALUE 9999999999999.99.
>
> but my question is when we got to fill this kind of variable with
> larger fields.
> even that cobol don't allow numerics fields so big, i think there is a
> better solution than define the value with all the nines.
>
Okay, if you think there's a better solution, pray tell us what it is. As of
now, four people have told you there is one and only one way to initialize a
COMP-3 field to all 9s. We four have, conservatively, over 150 man-years of
collective COBOL programming experience. I, myself, teach COBOL at the
university level. Others have literally "written the book" on COBOL, and
some have even read the book.
In addition, many others have read your question and not seen fit to
respond, probably because they don't have an answer either.
If there is such a mechanism, we've never seen it or heard of it. Don't
count on a more economical way of initializing COMP-3 fields or it'll break
your heart.
As an aside, current practice (at least here) is to avoid COMP-3 fields; the
confusion and problems they generate are no longer offset by their
efficiency of storage or computational speed.
| |
| Howard Brazee 2006-07-25, 6:55 pm |
| On Tue, 25 Jul 2006 21:19:09 +0200, Jürgen Vetter <vetter@dokom.net>
wrote:
>
>Do you know any compiler which can work with
>more than pic 9(18)?
I don't , but I'm curious - is there any architecture which can handle
this?
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
| |
| William M. Klein 2006-07-25, 6:55 pm |
| "Jürgen Vetter" <vetter@dokom.net> wrote in message
news:44c68b1e$1@news.knipp.de...
> Am 24.07.2006 16:34 schrieb jferreira80@gmail.com:
<snip>
> Do you know any compiler which can work with
> more than pic 9(18)?
>
IBM has supported 31-digit numeric fields for several years now - in accordance
with the '02 COBOL Standard. I believe that Micro Focus already does as well,
probably several others as well.
As I recall (and this is memory only) there was one vendor supporting 100+ digit
numeric fields but NOT floating point MANY years ago.
Bottom-Line:
If using LARGE numeric fields, do look at the HIGHEST-/Lowest-Algebraic
intrinsic functions. I am not certain which vendors currently support them, but
they really do work for such fields.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Joe Zitzelberger 2006-07-25, 6:55 pm |
| In article <utscc2dvjtvld54ubt93792n7q29jph82l@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
> On Tue, 25 Jul 2006 21:19:09 +0200, Jürgen Vetter <vetter@dokom.net>
> wrote:
>
>
> I don't , but I'm curious - is there any architecture which can handle
> this?
JVMs can.
| |
| Howard Brazee 2006-07-26, 6:55 pm |
| On Tue, 25 Jul 2006 19:42:21 -0400, Joe Zitzelberger
<zberger@knology.net> wrote:
>
>JVMs can.
COMP-3?
| |
| Roger While 2006-07-26, 6:55 pm |
| AKA. PACKED-DECIMAL.
Roger
"Howard Brazee" <howard@brazee.net> schrieb im Newsbeitrag
news:trtec2hhk546vj8tnh6mbv0poksrr3cms0@
4ax.com...
> On Tue, 25 Jul 2006 19:42:21 -0400, Joe Zitzelberger
> <zberger@knology.net> wrote:
>
>
> COMP-3?
| |
| Michael Mattias 2006-07-26, 6:55 pm |
| "Roger While" <simrw@sim-basis.de> wrote in message
news:ea7tsg$1rh$03$1@news.t-online.com...
>
> AKA. PACKED-DECIMAL.
Remember, COMP-3 is 'implementor-defined' so blanket statements about 'how
to fill' these data items are a tad iffy and should always be conditioned on
something...like the O/S and/or specific compiler....
MCM
| |
| William M. Klein 2006-07-26, 6:55 pm |
| IBM can handle this (COMP-3 or Packed-Decimal) items up to 31-digits - with
Enterprise COBOL on z/OS.
http://publibz.boulder.ibm.com/cgi-.../igy3pg31/2.4.5
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:r6Lxg.75679$Lm5.58228@newssvr12.news.prodigy.com...
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:ea7tsg$1rh$03$1@news.t-online.com...
>
>
> Remember, COMP-3 is 'implementor-defined' so blanket statements about 'how
> to fill' these data items are a tad iffy and should always be conditioned on
> something...like the O/S and/or specific compiler....
>
> MCM
>
>
>
| |
| Roger While 2006-07-26, 6:55 pm |
| And OpenCOBOL upto 36 with all numeric field types except binary :-)
(And binary is on the way)
Incidentally Bill, now you can promote our
"BINARY-HUGE", better BINARY-LONG-LONG :-)
Roger
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:obLxg.123271$vu2.19499@fe05.news.easynews.com...
> IBM can handle this (COMP-3 or Packed-Decimal) items up to 31-digits -
> with Enterprise COBOL on z/OS.
>
> http://publibz.boulder.ibm.com/cgi-.../igy3pg31/2.4.5
>
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Michael Mattias" <michael.mattias@gte.net> wrote in message
> news:r6Lxg.75679$Lm5.58228@newssvr12.news.prodigy.com...
>
>
| |
| Howard Brazee 2006-07-26, 6:55 pm |
| On Wed, 26 Jul 2006 14:42:29 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>IBM can handle this (COMP-3 or Packed-Decimal) items up to 31-digits - with
>Enterprise COBOL on z/OS.
Which is less than a third of
01 ws-con-variable1 PIC 9(99)v9(02) COMP-3.
I was not familiar with any other implementations of COMP-3, and
haven't worked with CoBOL with a JVM. I haven't even worked with
packed fields with Java.
But it makes sense that a JVM wouldn't be limited to the hardware
architecture. I've been a proponent of a LARGE data type that is
virtually unlimited in size - that would be implementer designed - if
I say PIC 9(99)V9(02) LARGE. The implementer can decide how to store
it.
| |
| Roger While 2006-07-26, 6:55 pm |
| Well, do you want to store a magnitude googol or even a googolplex ?
Cobol is a business language, I don't think we have need for these
magnitudes !
(Consider what these numbers count -
number of atoms in the earth ? number of atoms in the universe ? -
- research!)
Roger
"Howard Brazee" <howard@brazee.net> schrieb im Newsbeitrag
news:1c1fc21cv66lvkeqouhtok0cth8lbthtkq@
4ax.com...
> On Wed, 26 Jul 2006 14:42:29 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
>
> Which is less than a third of
> 01 ws-con-variable1 PIC 9(99)v9(02) COMP-3.
>
> I was not familiar with any other implementations of COMP-3, and
> haven't worked with CoBOL with a JVM. I haven't even worked with
> packed fields with Java.
>
> But it makes sense that a JVM wouldn't be limited to the hardware
> architecture. I've been a proponent of a LARGE data type that is
> virtually unlimited in size - that would be implementer designed - if
> I say PIC 9(99)V9(02) LARGE. The implementer can decide how to store
> it.
| |
| Roger While 2006-07-26, 6:55 pm |
| He-he, when BG approaches 18 digits then the world has a problem :-)
Roger
"Jürgen Vetter" <vetter@dokom.net> schrieb im Newsbeitrag
news:44c7b2af$1@news.knipp.de...
> Am 26.07.2006 17:26 schrieb Roger While:
>
> maybe you have to count bill gates salary :->
| |
| Howard Brazee 2006-07-26, 6:55 pm |
| On Wed, 26 Jul 2006 18:20:11 +0200, Jürgen Vetter <vetter@dokom.net>
wrote:
>
>maybe you have to count bill gates salary :->
I don't believe his salary is extraordinary. He doesn't need a high
salary when he owns so much of the company.
| |
| Alistair 2006-07-26, 6:55 pm |
|
Roger While wrote:
> Well, do you want to store a magnitude googol or even a googolplex ?
> Cobol is a business language, I don't think we have need for these
> magnitudes !
> (Consider what these numbers count -
> number of atoms in the earth ? number of atoms in the universe ? -
> - research!)
The number of times that the universe has run through to completion, so
far?
| |
| William M. Klein 2006-07-26, 6:55 pm |
| Sorry Howard,
I must have missed when this thread got to:
Pic 9(99)
(I was just thinking of "bigger than 18")
I do believe (as stated earlier) that one older COBOL *could* handle Pic
9(100) - but I don't remember which one (and certainly don't remember if it
supported either Comp-3 or Packed-Decimal.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:1c1fc21cv66lvkeqouhtok0cth8lbthtkq@
4ax.com...
> On Wed, 26 Jul 2006 14:42:29 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
>
> Which is less than a third of
> 01 ws-con-variable1 PIC 9(99)v9(02) COMP-3.
>
> I was not familiar with any other implementations of COMP-3, and
> haven't worked with CoBOL with a JVM. I haven't even worked with
> packed fields with Java.
>
> But it makes sense that a JVM wouldn't be limited to the hardware
> architecture. I've been a proponent of a LARGE data type that is
> virtually unlimited in size - that would be implementer designed - if
> I say PIC 9(99)V9(02) LARGE. The implementer can decide how to store
> it.
| |
| HeyBub 2006-07-26, 6:55 pm |
| Jürgen Vetter wrote:
> Am 26.07.2006 17:26 schrieb Roger While:
>
> maybe you have to count bill gates salary :->
Bill Gates annual salary is a mere $865,114. By corporate standards, he is
significantly underpaid.
Gates, being mindful of the great position of trust invested in him, tries
to keep his salary at a reasonable multiple (say, 4 times that of) the
president.
| |
| Richard 2006-07-26, 6:55 pm |
|
HeyBub wrote:
> Bill Gates annual salary is a mere $865,114. By corporate standards, he is
> significantly underpaid.
I am sure that it is arranged by wizards to minimise his tax bills.
> Gates, being mindful of the great position of trust invested in him, tries
> to keep his salary at a reasonable multiple (say, 4 times that of) the
> president.
That is not to say that he considers himself to be as low as only 4
times as important as the president.
| |
| Michael Mattias 2006-07-26, 6:55 pm |
| "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12cfgta8nhfn89b@news.supernews.com...
>Bill Gates annual salary is a mere $865,114. By corporate standards, he is
>significantly underpaid.
> Gates, being mindful of the great position of trust invested in him, tries
> to keep his salary at a reasonable multiple (say, 4 times that of) the
> president.
If you mean president of the USA, 865K is merely a little over twice the
$400K salary which went into effect for president of US I think in '01.
MCM
| |
| HeyBub 2006-07-26, 9:55 pm |
| Michael Mattias wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:12cfgta8nhfn89b@news.supernews.com...
>
>
>
> If you mean president of the USA, 865K is merely a little over twice
> the $400K salary which went into effect for president of US I think
> in '01.
>
Ooooh! Thanks. I'm a bit behind the times.
Still, all is relative. The president's salary in 1909 ($75,000) was really
$1,607,000 in current dollars.
According to Wikipedia.
| |
| Joe Zitzelberger 2006-07-28, 7:55 am |
| In article <trtec2hhk546vj8tnh6mbv0poksrr3cms0@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
> On Tue, 25 Jul 2006 19:42:21 -0400, Joe Zitzelberger
> <zberger@knology.net> wrote:
>
>
> COMP-3?
No, big decimals -- Pic 9(99)v9(02). The internal representation of the
data is not relevant.
| |
| Howard Brazee 2006-07-28, 7:55 am |
| On Fri, 28 Jul 2006 08:23:38 -0400, Joe Zitzelberger
<zberger@knology.net> wrote:
>
>No, big decimals -- Pic 9(99)v9(02). The internal representation of the
>data is not relevant.
The internal representation is what architecture is about.
| |
| Roger While 2006-07-28, 6:55 pm |
| In fact, OpenCOBOL could potentially deal with
pic 9(99), pic 9(999), ... (with/without COMP-3 AKA PACKED-DECIMAL)
As OpenCOBOL uses GMP, theoretically there is
no limit (See GMP home page) except machine/compiler
limits.
However, who needs this? :-)
Roger
"Howard Brazee" <howard@brazee.net> schrieb im Newsbeitrag
news:7o5kc2pskufpnbvhsvg7q2c8g31s439aig@
4ax.com...
> On Fri, 28 Jul 2006 08:23:38 -0400, Joe Zitzelberger
> <zberger@knology.net> wrote:
>
handle[color=darkred]
>
> The internal representation is what architecture is about.
| |
|
| In article <1153749015.404152.23700@m79g2000cwm.googlegroups.com>,
<jferreira80@gmail.com> wrote:
>Hi...just a hand-pocket question...... :)
>
>i have a variable
>
>01 ws-con-variable1 PIC 9(13)V9(02) COMP-3.
>
>and i need to fill all the fields with value 9 .
[snip]
Well, it's been long enough so that this assignment should have been dealt
with... so it's time for another example of 'Kids, Don't Try This At
Home!' code. Given the platform of Big Blue Iron and the compiler of IBM
Enterprise COBOL for z/OS and OS/390 3.2.1 then how about...
01 PACKED-DEC PIC S9(13)V99 COMP-3 VALUE +0.
01 BIGGEST-PD-X-COMP3.
05 FILLER PIC X(09) VALUE ALL X'99'.
05 FILLER PIC X(01) VALUE X'9C'.
01 BIGGEST-PD-X REDEFINES BIGGEST-PD-X-COMP3
PIC S9(16)V99 COMP-3.
01 DISPLAY-Z PIC Z(15)9.99+ VALUE ZEROES.
....
PROCEDURE DIVISION.
MOVE BIGGEST-PD-X TO PACKED-DEC.
MOVE PACKED-DEC TO DISPLAY-Z.
.... or a reasonable facsimile thereof.
DD
| |
|
| docdwarf@panix.com () wrote:
>Well, it's been long enough so that this assignment should have been dealt
>with... so it's time for another example of 'Kids, Don't Try This At
>Home!' code. Given the platform of Big Blue Iron and the compiler of IBM
>Enterprise COBOL for z/OS and OS/390 3.2.1 then how about...
>
>01 PACKED-DEC PIC S9(13)V99 COMP-3 VALUE +0.
>01 BIGGEST-PD-X-COMP3.
> 05 FILLER PIC X(09) VALUE ALL X'99'.
> 05 FILLER PIC X(01) VALUE X'9C'.
>01 BIGGEST-PD-X REDEFINES BIGGEST-PD-X-COMP3
> PIC S9(16)V99 COMP-3.
Definitely a limited solution, as the 2002 standard
ups the max numeric length from 18 to 31 digits.
With this code, you move to a new compiler, later make
a few (seemingly) unrelated changes and suddenly your
COBOL code stops working for no apparent reason.
I agree, "Don't try this at home."
--
Ron
(user ron
in domain spamblocked.com)
| |
|
| In article <hkk4d2htnkv5lr1885cnkcg91d7kq9mgmj@4ax.com>,
Ron <ron@address.below> wrote:
>docdwarf@panix.com () wrote:
>
>Definitely a limited solution, as the 2002 standard
>ups the max numeric length from 18 to 31 digits.
Quite so... and when the 1985 standard removed the AFTER POSITIONING
syntax I stopped seeing those in programs... sometimes afterwards.
I will apologise, however, for reversing the fieldnames; what is labelled
as BIGGEST-PD-X-COMP3 should be BIGGEST-PD-X and vice-versa.
>
>With this code, you move to a new compiler, later make
>a few (seemingly) unrelated changes and suddenly your
>COBOL code stops working for no apparent reason.
Ummmmm... this describes many programs that, I believe, more than a few
programmers have seen; nothing new to it at all.
>
>I agree, "Don't try this at home."
Then, of course... one of us *must* be wrong, or so I'll Wildely conclude.
DD
| |
| William M. Klein 2006-08-04, 7:55 am |
| With the '02 Standard, you definitely should use the
Highest-Algebraic
intrinsic function. (And probably USAGE PACKED-DECIMAL rather than Comp-3)
--
Bill Klein
wmklein <at> ix.netcom.com
"Ron" <ron@address.below> wrote in message
news:hkk4d2htnkv5lr1885cnkcg91d7kq9mgmj@
4ax.com...
> docdwarf@panix.com () wrote:
>
> Definitely a limited solution, as the 2002 standard
> ups the max numeric length from 18 to 31 digits.
>
> With this code, you move to a new compiler, later make
> a few (seemingly) unrelated changes and suddenly your
> COBOL code stops working for no apparent reason.
>
> I agree, "Don't try this at home."
>
> --
> Ron
> (user ron
> in domain spamblocked.com)
| |
| Howard Brazee 2006-08-04, 7:55 am |
| On Fri, 04 Aug 2006 12:24:33 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>With the '02 Standard, you definitely should use the
> Highest-Algebraic
>intrinsic function. (And probably USAGE PACKED-DECIMAL rather than Comp-3)
I tend to use PACKED-DECIMAL these days, but don't think it really
matters. If we have to port to a computer where COMP-3 syntax is a
problem, chances are we would have to re-do the data as well.
|
|
|
|