Numeric-edited fields problem. 4

[andreymurom]

Hello everybody,

My program uses 2 fields that are passed parameters from another another program where they are defined as a character fields. The data in these fields is numeric and I want to do some numeric operations on them.

They are defined as:
01 PGM-PARM.
...
05 FROM-AMT PIC -(8)9.
05 TO-AMT PIC -(8)9.
...

Then I have temporary numeric fields in the program (Thank you very much, Betty Scherber, for the great advice! It's worked.):

01 FROM-AMT-NUM PIC S9(9).
01 TO-AMT-NUM PIC S9(9).

Then I move parms into the numeric fields:

MOVE FROM-AMT TO FROM-AMT-NUM.
MOVE TO-AMT TO TO-AMT-NUM.

There is no problem with the negative numbers coming from the calling program. But when it moves positive numbers it gives an error:

Message . . . . : Floating character in numeric-edited sending field at statement 414 was not valid (C D F G).
Cause . . . . . : During the de-editing of a numeric-edited field containing the floating PICTURE character +, -, or $, a leading floating character was not found, or it was located at the wrong position in the field.

The value in the sending field when this happens looks like : "000001000".

Thank you

 

[slade]

Hi Andre,

There are a number of ways to solve this. One is to redefine the parm flields as pic X(09) and test the ih-ord byte for zero. If zero move numed field; if not move alphanum field, e.g.:

05 to-amt pic -9(08).
05 to-amt-x redefines
to-amt pic x(09).

if to-amt-x(1:1) = zero
move to-amt-x to to-amt-num
else
move to-amt to to-amt-num
end-if

P.S. I don't have a manual handy, but I'm pretty sure you can move A/N to NUM.
Check the maunual.

Jack

 

[RonaldB]

Andre,

i do have a manual ready, but no experience with de-editing. You might wanna try the SIGN LEADING clause on your numeric field, so:

01 FROM-AMT-NUM PIC S9(9) SIGN LEADING.
01 TO-AMT-NUM PIC S9(9) SIGN LEADING.

I haven't tried it, but maybe you can. Let us know if it helped.

Regards,
Ronald.

 

[slade]

Hi Ron,

You bring up a good point. The fields can be defined that way if they all contain leading zeros after the sign. If the field can contain " -123", the num/ed definition must stand (note that the num/ed def works in either case).

But the real issue is that the fields, if they contain zeros, don't have a sign. Thus the IF statment is required.

Regards, Jack.

 

[RonaldB]

Jack,

i'm sure you're right; as said, i don't have much experience with de-editing. Anyway, passing edited parms bites wind, in my opinion; any numeric field should only then be edited when needed for displaying and such, and otherwise kept in original numeric form. But that's just my opinion; Andre of course has to work with the situation at hand.

Regards,
Ron(ald).

 

[andreymurom]

Thank you very much Jack, thank you very much Ron. I redefined the fields as Jack suggested and it worked. thank you very much again!!!

 

[Thane]

Another way would be to use Function Numval.

 

[andreymurom]

I actually tried the Function Numval, but by some reason I can't even enter it, the line gets highlighted and error message shows at the bottom of the screen. I am using PDM on the AS400, OS version - V4R4. Has anybody used any Functions on the AS400?

 

[slade]

Hi Andrey,

Gotta see the code and err msg.

Hi Thane,

The bad thing about NUMVAL and NVC is that it will abend if the sending data doesn't conform to the assumed input requirements. I'd much prefer if it just moved the invalid digits to the receiving field as is and allow me to use an IF NUMERIC to determine if the data is OK. Or maybe set an rc or both.

Thanx, Jack.

 

[Anil29]

Hi,

I am getting a SOC7 abend whicle moving a date field 9(6) COMP-3 to another 9(6) date field.

The problem was due to the data in the sending field being non-numeric.

The data in the input file field is actaully populated in a program which is executed before the program givning the error. Here the field is assigned from a PIC 9(6) date variable to the PIC 9(6) COMP-3 variable by a MOVE satement.

The data in the sending field is proper. But the receiving field data becomes non-numeric. I am unable to reason out why this happens.

Please help me out.

Thanks.

 

[slade]

Hi Anil,

You'll have to show us the fields before/after each move.
I know you can find them in the dump but it's more accurate to show us a series of displays that contain the data. I use:

DISPLAY 'DEBUG~ fld descr >' fld-name '<'

The &quot;DEBUG~&quot; makes them easy to find and delete. The &quot;><&quot; makes it easy to determine if unprintable chars are in the fld.

Looking forward to seeing what you come up with.

Regards, Jack.

 

[NinaToo]

Anil, you wrote:
----------
I am getting a SOC7 abend whicle moving a date field 9(6) COMP-3 to another 9(6) date field.

The problem was due to the data in the sending field being non-numeric.
----------
If I recall my facts about packed decimal (COMP-3) fields, I believe that they contain non-numeric characters to symbolize certain values. Which is why a date field in PIC 9(6) COMP-3 only takes up 3 bytes, whereas a date field in PIC 9(6) takes up 6 bytes.

So to move a COMP-3 field into a PIC 9, you have to redefine the COMP-3 field first, to a PIC 9. Then move that value into your other PIC 9 field (or simply use the PIC 9 redefined field to do whatever you do with it, without the extra MOVE).

If you move a COMP-3 field into a PIC X(6), I don't think that you would get the SOC 7, but you would get rather strange looking values in the PIC X field, which wouldn't process the way you would want it to.

Hope this helps, and anyone, feel free to correct me if I'm wrong. Nina Too

 

[slade]

Hi Nina,

I THINK the comp-3 move to a pic x will result in valid O/P.

pic 9(6) comp-3 has 4 bytes. Even numbered digits in comp-3 defs is inefficient and misleading because the field contains 7 digits plus the sign. I think there's also some code generated to compensate for the pic/storage mismatch.

Regards, Jack.

 

[StephenJSpiro]

andreymurom wrote:

My program uses 2 fields that are passed parameters from another another program &quot;where they are defined as a character fields&quot;. The data in these fields is numeric and I want to do some numeric operations on them.
(quotes added)

When using a field passed by reference (the default for CALL), you should always define it the same way in the receiving program. THEN manipulate it.

You had a character field described as numeric edited, and you not only described it differently, you got the edit mask wrong. I do not know why you should have no sign on a positive number, but, clearly, the sending data was NOT necessarily formatted as you expected. You can either go to the sending program to figure out why, or, as suggested, write a kludge to make it work as you expect.
The professional way is to find out what you are really getting. (No criticism intended for the authors of the workarounds; you were looking for a programming solution based on the facts which you provided, and they gave it to you.)

Stephen J Spiro
Member, J4 COBOL Standards Committee

 

[NinaToo]

Slade, you wrote:
---------
pic 9(6) comp-3 has 4 bytes. Even numbered digits in comp-3 defs is inefficient and misleading because the field contains 7 digits plus the sign.
---------
Jack, I believe that what you are describing is a PIC S9(6) COMP-3. This contains 3 bytes plus the sign byte, total=4 bytes. I believe that is you have PIC 9(6) COMP-3, without the sign, then it's 3 bytes.

I might be wrong, however. Perhaps in some systems, the sign is implied when you use COMP-3.

Nina Too

 

[StephenJSpiro]

Nina, in IBM on the mainframe, packed decimal fields always have a sign nibble. Even unsigned fields. C is plus, D is minus, and F is unsigned. The sign is ALWAYS trailing in IBM mainframe COMP-3.
(The MACHINE considers C A E and F as positive, D and B as negative. For COBOL purposes, however, F is unsigned and
B A and E will never happen.)

Stephen J Spiro

 

[slade]

Hi Nina,

What he said.

Regards, Jack.

 

[BettyScherber]

Slade -
I recall that beginning with COBOL 85, an S9(6) field really is only allowed to hold six digits, even if you're using COMP or COMP-3 or BINARY or PACKED-DECIMAL. The validation tests provided by ANSI for testing COBOL compilers actually contain tests for this and if you don't truncate the data you fail. True the half-byte is wasted, but at least it's not misleading. Betty Scherber
Brainbench MVP for COBOL II

http://www.brainbench.com

 

[RonaldB]

All,

a 9(6) COMP-3 field occupies 4 bytes. Always. Well, at least on a mainframe, but i think this is a COBOL standard.
Using an explicit picture 9(6) may be wasting a nibble, but as Betty stated, it makes it clear that this should be a six digit number, being a date and all.
Moving a COMP-3 field to a zoned numeric field results in a numeric move and should NOT cause an abend, provided the COMP-3 field contains a correct numeric value. The compiler should work out what the sending and receiving field are like and generate code to convert the notations. An abend on such a move indicates a non-numeric value in the sending field.

Just my two cents.

Regards,
Ronald.

 

[NinaToo]

Thanks, everyone, for your imput.

Now could someone tell me the difference between

PIC 9(6) COMP-3

and

PIC S9(6) COMP-3

How many bytes does each of these fields have? I've always been confused on this.

Thanks, Nina Too