Moving PIC X(06) to PIC 9(06) 
Author Message
 Moving PIC X(06) to PIC 9(06)

Hope some of you COBOL gurus might be able to give me the definitive answer
on this.  According to my copy of Stern and Stern (Seventh Edition) moving
a PIC X(06) variable to a PIC 9(06) variable is not a permissible move.  I
looked this up when I was getting a S0C7 error (data exception) due to a
PIC X variable set to low values being moved to a PIC 9 variable, which is
was then passed to an external routine.  The error occurred when a
mathematical operation was attempted on the variable in the external
routine.
Going through Xpediter I saw the contents of the PIC X variable was low
values (as expected) but the contents of the PIC 9 variable was
0000000000F0 (6 bytes in hex notation) after the move.  
My colleagues say that moving a PIC X to a PIC 9 is okay as long as the PIC
X variable only contains numerics (ie anything between 0 and 9 in each byte
position).  I showed them Stern and Stern and they grunted and said it was
still alright (see previous sentence).  What do you people think?    
--
                           Regards
                 The Man in Spectacles

Please remove -nematode- from the email address before replying

Solicitations to me must be pre-approved in writing by me after solicitor
pays $1000 US per incident.  Solicitations sent to me are proof that you
accept this notice and will send a certified check forthwith.



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)



Quote:
>.  
> My colleagues say that moving a PIC X to a PIC 9 is okay as long as the
PIC
> X variable only contains numerics (ie anything between 0 and 9 in each
byte
> position).  I showed them Stern and Stern and they grunted and said it
was
> still alright (see previous sentence).  What do you people think?    

Short answer.

It's still alright.

Long answer - if only numeric variables were moved to numeric variables,
the number of  core dumps would be reduced considerably.  However, the
second most common reason - at our shop - for data exceptions is the fact
that many times people fail to initialize numeric working storage items
before using them.



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)


Quote:

> Hope some of you COBOL gurus might be able to give me the definitive answer
> on this.  According to my copy of Stern and Stern (Seventh Edition) moving
> a PIC X(06) variable to a PIC 9(06) variable is not a permissible move.
> My colleagues say that moving a PIC X to a PIC 9 is okay as long as the PIC
> X variable only contains numerics (ie anything between 0 and 9 in each byte
> position).  I showed them Stern and Stern and they grunted and said it was
> still alright (see previous sentence).  What do you people think?

I tried a bunch of stuff just to be sure - and will vote with your
colleagues. The hex underlying the fields for PIC X(06) = "123456" would
be 'F1 F2 F3 F4 F5 F6' in the PIC X(06) and the same under the PIC
9(06).
A common related problem is where someone moves 'S9(xx) COMP-3' to
'X(xx)' and expects an unpack to occur.
In any case, if there is any doubt about the value in the first operand,
one should check it for numeric prior to trying to stuff it into a PIC
9(..) field.

John



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)


Quote:

> Hope some of you COBOL gurus might be able to give me the definitive answer
> on this.  According to my copy of Stern and Stern (Seventh Edition) moving
> a PIC X(06) variable to a PIC 9(06) variable is not a permissible move.  

I do this all the time, however you *do* have to ensure that the PIC X
field is numeric first.  LOW-VALUES is NOT numeric!!!
--
Joe
+-------------------------------------------------------+
| Nothing is fool-proof to a sufficiently talented fool.|
+-------------------------------------------------------+      
| In order to reply via e-mail address as follows:      |
|      jkohler at compuserve dot com                    |
| replace the at and dot with the appropriate symbols.  |
+-------------------------------------------------------+


Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

: However, the
: second most common reason - at our shop - for data exceptions is the fact
: that many times people fail to initialize numeric working storage items
: before using them.

Thas'a right!  The big gotcha's are the result of something like:
A believing, trusting, but inexperienced coder pulls a value out
of a CICS BMS screen field -- stuffs it into new record -- and
does a WRITE KEY NEW -- ala. new cutomer create.
At month end the (numeric) field is operated on and , surprise! ,
S0C7!!  --- at 3 A.M.  --- in a JOB thats a pre-req for 177 JOBs
downstream.

