PIC X Alpha to PIC 9 = valid numeric?

Platform is IBM mainframe... compilers are IGYCRCTL (IBM Enterprise COBOL
for z/OS and OS/390 3.2.0) *and* IKFCBL00 (IBM OS/VS COBOL JULY 1, 1982).

(The latter shows a compile date of APR 20,1905... hee hee hee!)

Given the code of:

*
01  FLDCHAR1 PIC X VALUE 'A'.
01  FLDCHAR2 PIC X VALUE 'H'.
01  FLDCHAR3 PIC X VALUE 'I'.
01  FLDCHAR4 PIC X VALUE 'R'.
01  FLDCHAR5 PIC X VALUE 'U'.
*
01  NUMCHAR PIC 9 VALUE ZERO.
*
PROCEDURE DIVISION.
MOVE FLDCHAR1 TO NUMCHAR.
IF NUMCHAR-X NUMERIC
DISPLAY ' !1 ', NUMCHAR.
MOVE FLDCHAR2 TO NUMCHAR.
IF NUMCHAR-X NUMERIC
DISPLAY ' !2 ', NUMCHAR.
MOVE FLDCHAR3 TO NUMCHAR.
IF NUMCHAR-X NUMERIC
DISPLAY ' !3 ', NUMCHAR.
MOVE FLDCHAR4 TO NUMCHAR.
IF NUMCHAR-X NUMERIC
DISPLAY ' !4 ', NUMCHAR.
MOVE FLDCHAR5 TO NUMCHAR.
IF NUMCHAR-X NUMERIC
DISPLAY ' !5 ', NUMCHAR.
GOBACK.

... SYSOUT for load modules generated by *both* compilers show:

!1 1
!2 8
!3 9
!4 9
!5 4

... and I am... surprised... nonplussed... flabbergastigatified.  Given
that in EBCDIC A = X'C1', H = X'C8', I = X'C9', R = X'D9', U = X'E4' and
display numerics 0 - 9 are X'F0' - X'F9'...

... it seems that 'automagically' the high-order nibble (C,D or E) is
being replaced while the integrity of the low-order nibble is preserved.

Has anyone else run across this phenomenon... or a reasonable facsimile
thereof?

DD

Doc,
My *guess* is that you have both compilers set to compile with the ZWB
compiler option (available in both).

In addition, I'll bet your Enterprise COBOL compiler has NUMPROC(MIG) set.

Try compiling with NOZWB (and for Enterprise COBOL NUMPROC(PFD) and see what
happens.

NOTE:
ZWB *claims* to only work for "comparisons" - but I have a "vague" memory it
also works for SOME moves.

FYI -
There is NOTHING in the '74, '85, or '02 Standards that say that what is
happening is "invalid".  All the Standards say is that "results are
unpredictable" (except if you have an '02 Standard that is using "exception
handling" which I don't think any compiler - much less any IBM compiler
currently has)

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:d4670o$f0n$1@panix5.panix.com...
>
> Platform is IBM mainframe... compilers are IGYCRCTL (IBM Enterprise COBOL
> for z/OS and OS/390 3.2.0) *and* IKFCBL00 (IBM OS/VS COBOL JULY 1, 1982).
>
> (The latter shows a compile date of APR 20,1905... hee hee hee!)
>
> Given the code of:
>
> *
> 01  FLDCHAR1 PIC X VALUE 'A'.
> 01  FLDCHAR2 PIC X VALUE 'H'.
> 01  FLDCHAR3 PIC X VALUE 'I'.
> 01  FLDCHAR4 PIC X VALUE 'R'.
> 01  FLDCHAR5 PIC X VALUE 'U'.
> *
> 01  NUMCHAR PIC 9 VALUE ZERO.
> *
> PROCEDURE DIVISION.
>     MOVE FLDCHAR1 TO NUMCHAR.
>     IF NUMCHAR-X NUMERIC
>         DISPLAY ' !1 ', NUMCHAR.
>     MOVE FLDCHAR2 TO NUMCHAR.
>     IF NUMCHAR-X NUMERIC
>         DISPLAY ' !2 ', NUMCHAR.
>     MOVE FLDCHAR3 TO NUMCHAR.
>     IF NUMCHAR-X NUMERIC
>         DISPLAY ' !3 ', NUMCHAR.
>     MOVE FLDCHAR4 TO NUMCHAR.
>     IF NUMCHAR-X NUMERIC
>         DISPLAY ' !4 ', NUMCHAR.
>     MOVE FLDCHAR5 TO NUMCHAR.
>     IF NUMCHAR-X NUMERIC
>         DISPLAY ' !5 ', NUMCHAR.
>     GOBACK.
>
> ... SYSOUT for load modules generated by *both* compilers show:
>
> !1 1
> !2 8
> !3 9
> !4 9
> !5 4
>
> ... and I am... surprised... nonplussed... flabbergastigatified.  Given
> that in EBCDIC A = X'C1', H = X'C8', I = X'C9', R = X'D9', U = X'E4' and
> display numerics 0 - 9 are X'F0' - X'F9'...
>
> ... it seems that 'automagically' the high-order nibble (C,D or E) is
> being replaced while the integrity of the low-order nibble is preserved.
>
> Has anyone else run across this phenomenon... or a reasonable facsimile
> thereof?
>
> DD

