IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Doubt corresponding with packed field


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Pankaj Gupta
Currently Banned

New User


Joined: 07 May 2008
Posts: 50
Location: Bangalore

PostPosted: Sat Jan 22, 2011 11:28 pm
Reply with quote

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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Sun Jan 23, 2011 12:02 am
Reply with quote

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
Back to top
View user's profile Send private message
Pankaj Gupta
Currently Banned

New User


Joined: 07 May 2008
Posts: 50
Location: Bangalore

PostPosted: Sun Jan 23, 2011 2:53 am
Reply with quote

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.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Sun Jan 23, 2011 3:02 am
Reply with quote

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
Back to top
View user's profile Send private message
Pankaj Gupta
Currently Banned

New User


Joined: 07 May 2008
Posts: 50
Location: Bangalore

PostPosted: Sun Jan 23, 2011 3:32 am
Reply with quote

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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Sun Jan 23, 2011 3:41 am
Reply with quote

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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Sun Jan 23, 2011 8:56 am
Reply with quote

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

DISPLAY (4-Bytes) PIC 9(04)
Code:

X'F3F5F2F1'

SIGNED PACKED-DECIMAL (3-Bytes) PIC S9(05) PACKED-DECIMAL
Code:

X'03521C'

SIGNED BINARY-HALFWORD (2-Bytes) PIC S9(04) BINARY
Code:

X'0DC1'

HTH....

Bill
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sun Jan 23, 2011 10:16 am
Reply with quote

Hello,

Quote:
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
You need to spend whatever time is necessary to clear this confusion. . . You may have something running, but possibly not something that will work on most IBM mainframes.

Suggest you post the text from the manual you used to learn about "display-7" - i have never seen this in an IBM mainframe compiler.

It may also help if you post the code that finally ran as you wanted.
Back to top
View user's profile Send private message
Pankaj Gupta
Currently Banned

New User


Joined: 07 May 2008
Posts: 50
Location: Bangalore

PostPosted: Tue Jan 25, 2011 3:07 am
Reply with quote

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:
Code:


01  WS-X        PIC 9     USAGE IS DISPLAY-7
01  WS-Y        PIC 9     USAGE IS DISPLAY-7
01  WS-Z        PIC 9     USAGE IS DISPLAY-7

01  WS-ADD1  PIC 9(5) USAGE IS DISPLAY-7
01  WS-ADD2  PIC 9(5) USAGE IS DISPLAY-7

01  WS-NUMBER        PIC 9(5) USAGE IS DISPLAY-7
01  WS-NUMBER-R REDEFINES WS-NUMBER.
  03  WS-NUMBERS    PIC X OCCURS 5 TIMES.

01  WS-NUMBER1        PIC 9(5) USAGE IS DISPLAY-7
01  WS-NUMBER1-R REDEFINES WS-NUMBER1.
  03  WS-NUMBER1-BITMAP   PIC X OCCURS 5 TIMES.
   
01  WS-NUMBER2        PIC 9(5) USAGE IS DISPLAY-7
01  WS-NUMBER2-R REDEFINES WS-NUMBER2.
  03  WS-NUMBER2-BITMAP   PIC X OCCURS 5 TIMES.


Then I am defining the hex bitmap fields. I am not fully comprehending why we must be using these bitmaps but it as Mr Bill IS recommending:

Code:

01  WS-HEX-BITMAPS.
  03  WS-HEX-BITMAP1   PIC X VALUE X'F1'.
  03  WS-HEX-BITMAP2   PIC X VALUE X'F2'.
  03  WS-HEX-BITMAP3   PIC X VALUE X'F3'.
  03  WS-HEX-BITMAP4   PIC X VALUE X'F4'.
  03  WS-HEX-BITMAP5   PIC X VALUE X'F5'.
  03  WS-HEX-BITMAP6   PIC X VALUE X'F6'.
  03  WS-HEX-BITMAP7   PIC X VALUE X'F7'.
  03  WS-HEX-BITMAP8   PIC X VALUE X'F8'.
  03  WS-HEX-BITMAP9   PIC X VALUE X'F9'.
  03  WS-HEX-BITMAP10  PIC X VALUE X'F0'.
01  WS-HEX-BITMAPS-R REDEFINES WS-HEX-BITMAPS.
  03  WS-HEX-BITMAP PIC X OCCURS 10 TIMES.


Then in my code we are seeing:

Code:
    MOVE 75324 TO WS-ADD1
    MOVE 3521   TO WS-ADD2

    MOVE WS-ADD1 TO WS-NUMBER
    MOVE 1 TO NUMBER
    PERFORM CONVERT-TO-BITMAPS

    MOVE WS-ADD2 TO WS-NUMBER
    MOVE 2 TO NUMBER
    PERFORM CONVERT-TO-BITMAPS

    ADD WS-NUMBER1 WS-NUMBER2 GIVING WS-RESULT.

CONVERT-TO-BITMAPS SECTION.

    PERFORM MOVE-BITMAPS VARYING WS-X FROM 1 BY 1 UNTIL WS-X > 5.

CONVERT-TO-BITMAPS-EXIT.
    EXIT.

MOVE-BITMAPS SECTION

    MOVE WS-X TO WS-Y
    MOVE WS-NUMBERS(WS-Y) TO WS-Z.
    IF WS-Z = 0
       MOVE 10 TO WS-Z.
    IF NUMBER = 1
       MOVE WS-HEX-BITMAP(WS-Z) TO WS-NUMBER1-BITMAP(WS-X)
    ELSE
       MOVE WS-HEX-BITMAP(WS-Z) TO WS-NUMBER2-BITMAP(WS-X).

MOVE-BITMAPS-EXIT.
    EXIT.