Don'cha just love this buisness?? <g>

Jonesy
MainFrame IBM since **1966

--
Marvin L Jones  |  Denver, Colo:    az736<AT>freenet.uchsc.edu
Jonesy          |  Gunnison, Colo:  jonz<AT>rmi.net
W3DHJ  DM68mn   |  CompuServe:      72103,443
                |  snail-mail:      81230-1371



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

: However, the
: second most common reason - at our shop - for data exceptions is the fact
: that many times people fail to initialize numeric working storage items
: before using them.

Thas'a right!  The big gotcha's are the result of something like:
A believing, trusting, but inexperienced coder pulls a value out
of a CICS BMS screen field -- stuffs it into new record -- and
does a WRITE KEY NEW -- ala. new customer create.
At month end the (numeric) field is operated on and , surprise! ,
S0C7!!  --- at 3 A.M.  --- in a JOB thats a pre-req for 177 JOBs
downstream!

Don'cha just  l o v e  this business?!  <g>

Jonesy
MainFrame IBM since 1966

--
Marvin L Jones  |  Denver, Colo:    az736<AT>freenet.uchsc.edu
Jonesy          |  Gunnison, Colo:  jonz<AT>rmi.net
W3DHJ  DM68mn   |  CompuServe:      72103,443
                |  snail-mail:      81230-1371



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)



Quote:

>Don'cha just love this buisness?? <g>

Most fun I've had making a buck yet... got workin' on th' loadin'-dock
beat *all* hollow!

DD



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)


Quote:
> According to my copy of Stern and Stern (Seventh Edition)
> moving
> a PIC X(06) variable to a PIC 9(06) variable is not a permissible
> move.
snip
> My colleagues say that moving a PIC X to a PIC 9 is okay as long as
> the PIC
> X variable only contains numerics (ie anything between 0 and 9 in each
> byte
> position).  I showed them Stern and Stern and they grunted and said it
> was
> still alright (see previous sentence).  What do you people think?

The ANSI (ISO) COBOL standard defines this as an acceptable MOVE; your
colleagues are correct.  The sending operand is treated as if it were
described as an unsigned numeric integer.

Good programming practice (that taught by Stern and Stern) would not
allow the use of this 'feature'.  More relaxed programming practice
would require an IF...NUMERIC before the move, so that machines that are
intolerant of moving nonnumeric values won't abend your program.  

If you absolutely MUST propogate the bad data, then use reference
modification on the receiving item:
     MOVE PIC-X6 TO PIC-96 (1:)
This most likely will cause problems downstream...

Best regards,
--

Liant Software Corporation   http://www.liant.com/
512-343-1010  FAX:512-343-9487



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)


Quote:

> Hope some of you COBOL gurus might be able to give me the definitive answer
> on this.  According to my copy of Stern and Stern (Seventh Edition) moving
> a PIC X(06) variable to a PIC 9(06) variable is not a permissible move.  I
> looked this up when I was getting a S0C7 error (data exception) due to a
> PIC X variable set to low values being moved to a PIC 9 variable, which is
> was then passed to an external routine.  The error occurred when a
> mathematical operation was attempted on the variable in the external
> routine.
> Going through Xpediter I saw the contents of the PIC X variable was low
> values (as expected) but the contents of the PIC 9 variable was
> 0000000000F0 (6 bytes in hex notation) after the move.
> My colleagues say that moving a PIC X to a PIC 9 is okay as long as the PIC
> X variable only contains numerics (ie anything between 0 and 9 in each byte
> position).  I showed them Stern and Stern and they grunted and said it was
> still alright (see previous sentence).  What do you people think?
> --
>                            Regards
>                  The Man in Spectacles

> Please remove -nematode- from the email address before replying

> Solicitations to me must be pre-approved in writing by me after solicitor
> pays $1000 US per incident.  Solicitations sent to me are proof that you
> accept this notice and will send a certified check forthwith.

It is a valid move. But to safeguide yourself not to be called at 3:00am
for firefighting, better take a numeric test on it before the move
statement.

