Home > Archive > Cobol > April 2005 > PIC X Alpha to PIC 9 = valid numeric?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
PIC X Alpha to PIC 9 = valid numeric?
|
|
| docdwarf@panix.com 2005-04-26, 3:55 pm |
|
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
| |
| William M. Klein 2005-04-26, 3:55 pm |
| 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
| |
| William Bub 2005-04-26, 8:55 pm |
| 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
>
| |
| docdwarf@panix.com 2005-04-27, 3:55 am |
| 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...
>
>
| |
| docdwarf@panix.com 2005-04-27, 8:55 pm |
| In article <rv8d61971uhh h8sete8qceuhiutaf4s@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
| |
| SkippyPB 2005-04-27, 8:55 pm |
| 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
| |
| docdwarf@panix.com 2005-04-27, 8:55 pm |
| 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
| |
| docdwarf@panix.com 2005-04-27, 8:55 pm |
| 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 what
>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...
>
>
|
|
|
|
|