I think you might have different results if the fields had been larger than
one character. Nibble C represents "plus", and D represents "minus". Other
nibbles also translate to + or -, but are not the "preferred" sign nibble.
If other than the low order digit had a non-F nibble, I think it would have
failed the numeric test.


<docdwarf@panix.com> wrote in message news:d48pbk$cqp$1@panix5.panix.com...
> In article <qcnf611qhrgdhmi5deu8mlln6me971qovf@4ax.com>,
> SkippyPB  <swiegand@neo.rr.NOSPAM.com> wrote: 
>
> [snip]
>
>
> Ummmmm... perhaps that is what  me.  I did not know what sense to
> make of 'the absolute value of a letter'...
>
> ... and I was confounded by the subtlety of the absolute value of 'B'
> being 2... and the absolute value of 'K' being 2, also... and the absolute
> value of 'S' being the same as the absolute values of 'B' and 'K'.
>
> While musing over this... anyone out there have an ASCII platform they can
> try this on?  EBDCIC breaks up the capital letters; A - I = X'C1' - X'C9',
> J - R = X'D1' - X'D9', S - Z = X'E2' - X'E9'... the numerics are X'F1' -
> X'F9'.  ASCII's numerics are X'30' - X'39' and the caps are X'41' - X'5A'
> and I wonder what the absolute values of J (X'4A') through O (X'4F) (or Z,
> X'5A') might be.
>
> DD
>

In article <ATybe.9086$mG3.3669@twister.nyroc.rr.com>,
William Bub <fathafluff@hotmail.com> wrote:
>I think you might have different results if the fields had been larger than
>one character.

One of the other programmers did just that - expand the field to X(02) -
and yes, the results were different.

>Nibble C represents "plus", and D represents "minus". Other
>nibbles also translate to + or -, but are not the "preferred" sign nibble.
>If other than the low order digit had a non-F nibble, I think it would have
>failed the numeric test.

I'm still wondering what an ASCII system considers the absolute value of
J to be... hmmmm... sounding kind of Zen here... perhaps I should make
sounds of meditation in a lunatic manner...

... and just ommmmmm on, deranged.

