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

Quote:

>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.

If you had used the tools available you could have used
Wang's  MOVE WITH CONVERSION  extension to take care of
any PIC X -> PIC 9 manipulations.

This takes care of the knotty problem of moving a
NUMERIC EDITED into a NUMERIC.  M.W.C. handles the
decimal, signs, and spaces... I wish they'd make it
handle commas, too.

Quote:
>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.

Duh, since a space isn't a number, doesn't it make sense
not to allow non-numeric values in a numeric field?

Quote:
>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.

The compiler was protecting you from doing something stupid.

In my opinion.



Thu, 25 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)


Quote:

>>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.

>If you had used the tools available you could have used
>Wang's  MOVE WITH CONVERSION  extension to take care of
>any PIC X -> PIC 9 manipulations.

  LOOK! I was assigned to figure out why the program was yielding
  incorrect results after being recompiled with NO OTHER CHANGES.  I
  didn't write the thing to start with.  The functionalitly of the
  compiler changed in it's new version. It was not a matter of using
  "tools". Besides that...if you're paying attention... the original
  programmer DIDN'T WANT CONVERSION.  The Pic X field contained
  spaces and he expected (as he should) that the receiving Pic 9
  field would also contain spaces.  He checked it's validity later in
  a subsequent paragraph. Since the compiler CHANGED the data and put
  zeros instead of spaces into the Pic 9 field, the later numeric
  check always worked and yielded incorrect results.  Bad programming
  I know, but I didn't write it in the first place.

Quote:

>This takes care of the knotty problem of moving a
>NUMERIC EDITED into a NUMERIC.  M.W.C. handles the
>decimal, signs, and spaces... I wish they'd make it
>handle commas, too.

  What are you talking about, it was Pic X to Pic 9...there
  was no numeric edited item involved.

Quote:

>>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.

>Duh, since a space isn't a number, doesn't it make sense
>not to allow non-numeric values in a numeric field?

  Duh to you! No it doesn't. THE COMPILER DOES NOT HAVE THE RIGHT
  TO CHANGE THE DATA!!! Both fields are usage DISPLAY. It should
  do a simple MVC and move the data no matter what the contents.
  It is the programmers, not the compilers, responsiblity to ensure
  data validity...who again was NOT me to start with.

  *IF* the compiler were not going to allow non-numeric data in
  a numeric field, then it should dis-allow it at compile time.
  It should in NO WAY change data.

  This is the exact argument I got into with Wang tech support.

Quote:

>>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.

>The compiler was protecting you from doing something stupid.

  Then the compiler is WRONG. It is not the compilers business to
  protect programmers from doing something stupid. It's the
  compilers business to do what it's told even it is something
  stupid.

  AGAIN - THE COMPILER DOES NOT HAVE THE RIGHT TO MODIFY DATA!

  Pic X to Pic 9 is a valid move by the rules of COBOL.
  The contents of the Pic X field should be moved UNCHANGED to
  the Pic 9 field given both fields are of equal length - PERIOD.



Thu, 25 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

Quote:

> [snippage of a moderately justified rant]
>   AGAIN - THE COMPILER DOES NOT HAVE THE RIGHT TO MODIFY DATA!

Calm down, old boy, you'll blow a capillary... whether the compiler has
this 'right' (curious use of that term, but neither here nor there) the
question is not one of 'rights'... the question is one of 'is'.  No
matter what the scintillating clarity of your arguments might be I do
not think that WANG is about to rewrite a chunk of compiler-code based
on your powers of persuasion... I would be happy to be proven wrong on
this, of course.

So, then question changes, I believe, from 'what is right?' to 'what to
do?'... and I fear I have lost sight of the original difficulty.  If it
remain unsolved might you restate it so that we might construct some WS
fields, based on the compiler's changed behavior?

DD



Thu, 25 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)


Quote:

>> [snippage of a moderately justified rant]