This is seeming very complex but I am understanding it is being needful to ensure that the coding will be running on all mainframes. You will be seeing I have been keeping the codings as simple as it is possible by utilising the redfines and table processing.

I am having even a more simpler solution with a reuse subroutine and SQLs to do the additions. I will be posting this after when I will finish the coding and testing.

Thank you again for your kind help.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Jan 25, 2011 4:06 am
Reply with quote

Hello,

Quote:
I was not understanding that the additions on the mainframe are not being reliable.
This is utter nonsense. . . Of course "additions" on the mainframe ARE reliable - as long as correct code is executed.

I suspect that there are several trillion dollars worth of transactions every day that are calculated correct to the penny. . .

Is there some reason you did not post the quote from the COBOL manual that shows this display-7?

It appears that you are still just "winging it" and hoping for the best.

If you show a bit of sample input and the calculation(s) [not code] you want performed on this, someone should be able to clarify.

If you are not working on an IBM mainframe, you should find a forum that supports your environment.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Tue Jan 25, 2011 4:12 am
Reply with quote

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
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Jan 25, 2011 4:16 am
Reply with quote

Hi Bill,

Quote:
Otherwise, what the heck are you doing?

Trying to ensure job security. . .?
No one else on the mainframe will have a clue. . .
If this is a mainframe icon_confused.gif

d
Back to top
View user's profile Send private message
Pankaj Gupta
Currently Banned

New User


Joined: 07 May 2008
Posts: 50
Location: Bangalore

PostPosted: Tue Jan 25, 2011 4:33 am
Reply with quote

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.
Back to top
View user's profile Send private message
Mickeydusaor

Active User


Joined: 24 May 2006
Posts: 258
Location: Salem, Oregon

PostPosted: Tue Jan 25, 2011 4:49 am
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jan 25, 2011 5:44 am
Reply with quote

Quote:
I was not understanding that the additions on the mainframe are not being reliable.
I have never heard of any fixed point addition on the mainframe having any problems (unless overflow occurs, of course) -- they are as reliable as they can be. The original post you made appeared to be due to truncation -- on an IBM COBOL compiler, depending upon the value for the compiler option TRUNC, a variable may not be allowed to store more digits than the PICTURE clause. If this is the case, moving 75324 to a PIC S9(04) variable will change the number to 5324 since only the last 4 digits would be kept.

What is the mainframe you are using? The specific machine and model number will tell us much. I ask specifically because DISPLAY-7 is not a supported variable type in IBM z/OS COBOL even though it is valid on some platforms.

This becomes important because different machines implement COBOL differently, and something that depends upon bit patterns (for example) on an IBM z/OS machine will likely fail miserably (or at least give erroneous results) running on a VAX machine or a PC.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Jan 25, 2011 7:27 am
Reply with quote

Hello,

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

Show some actual input data. . . 2 fields you want to add. . . In hex if necessary. . .

This is how addition can be accomplished:
Code:
01 SOME-STUFF.
   05 ONE-NUMBER-SS PIC S9(5)V99.
   05 ANOTHER-SS    PIC S9(5)V99.
   05 A-TOTAL-SS    PIC S9(7)V99.

COMPUTE A-TOTAL-SS = ONE-NUMBER-SS + ANOTHER-SS.
Assuming the first 2 fields have valid numeric values, that is a very simple way to add 2 numbers.

Why will this not work for you icon_confused.gif
Back to top
View user's profile Send private message
Pankaj Gupta
Currently Banned

New User


Joined: 07 May 2008
Posts: 50
Location: Bangalore

PostPosted: Thu Jan 27, 2011 4:25 am
Reply with quote

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?
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Jan 27, 2011 10:26 am
Reply with quote

Hello,

Quote:
This is seeming very simple.
Arithmetic operations should not be difficult. . .

You properly define the fields and then name them in the calculations. Your properly defining the fields and executing the proper code is all that it takes.

Suggest you spend a bit of time creating several test cases with different data definitions and values and do some arithmetic to actually see this happen.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Jan 27, 2011 2:55 pm
Reply with quote

Pankaj Gupta wrote:
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?


suggest you go to the programming guide and learn the fundamentals.

a professional reads the documentation for each new environment he encounters.
most of your questions are a result of you making assumptions and
not familiarizing yourself with your new environment.
Back to top
View user's profile Send private message
UmeySan

Active Member


Joined: 22 Aug 2006
Posts: 771
Location: Germany

PostPosted: Thu Jan 27, 2011 4:29 pm
Reply with quote

Hi gent's !

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

Has to do with WebSphere Development Studio.
Back to top
View user's profile Send private message
Pankaj Gupta
Currently Banned

New User


Joined: 07 May 2008
Posts: 50
Location: Bangalore

PostPosted: Fri Jan 28, 2011 4:26 am
Reply with quote

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.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Fri Jan 28, 2011 5:30 am
Reply with quote

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


You might be a professional but You still need to learn how to read the answers You get icon_biggrin.gif
nobody, repeat nobody suggested You to write Your own addition routines.

the hex reference was only to show You how the most common cobol representation of numbers are stored in memory...
and the only way to understand is to to show their hexadecimal values

also it funny that a professional would think that in the Anno Domini 2011
somebody should , when using a high level language, write their own addition and simple conversion routines...
even in assembler to convert from zoned to packed a single instruction is all that is needed and the same is true also to convert from packed to binary icon_cool.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Jan 28, 2011 6:33 am
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace Multiple Field values to Othe... DFSORT/ICETOOL 12
No new posts PD not working for unsigned packed JO... DFSORT/ICETOOL 5
No new posts Def PD not working for unsigned packe... JCL & VSAM 3
No new posts Join 2 files according to one key field. JCL & VSAM 3
No new posts Need Help with Packed Decimal Signs DFSORT/ICETOOL 4
Search our Forums:

Back to Top