(note to those who are not familiar with the folk songs of the United
States of America: a standard transliteration of the humming sound made by
meditators in some sects of Buddhims is 'om' (pronounced with a long 'o',
as in 'go'; my example above has a repeated 'm' to emphasise the
humming... and a 'standard' folk song of the USA is named 'Home on the
Range'...

... and once again I manage to demonstrate that a joke explained is a joke
lost.)

DD

>
>
><docdwarf@panix.com> wrote in message news:d48pbk$cqp$1@panix5.panix.com...
 
>
>

In article <rv8d61971uhhh8sete8qceuhiutaf4s@4ax.com>,
Binyamin Dissen  <postingid@dissensoftware.com> wrote:
>On 20 Apr 2005 14:28:40 -0400 docdwarf@panix.com wrote:

[snip]

>:>... it seems that 'automagically' the high-order nibble (C,D or E) is
>:>being replaced while the integrity of the low-order nibble is preserved.
>
>I am assuming the you typed NUMCHAR-X for NUMCHAR.

Actually... the code was copy-n-pasted right from the editor.

>
>My guess would be that the following code is being generated for the move.
>
>         PACK  Temp,FLDCHAR
>         ZAP   Temp2,Temp
>         UNPK  NUMCHAR,TEMP2
>         OI    BUMCHAR,X'F0'

Very close, Mr Dissen... the PMAP for a compile with a ZWB option (see Mr
Klein's suggestion) shows:

22      MOVE      00033C  D2 00 6 038 6 010           MVC  038(1,6),010(6)
000342  96 F0 6 038                 OI   038(6),X'F0'

... and ...

25      MOVE      000376  D2 00 6 038 6 018           MVC  038(1,6),018(6)
00037C  96 F0 6 038                 OI   038(6),X'F0'

... etc., with the OI you predicted in there.  Compiling with the the
NOZWB option set (see Mr Klein's posting) generates:

22      MOVE      00033C  D2 00 6 038 6 010           MVC  038(1,6),010(6)
000342  96 F0 6 038                 OI   038(6),X'F0'

... and ...

25      MOVE      000376  D2 00 6 038 6 018           MVC  038(1,6),018(6)
00037C  96 F0 6 038                 OI   038(6),X'F0'

... showing what some Britspeak users would call 'not a ha'penny's bit o'
difference between 'em'.

Thanks much!

DD

On 21 Apr 2005 08:36:22 -0400, docdwarf@panix.com enlightened us:

>In article <rv8d61971uhhh8sete8qceuhiutaf4s@4ax.com>,
>Binyamin Dissen  <postingid@dissensoftware.com> wrote: 
>
>[snip]
> 
>
>Actually... the code was copy-n-pasted right from the editor.
> 
>
>Very close, Mr Dissen... the PMAP for a compile with a ZWB option (see Mr
>Klein's suggestion) shows:
>
>22      MOVE      00033C  D2 00 6 038 6 010           MVC  038(1,6),010(6)
>                  000342  96 F0 6 038                 OI   038(6),X'F0'
>
>... and ...
>
>25      MOVE      000376  D2 00 6 038 6 018           MVC  038(1,6),018(6)
>                  00037C  96 F0 6 038                 OI   038(6),X'F0'
>
>... etc., with the OI you predicted in there.  Compiling with the the
>NOZWB option set (see Mr Klein's posting) generates:
>
>22      MOVE      00033C  D2 00 6 038 6 010           MVC  038(1,6),010(6)
>                  000342  96 F0 6 038                 OI   038(6),X'F0'
>
>... and ...
>
>25      MOVE      000376  D2 00 6 038 6 018           MVC  038(1,6),018(6)
>                  00037C  96 F0 6 038                 OI   038(6),X'F0'
>
>... showing what some Britspeak users would call 'not a ha'penny's bit o'
>difference between 'em'.
>
>Thanks much!
>
>DD

Maybe I'm not following along correctly here, but the assembler code
makes perfect sense to me no matter what ZWB is.  If I understand
correctly you are moving a PIC X field to a PIC 9 field.  In other
words, you are moving an alpha-numeric field to an unsigned, unpacked
numeric field.  Therefore, MVC (move character) moves the data.  OI
(or immediate) ensures the sign of the receiving field is numeric
positive.  Unsigned numeric is akin to absolute value in math.

Regards,

////
(o o)
-oOO--(_)--OOo-


"You can do anything if you want it bad enough.
That is why we see so many people who can fly."
-- Elden Carnahan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

In article <qcnf611qhrgdhmi5deu8mlln6me971qovf@4ax.com>,
SkippyPB  <swiegand@neo.rr.NOSPAM.com> wrote:
>On 21 Apr 2005 08:36:22 -0400, docdwarf@panix.com enlightened us:

[snip]
 
>
>Maybe I'm not following along correctly here, but the assembler code
>makes perfect sense to me no matter what ZWB is.  If I understand
>correctly you are moving a PIC X field to a PIC 9 field.  In other
>words, you are moving an alpha-numeric field to an unsigned, unpacked
>numeric field.

So far, so good.

>Therefore, MVC (move character) moves the data.  OI
>(or immediate) ensures the sign of the receiving field is numeric
>positive.  Unsigned numeric is akin to absolute value in math.

Ummmmm... perhaps that is what  me.  I did not know what sense to
make of 'the absolute value of a letter'...

... and I was confounded by the subtlety of the absolute value of 'B'
being 2... and the absolute value of 'K' being 2, also... and the absolute
value of 'S' being the same as the absolute values of 'B' and 'K'.

While musing over this... anyone out there have an ASCII platform they can
try this on?  EBDCIC breaks up the capital letters; A - I = X'C1' - X'C9',
J - R = X'D1' - X'D9', S - Z = X'E2' - X'E9'... the numerics are X'F1' -
X'F9'.  ASCII's numerics are X'30' - X'39' and the caps are X'41' - X'5A'
and I wonder what the absolute values of J (X'4A') through O (X'4F) (or Z,
X'5A') might be.

DD

In article <ysx9e.508124$za2.79106@news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>Doc,
>  My *guess* is that you have both compilers set to compile with the ZWB
>compiler option (available in both).

One compiler at a time, then.

For IKFCBL00 the invocation is:

//COB      EXEC PGM=IKFCBL00,
//             PARM=('BUF=60K,SIZE=400K',OPT,DMAP,LIB,P
MAP,APOST)

... and a quick tour of the listing shows - among other things - :

*OPTIONS IN EFFECT*       OPTIMIZE, NOSYMDMP, NOTEST,   VERB,   ZWB,

One 'bingo' for Mr Klein.  Since dealing with IKFCBL00 is a matter of more
academic interest than anything else I will, for the nonce, leave it
aside.

>
>In addition, I'll bet your Enterprise COBOL compiler has NUMPROC(MIG) set.

On this site someone's put together a compile CLIST, command-line invoked
within an editor session, which I used as the skeleton to create my
test-to-my-own-library JCL.  The expansion of this CLIST shows:

XXCOMP     EXEC PGM=IGYCRCTL,
XX            COND=(0,NE,BLDCOPY),
XX            PARM='SIZE(MAX),LIB,NUMPROC(&NUMP),OFF,MAP,
XX             &XREF,&OPT,&FLAG,&C370OPT,NOADV'

... which gets substituted-to, in part:

 PGM=IGYCRCTL,COND=(0,NE,BLDCOPY),PARM='S
IZE(MAX),LIB,NUMPROC(MIG),OFF,MAP,

Second 'bingo' for Mr Klein.  Dropping down through the listing of options
I find, right at the end:

NOWORD
XREF(FULL)
YEARWINDOW(1900)
ZWB

Third 'bingo' for Mr Klein... some days it just works out well, eh?

>
>Try compiling with NOZWB (and for Enterprise COBOL NUMPROC(PFD) and see wha
t
>happens.

Well... time to descend into the Temple of Truth.  Working now only
with the Enterprise version, leaving ZWB alone, turning on the LIST
option so I can get a PMAP... errrrr, listing... and compiling with
NUMPROC(MIG) I find the data are properly initialised, as in:

92C1 2010               MVI   16(2),X'C1'             (BLW=0)+16
92C8 2018               MVI   24(2),X'C8'             (BLW=0)+24
92C9 2020               MVI   32(2),X'C9'             (BLW=0)+32
92D9 2028               MVI   40(2),X'D9'             (BLW=0)+40
92E4 2030               MVI   48(2),X'E4'             (BLW=0)+48
92F0 2038               MVI   56(2),X'F0'             (BLW=0)+56
GN=13    EQU   *

... and there's the A, H, I, R and U my VALUE clause dictates.  Down in
the PROCEDURE DIVISION code one finds...

022  MOVE
00044E  5820 912C               L     2,300(0,9)              BLW=0
000452  92F1 2038               MVI   56(2),X'F1'             (BLW=0)+56

... and ...

025  MOVE
000472  92F8 3038               MVI   56(3),X'F8'             (BLW=0)+56

... and ...

028  MOVE
00048E  92F9 3038               MVI   56(3),X'F9'             (BLW=0)+56

... and I am stunned.  This explains the results I get, sure, but *how*
did the compiler 'know' I 'wanted' the X'C1' at 2010 to be changed into an
X'F1' for the MVI?  Have... puzzlement.

Changing the compile-stream to supply NUMPROC(PFD) does nothing to the
initialisation of the fields:

92C1 2010               MVI   16(2),X'C1'             (BLW=0)+16
92C8 2018               MVI   24(2),X'C8'             (BLW=0)+24
92C9 2020               MVI   32(2),X'C9'             (BLW=0)+32
92D9 2028               MVI   40(2),X'D9'             (BLW=0)+40
92E4 2030               MVI   48(2),X'E4'             (BLW=0)+48
92F0 2038               MVI   56(2),X'F0'             (BLW=0)+56
GN=13    EQU   *

... but the PROCEDURE DIVISION code becomes:

022  MOVE
00044E  5820 912C               L     2,300(0,9)              BLW=0
000452  92C1 2038               MVI   56(2),X'C1'             (BLW=0)+56

... and ...

025  MOVE
000472  92C8 3038               MVI   56(3),X'C8'             (BLW=0)+56

... and ...

028  MOVE
00048E  92C9 3038               MVI   56(3),X'C9'             (BLW=0)+56

... reflecting the 'oughta be' that was coded.

Thanks much!

DD

><docdwarf@panix.com> wrote in message news:d4670o$f0n$1@panix5.panix.com...
 
>
>