Cobol - Numeric Edited and VALUE/MOVE

Author

Numeric Edited and VALUE/MOVE

Roger While

2007-12-14, 6:56 pm

In W/S (Assuming no DECIMAL-POINT IS COMMA) -
<level wahtever> MYFLD PIC ZZZ,Z VALUE ALL '9'.

Equivalent in PROCEDURE -
MOVE ALL '9' TO MYFLD.

AFAIK, num-edits are class alphanumeric and as such current
compilers (tested MF/ACU) produce a value of
99999 in MYFLD. (Which, if I am reading the past/current standards
is correct). This seems to me to me to
be non-intuitive. In fact, OC produces 999,9.
Thoughts?

Roger

William M. Klein

2007-12-14, 6:56 pm

Value clauses are NOT the same as "MOVE literal to field-name (and this is a
good example).

As I recall (but haven't checked this recently)
Set 88-level to true

also follows the rules of VALUE clause and not MOVE. (I think there are some
issues with JUSTIFIED as well as all "literal").

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:fju86o$7rg$02$1@news.t-online.com...
> In W/S (Assuming no DECIMAL-POINT IS COMMA) -
> <level wahtever> MYFLD PIC ZZZ,Z VALUE ALL '9'.
>
> Equivalent in PROCEDURE -
> MOVE ALL '9' TO MYFLD.
>
> AFAIK, num-edits are class alphanumeric and as such current
> compilers (tested MF/ACU) produce a value of
> 99999 in MYFLD. (Which, if I am reading the past/current standards
> is correct). This seems to me to me to
> be non-intuitive. In fact, OC produces 999,9.
> Thoughts?
>
> Roger
>
>

Robert

2007-12-14, 9:56 pm

On Fri, 14 Dec 2007 16:41:39 +0100, "Roger While" <simrw@sim-basis.de> wrote:

>In W/S (Assuming no DECIMAL-POINT IS COMMA) -
><level wahtever> MYFLD PIC ZZZ,Z VALUE ALL '9'.
>
>Equivalent in PROCEDURE -
>MOVE ALL '9' TO MYFLD.
>
>AFAIK, num-edits are class alphanumeric and as such current
>compilers (tested MF/ACU) produce a value of
>99999 in MYFLD. (Which, if I am reading the past/current standards
>is correct). This seems to me to me to
>be non-intuitive. In fact, OC produces 999,9.
>Thoughts?

13.16.61.2
8) Editing characters in a picture character-string are included in determining the size
of the data item, but do not cause editing of the initial value when the data item is
initialized.

What happens when you INITIALIZE MYFLD TO VALUE? Generally, INITIALIZE follows the rules
for MOVE, which would give 999,9. However, the Standard muddies the waters by saying:

14.8.19.3.6.a.3
The actual sending-operand is a literal that, when moved to the receiving-operand with a
MOVE statement, produces the same result as the initial value of the data item as produced
by the application of the VALUE clause.

The requirement is impossible. There IS NO LITERAL that will produce 99999 when MOVEd to
MYFLD.

I tried it on Fujitsu. VALUE ZERO gives 00000. INITIALIZE MYFLD gives 000,0. This compiler
doesn't support TO VALUE.

William M. Klein

2007-12-15, 3:55 am

Sounds like someone should send J4 an interpretation request.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:je56m39r1iar54qglkgu5mgkauafa6tagv@
4ax.com...
> On Fri, 14 Dec 2007 16:41:39 +0100, "Roger While" <simrw@sim-basis.de> wrote:
>
>
> 13.16.61.2
> 8) Editing characters in a picture character-string are included in
> determining the size
> of the data item, but do not cause editing of the initial value when the data
> item is
> initialized.
>
> What happens when you INITIALIZE MYFLD TO VALUE? Generally, INITIALIZE follows
> the rules
> for MOVE, which would give 999,9. However, the Standard muddies the waters by
> saying:
>
> 14.8.19.3.6.a.3
> The actual sending-operand is a literal that, when moved to the
> receiving-operand with a
> MOVE statement, produces the same result as the initial value of the data item
> as produced
> by the application of the VALUE clause.
>
> The requirement is impossible. There IS NO LITERAL that will produce 99999
> when MOVEd to
> MYFLD.
>
> I tried it on Fujitsu. VALUE ZERO gives 00000. INITIALIZE MYFLD gives 000,0.
> This compiler
> doesn't support TO VALUE.

William M. Klein

2007-12-15, 3:55 am

Robert,
I just looked farther.

Did you see the note under SR(8) which says,

"NOTE The programmer is responsible for specifying the value of a literal
associated with an alphanumeric-edited,
numeric-edited, or national-edited item in edited form."

Value ALl "9"

may be accepted by compilers (I think many/most do) and they may indeed do what
you say, but the source is not conforming to the Standard, so its rules don't
apply.

If you had

05 Num-Ed Pic 99,999.99 Value "12,345.67".
....
Initialize Num-Edi to Value

then all would work "as defined in the Standard".

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:WJJ8j.138292$Hq5.20184@fe04.news.easynews.com...
> Sounds like someone should send J4 an interpretation request.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Robert" <no@e.mail> wrote in message
> news:je56m39r1iar54qglkgu5mgkauafa6tagv@
4ax.com...
>
>

Robert

2007-12-17, 6:56 pm

Roger While

2007-12-17, 6:56 pm