>>   AGAIN - THE COMPILER DOES NOT HAVE THE RIGHT TO MODIFY DATA!

>Calm down, old boy, you'll blow a capillary... whether the compiler has
>this 'right' (curious use of that term, but neither here nor there) the
>question is not one of 'rights'... the question is one of 'is'.  No
>matter what the scintillating clarity of your arguments might be I do
>not think that WANG is about to rewrite a chunk of compiler-code based
>on your powers of persuasion... I would be happy to be proven wrong on
>this, of course.

>So, then question changes, I believe, from 'what is right?' to 'what to
>do?'... and I fear I have lost sight of the original difficulty.  If it
>remain unsolved might you restate it so that we might construct some WS
>fields, based on the compiler's changed behavior?

  Okay... I'm calmed down now. I tried to write about an experience
  with this issue and some guy replied with what I felt was a
  condescending, smart alack flame that aggravated me. It's
  irrelevant now anyway since we're no longer using Wang.  I still
  stay it was a bug in their compiler though.

  For the record, MicroFocus will terminate animator with an
  "invalid data in numeric field" message and VS Cobol II on MVS
  simply does the move without data modification. Early releases of
  VS Cobol II had problems with this kind of move as well which IBM
  recognized as wrong and corrected.



Fri, 26 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

big snip

Quote:
>   AGAIN - THE COMPILER DOES NOT HAVE THE RIGHT TO MODIFY DATA!

But of course, compilers (and their associated runtime libraries,
actually) modify data all the time.

Quote:
>   Pic X to Pic 9 is a valid move by the rules of COBOL.

You need to go to the *source* (i.e. the COBOL standard) and read all
the conditions that must exist on the X-to-9 move before it is valid.
Therein you will find that the compiler has the right to treat the pic X
field as if it were pic 9, which means a whole lot to a compiler writer.

Quote:
>   The contents of the Pic X field should be moved UNCHANGED to
>   the Pic 9 field given both fields are of equal length - PERIOD.

No, not really (see above).  HOWEVER, if the application writer intends
for the transparent move of nonnumeric data in such a situation, the
standard provides a mechanism: reference modification.  Through
reference modification, one can alias the pic 9 field to alphanumeric,
and the move is transformed to an alphanumeric-to-alphanumeric move:
    MOVE pic-x-item TO pic-9-item (1:)

(That's the syntax -- not a smiley).

Despite your opinion, which has been clearly stated and is obviously
srongly held, your version of how COBOL should behave has not been
accepted in theory (i.e. the standard and the CCVS (COBOL Compiler
Validation Suite) test programs) or in fact (the implementations of
most, if not all, major COBOL vendors).  But a new standard is being
brewed right now, so there is still time to argue your case in the
sppropriate forum.

--

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



Fri, 26 May 2000 03:00:00 GMT  
 Moving PIC X(06) to PIC 9(06)

Quote:

>   LOOK! I was assigned to figure out why the program was yielding
>   incorrect results after being recompiled with NO OTHER CHANGES.  I
>   didn't write the thing to start with.  The functionalitly of the
>   compiler changed in it's new version. It was not a matter of using
>   "tools". Besides that...if you're paying attention... the original
>   programmer DIDN'T WANT CONVERSION.  The Pic X field contained
>   spaces and he expected (as he should) that the receiving Pic 9
>   field would also contain spaces.  He checked it's validity later in
>   a subsequent paragraph. Since the compiler CHANGED the data and put
>   zeros instead of spaces into the Pic 9 field, the later numeric
>   check always worked and yielded incorrect results.  Bad programming
>   I know, but I didn't write it in the first place.

This sounds like Micro Focus COBOL on a PC or UNIX.  You can set a runtime
switch or compiler directive to get the desired behavior, but in all
honesty, to expect a PIC 9 field to "properly" contain spaces is insane.


Fri, 26 May 2000 03:00:00 GMT  
 
 [ 6 post ] 

 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