Rgds,
Chip Ling



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

Quote:


> > According to my copy of Stern and Stern (Seventh Edition)
> > moving
> > a PIC X(06) variable to a PIC 9(06) variable is not a permissible
> > move.
> snip
> > My colleagues say that moving a PIC X to a PIC 9 is okay as long as
> > the PIC
> > X variable only contains numerics (ie anything between 0 and 9 in each
> > byte
> > position).  I showed them Stern and Stern and they grunted and said it
> > was
> > still alright (see previous sentence).  What do you people think?

> The ANSI (ISO) COBOL standard defines this as an acceptable MOVE; your
> colleagues are correct.  The sending operand is treated as if it were
> described as an unsigned numeric integer.

> Good programming practice (that taught by Stern and Stern) would not
> allow the use of this 'feature'.  More relaxed programming practice
> would require an IF...NUMERIC before the move, so that machines that are
> intolerant of moving nonnumeric values won't abend your program.

I don't know why you think it is bad practice to do this kind of a
MOVE, once you have verified that the contents of the PIC(06)
are in fact numeric.  In some cases I don't see a good obvious way to
avoid it, unless you redefine the PIC X(06) as a PIC 9(06) and then
MOVE the PIC 9(06) version.  Such a variant doesn't strike me as
much of an improvement.

Suppose your PIC X(06) represents an input field on a data entry
screen.  Depending on the environment you may not be able to keep
the user from entering garbage into what should be a numeric field.
After verifying that the field is numeric, just how would "good
programming practice" convert it to a numeric value?

You could use EVALUATE to assign a numeric value to each digit,
multiply each value by the appropriate power of 10, and add them
all up.  No doubt there are other possible ways as well, but how
is any of them better than a simple MOVE?  Are there dialects where
such a MOVE (of valid data) would cause an abend?


http://home.swbell.net/mck9/cobol/cobol.html



Sun, 21 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)



Quote:

>Thas'a right!  The big gotcha's are the result of something like:
>A believing, trusting, but inexperienced coder pulls a value out
>of a CICS BMS screen field -- stuffs it into new record -- and
>does a WRITE KEY NEW -- ala. new customer create.
>At month end the (numeric) field is operated on and , surprise! ,
>S0C7!!  --- at 3 A.M.  --- in a JOB thats a pre-req for 177 JOBs
>downstream!

You...don't....edit....screen entrty???  What planet did you arrive
from?  Seriously, sounds like you need a good tester.  The business
analyst on my last team was very good at finding bugs;  kept us all on
our toes.

Quote:
>Don'cha just  l o v e  this business?!  <g>

Yeah, but sometimes I forget why.
Unsolicited e-mails are annoying, but not that big a deal.  
I'd rather not get them, but they're easy enough to delete.  
The flip side is that sometimes they actually are of interest.
It's just like junk mail, we all complain about it, but once
in a while there's something worth opening up and reading.        
-Curt Shannon


Mon, 22 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

Quote:


>> Hope some of you COBOL gurus might be able to give me the definitive answer
>> on this.  According to my copy of Stern and Stern (Seventh Edition) moving
>> a PIC X(06) variable to a PIC 9(06) variable is not a permissible move.  I
>> looked this up when I was getting a S0C7 error (data exception) due to a
>> PIC X variable set to low values being moved to a PIC 9 variable, which is
>> was then passed to an external routine.  The error occurred when a
>> mathematical operation was attempted on the variable in the external
>> routine.
>> Going through Xpediter I saw the contents of the PIC X variable was low
>> values (as expected) but the contents of the PIC 9 variable was
>> 0000000000F0 (6 bytes in hex notation) after the move.
>> My colleagues say that moving a PIC X to a PIC 9 is okay as long as the PIC

snip

the move is valid as the data is unpacked  the 'F' on the end was a
forced sign  usually an OR of x'F0'

the data, when used, will be packed and the unnecessary zones on the
other digits are ignored.  When final unpacking is done...F zones are
forced on each digit.   SMOKIN'

JR

and stir with a Runcible spoon...



Mon, 22 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

