Doubt corresponding with packed field

Pankaj Gupta · New User Joined: 07 May 2008 Posts: 50 Location: Bangalore

Hello,

Recently I am returning to Cobols after absencing for a few years.

I am having a program which is moving a number 75324 to the packed decimal field WS-COUNT PIC S9(4) COMP and another number 3521 to the packed decimal field WS-COUNT2 PIC S9(4) COMP. When these I am adding the answer is coming to be 8845. I am thinking it should be 78845.

Please can you help me why this is being so.

Thanking you,
Pankaj

Bill O'Boyle · Posted: Sun Jan 23, 2011 12:02 am

Unless you're on an AS/400 platform (where COMP is Packed-Decimal), on a Mainframe, COMP-3 is Packed-Decimal.

Technically, under Mainframe, the maximum value that can be moved to a PIC S9(04) COMP field is +32767. However, if you compile the program using TRUNC(OPT) instead of TRUNC(BIN), high-order truncation will occur on a PIC S9(04) COMP field, because it's based upon the picture clause. So, this maximum is +9999.

With at, 75324 moved to a binary-halfword, will get truncated, regardless of the TRUNC option used.

S9(04) COMP is referred to as a signed binary-halfword (max value +32767), 9(04) COMP is an unsigned binary-halfword, which has a maximum value of 65535. But regardless, high-order truncation will always occur with TRUNC(OPT). A binary-halfword is always two-bytes.

To get around this, define the field as a signed binary-fullword, PIC S9(09) COMP (four bytes) and you'll get the correct answer.

Note that if your compiler supports COMP-5 (minimum of OS/390 COBOL 2.2.1), then high-order truncation will not occur as the TRUNC option has no affect.

Bill

Pankaj Gupta · New User Joined: 07 May 2008 Posts: 50 Location: Bangalore

Thank you very much. I am thinking I am understanding you in correct fashions. I very obvious should have been defining my packed field as PIC S9(5) COMP because my number it is having the 5 digits. I am apologising very large for not seeing the wooden twig because the forest is great.

Bill O'Boyle · Posted: Sun Jan 23, 2011 3:02 am

Remember, COMP is Binary, whereas, COMP-3 is Packed-Decimal.

If your compiler is at least, VS/COBOL II (about 25 years old) and greater, define packed decimal fields as PACKED-DECIMAL, instead of COMP-3 and define binary fields as BINARY, instead of COMP.

Then, you can differentiate the definitions easily.

Note, these definitions are not valid with OS/VS COBOL (even older than VS/COBOL II) and you'll need to continue using COMP and COMP-3.

Bill

Pankaj Gupta · New User Joined: 07 May 2008 Posts: 50 Location: Bangalore

Thank you for your assisting but now I became quite confused. But now I am solving the problem at last by defining the packed fields as PIC S9(5) USAGE IS DISPLAY-7 and now the additions are in good function. Thank you again.

Pankaj

Bill O'Boyle · Posted: Sun Jan 23, 2011 3:41 am

I'm not familiar with DISPLAY-7, just DISPLAY (which is also known as DISPLAY-NUMERIC by most IBM Mainframer's).

DISPLAY-7 might be allowable on IBM Mainframes (it might be the same as DISPLAY), but I've never seen it used, so it might be in the best interest of you and others, to use DISPLAY.

In any event, glad you got this to work.

Bill

Bill O'Boyle · Posted: Sun Jan 23, 2011 8:56 am

Here's the value 3521 in three different Mainframe formats, in HEX notation -

DISPLAY (4-Bytes) PIC 9(04)

dick scherrer · Posted: Sun Jan 23, 2011 10:16 am

Hello,

Pankaj Gupta · New User Joined: 07 May 2008 Posts: 50 Location: Bangalore

Thank you all most kindly for your assisting in this problem.

I was not understanding that the additions on the mainframe are not being reliable. This must explain the queer answers I was before obtaining.