"Robert" <no@e.mail> schrieb im Newsbeitrag
news:cu1dm3131h913ngk02am3o26emhg6bq137@
4ax.com...
> On Fri, 14 Dec 2007 16:41:39 +0100, "Roger While" <simrw@sim-basis.de>
wrote:
>
>
> Editing rules are likely to be set at execution time, based on locale. For
instance, the
> currency symbol and whether to use a period or comma before pennies. If
the initial value
> followed the rules for MOVE, that would complicate program loading and
concievably affect
> program logic. I believe the Standard is attempting to avoid that
inconvenience.

Indeed, I am not disputing that. Moving of alpha-numeric to
numeric(-edited) has always been a bone of contention.
However, one ends up with a maybe not expected value in
the field. Funnily enough this turned up with a user
of OC who did not understand the warning that was given
(and which does not appear with MF/ACU, with highest warning level).

OC does initialization at module load time, not at compile time.

Roger

Robert

2007-12-17, 9:56 pm

On Mon, 17 Dec 2007 19:29:50 +0100, "Roger While" <simrw@sim-basis.de> wrote:

>
>"Robert" <no@e.mail> schrieb im Newsbeitrag
> news:cu1dm3131h913ngk02am3o26emhg6bq137@
4ax.com...
>wrote:
>instance, the
>the initial value
>concievably affect
>inconvenience.
>
>Indeed, I am not disputing that. Moving of alpha-numeric to
>numeric(-edited) has always been a bone of contention.

I would use NUMVAL() to cast alphanumeric to numeric.

>However, one ends up with a maybe not expected value in
>the field. Funnily enough this turned up with a user
>of OC who did not understand the warning that was given
>(and which does not appear with MF/ACU, with highest warning level).

The standard says to treat numeric-edited as alphanumeric when initializing it with VALUE.

>OC does initialization at module load time, not at compile time.

Like an INITIALIZE TO VALUE at load time. They should produce the same value, except for
group level values.

Note that '85 says INITIALIZE does not work on INDEX and POINTER whereas '02 initializes
POINTERs.

Richard

2007-12-17, 9:56 pm

On Dec 18, 2:55 pm, Robert <n...@e.mail> wrote:
> On Mon, 17 Dec 2007 19:29:50 +0100, "Roger While" <si...@sim-basis.de> wrote:
>
>
>
>
>
>
>
> I would use NUMVAL() to cast alphanumeric to numeric.

NUMVAL() doesn't 'cast', it converts.

>
> The standard says to treat numeric-edited as alphanumeric when initializing it with VALUE.
>
>
> Like an INITIALIZE TO VALUE at load time. They should produce the same value, except for
> group level values.
>
> Note that '85 says INITIALIZE does not work on INDEX and POINTER whereas '02 initializes
> POINTERs.

'85 doesn't say anything of the sort. USAGE POINTER is an extension to
'85.

William M. Klein

2007-12-18, 3:55 am

"Robert" <no@e.mail> wrote in message
news:ac8em35r5od3kqvplfvfum7ud01e3bc5c4@
4ax.com...
> On Mon, 17 Dec 2007 19:29:50 +0100, "Roger While" <simrw@sim-basis.de> wrote:
<snip>
>
> Note that '85 says INITIALIZE does not work on INDEX and POINTER whereas '02
> initializes
> POINTERs.

Huh ???
Pointers are not IN the '85 Standard, so I don't see how/when it says whether
they are or are not impacted by the INITIALIZE statement.

--
Bill Klein
wmklein <at> ix.netcom.com

Robert

2007-12-18, 6:55 pm

On Tue, 18 Dec 2007 05:15:44 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>"Robert" <no@e.mail> wrote in message
> news:ac8em35r5od3kqvplfvfum7ud01e3bc5c4@
4ax.com...
><snip>
>
>Huh ???
> Pointers are not IN the '85 Standard, so I don't see how/when it says whether
>they are or are not impacted by the INITIALIZE statement.

I've been using pointers so long, I forgot for a moment they weren't in the '85 Standard.
The point is, Micro Focus, IBM and Fujitsu do not INITIALIZE pointers, in conflict with
the current '02 Standard.

William M. Klein

2007-12-18, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:bg4gm3h860aa8qqql93hkiasp0c8evf3pm@
4ax.com...
> On Tue, 18 Dec 2007 05:15:44 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> I've been using pointers so long, I forgot for a moment they weren't in the
> '85 Standard.
> The point is, Micro Focus, IBM and Fujitsu do not INITIALIZE pointers, in
> conflict with
> the current '02 Standard.

"in conflict" with a Standard they don't claim to support.

OK, the significance of this is ...?

--
Bill Klein
wmklein <at> ix.netcom.com

Robert

2007-12-19, 3:55 am

On Tue, 18 Dec 2007 23:55:39 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>
>"Robert" <no@e.mail> wrote in message
> news:bg4gm3h860aa8qqql93hkiasp0c8evf3pm@
4ax.com...
>
>"in conflict" with a Standard they don't claim to support.

Server Express 4.0 SP2 and 5.0 support DIALECT"ISO2002".

Self correction: MF 4.0 SP2 and later *do* INITIALIZE pointers. The balloons by the type
(INITIALIZE identifier DATA-POINTER) say ISO2002/MF, but there is no indication that the
default action (ALL) includes or omits pointers based on compiler options. The description
of their initialization (SET .. TO NULL) does not have a balloon.

>OK, the significance of this is ...?

I assume Roger and the other OC developers want to follow the current Standard.

Sponsored Links