Absolutely this is a valid move. Since both fields are usage
display, at the assembler level this should be a simple MVC.
Whatever is in the Pic X field should end up in the Pic 9 field.

The compiler of course will not do any check to ensure that you
are putting numeric data into the Pic 9 field. You're setting
yourself up for a big SOC7 if you don't do a IF NUMERIC
check first.

Years ago when we had a Wang machine I got into a big shall we say
"discussion" with WANG technical support over this issue. Someone
else had coded a program that did exactly this, moved a pic x to a
pic 9 field. We loaded a new version of the compiler and started
getting all kinds of odd results from a program.  The "people" who
wrote the compiler decided that since pic 9 was numeric they would
ensure that numerics ended up in the field. The pic x field
contained spaces and they altered the data so that the pic 9
receiving field ended up with zeros after the move. The programmer
did the numeric check after the move in a subsequent paragraph.
Admittedly, this move statement is bad programming but I arugued
that this was flat wrong and the compiler does not have the right to
change the data. It should have put whatever was in the pic x field
into the pic 9 field and let the chips fall. I didn't win this with
Wang but we don't have a Wang machine anymore either. This is the
only thing I've found in a cobol compiler that I think was truely a
bonafide bug.



Mon, 22 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

Thanks a lot to everyone who responded to this post.  We now have a much
clearer idea of how we should be handling this situation and what to watch
out for.
--
                           Regards
                 The Man in Spectacles

Please remove -nematode- from the email address before replying

Solicitations to me must be pre-approved in writing by me after solicitor
pays $1000 US per incident.  Solicitations sent to me are proof that you
accept this notice and will send a certified check forthwith.



Mon, 22 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)


Quote:

> I don't know why you think it is bad practice to do this kind of a
> MOVE, once you have verified that the contents of the PIC(06)
> are in fact numeric.  In some cases I don't see a good obvious way to
> avoid it, unless you redefine the PIC X(06) as a PIC 9(06) and then
> MOVE the PIC 9(06) version.  Such a variant doesn't strike me as
> much of an improvement.

Michael, any practice which sets up a situation for a likely problem is bad.
By definition, alphanumeric data is left justified and space filled, and
numeric data is right justified and zero filled.  These types are by nature
mutually contradictory.  For a move like this to work properly, the fields
usually (but not always) need to be the same size.  Any time you move between
the two you set yourself or some poor maintenance programmer up for a
surprise when the size of one field is changed, or the numeric field is
changed to COMP.  If you always make a habit of only moving numeric to
numeric and alphanumeric to alphanumeric, you will never need to worry about
it.  You have eliminated that pitfall entirely.  And it doesn't take a lot of
coding:

           03  TEST-FIELD           PIC  X(04).

can easily be changed to:

           03  TEST-FIELD.
               05  TEST-FIELD-NUM   PIC  9(04).

Since group items are implicitly alphanumeric, the usage of TEST-FIELD is not
changed, and you now have a numeric definition to use.

Of course, you should NEVER, EVER accept data into a database, or use it for
numeric purposes without validating it.  To do this is a mark of inexperience
or sloppiness.  It is one of the differences between excellence and get-by.
Which kind of programming would you trust to handle your life or fortune?
--
Judson McClendon          This is a faithful saying and worthy of all
Sun Valley Systems        acceptance, that Christ Jesus came into the

(please remove zzz from email id to respond)



Mon, 22 May 2000 03:00:00 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Moving PIC X(06) to PIC 9(06)

2. Moving a PIC X(20) to PIC S9(8)V9(2) COMP 3 field

3. moving data from pic 99 to pic 99

4. CPCS v4.06 and new v2.25

5. ANNOUNCE: OSLib v1.06 now available

6. Part 06 of 11 - Topics for Discussion

7. How to write 14.316523E-06 to spreadsheetfile

8. Grumpfish Library v4.06

9. mouse sample - regist.arj (06/10)

10. Comix 3.00.06

11. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (06/10)

12. Mice In TS Modula 2, v1.06 for DOS

 

 
Powered by phpBB® Forum Software