I have now formulated a fine solution based on Mr Bill's comments which is working I am thinking. But also I have another idea for a truly use again solution that later I will be explaining. But in first beginning shall I explain my coding based on Mr Bill's method:

First I am defining some variable storages:

dick scherrer · Posted: Tue Jan 25, 2011 4:06 am

Hello,

Bill O'Boyle · Posted: Tue Jan 25, 2011 4:12 am

I have to ask the following -

Are you attempting to test for a bit being "ON" and then set a C'1' in a corresponding table element?

Otherwise, what the heck are you doing?

Bill

dick scherrer · Posted: Tue Jan 25, 2011 4:16 am

Hi Bill,

Pankaj Gupta · New User Joined: 07 May 2008 Posts: 50 Location: Bangalore

No Bill, Sir, I was trying to follow your example of setting the variable to 3521 by instead moving X'F3F5F2F1' to the variable.

So I am looking at each digit one by the next one and if it is having the value 1 then I am moving X'F1' and if it is having the value 5 then I am moving the value X'F5' until I am building up the complete variable with the hex bitmaps as I have seen in your example.

Than I am adding them together as I now understand it is more accurate to be adding X'F7F5F3F2F4' and X'F3F5F2F1' than to be adding 75324 and 3521.

I suppose that this is because this way the numbers are being already in the computing language for optimised usage.

Mr Dick sir, yes I am working on an IBM mainframes. The display-7 is in my college cobols course so with this we should be fine. But gladly I will not use it if you think it would be working better.

I am trying to do additions on 2 numbers, that is all. I am apologising for seeming not to be clear.

Thank you again.

Mickeydusaor · Posted: Tue Jan 25, 2011 4:49 am

Bill, Dick I am with you. I looked a the Z/os cobol manuals and I mean
I never found any reference to and such DISPLAY-7.

Robert Sample · Posted: Tue Jan 25, 2011 5:44 am

dick scherrer · Posted: Tue Jan 25, 2011 7:27 am

Hello,

Pankaj Gupta · New User Joined: 07 May 2008 Posts: 50 Location: Bangalore

Thank you mr Dick.

This is seeming very simple.

Am I needing to first convert my decimal numbers for the additions to the hex system, or is the mainframe already understanding the decimal formations?

dick scherrer · Posted: Thu Jan 27, 2011 10:26 am

Hello,

dbzTHEdinosauer · Posted: Thu Jan 27, 2011 2:55 pm

UmeySan · Posted: Thu Jan 27, 2011 4:29 pm

Hi gent's !

DISPLAY-7 is mentioned in the ILE COBOL Reference Summary.

Has to do with WebSphere Development Studio.

Pankaj Gupta · New User Joined: 07 May 2008 Posts: 50 Location: Bangalore

With all respects, I am a professional in the ibm mainframes environments.

As can be seen at the top of this string, the only reason why then my additions were not working was because one of my fields was one number short.

Then I was getting confused by someone saying I must be converting my numbers to the hex system and then somehow it seemed that I must be writing my own additions subroutine. And then even to me this seemed strange, but always I take off my hat to the people with the larger experience.

Now I have decided not to use the display-7 fields, which, I am understanding, date from the 1980s and perhaps before.

enrico-sorichetti · Posted: Fri Jan 28, 2011 5:30 am

Robert Sample · Posted: Fri Jan 28, 2011 6:33 am

COBOL understands decimal numbers perfectly well. As long as you obey the rules, the results of any arithmetic operation are perfectly predictable. The rules are clearly laid out in the COBOL Language Reference manual. However, if you do things like move values too large for the PICTURE to a variable, then you cannot expect the results to be predictable -- repeatable, yes, but not necessarily predictable.

I've only been working with COBOL since 1975 and so far I've never had a reason to develop any kind of arithmetic routine for COBOL -- the existing operations have all worked perfectly well for over 35 years so far. The odds that you've found an exception are extremely low. It is far more likely that you are ignoring the standard ways of doing things in favor of doing things your own way. This introduces unnecessary risk to your project and your site since your way cannot possibly be tested as well as the standard routines.