Portal | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref

 Doubt corresponding with packed field Goto page 1, 2  Next
Author Message
Pankaj Gupta
Currently Banned

New User

Joined: 07 May 2008
Posts: 50
Location: Bangalore

 Posted: Sat Jan 22, 2011 11:28 pm    Post subject: Doubt corresponding with packed field 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

CICS Moderator

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

 Posted: Sun Jan 23, 2011 12:02 am    Post subject: Reply to: Doubt corresponding with packed field 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
Currently Banned

New User

Joined: 07 May 2008
Posts: 50
Location: Bangalore

 Posted: Sun Jan 23, 2011 2:53 am    Post subject: 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

CICS Moderator

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

 Posted: Sun Jan 23, 2011 3:02 am    Post subject: Reply to: Doubt corresponding with packed field 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
Currently Banned

New User

Joined: 07 May 2008
Posts: 50
Location: Bangalore

 Posted: Sun Jan 23, 2011 3:32 am    Post subject: 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

CICS Moderator

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

 Posted: Sun Jan 23, 2011 3:41 am    Post subject: Reply to: Doubt corresponding with packed field 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

CICS Moderator

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

Posted: Sun Jan 23, 2011 8:56 am    Post subject: Reply to: Doubt corresponding with packed field

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
dick scherrer

Moderator Emeritus

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

Posted: Sun Jan 23, 2011 10:16 am    Post subject:

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.
Pankaj Gupta
Currently Banned

New User

Joined: 07 May 2008
Posts: 50
Location: Bangalore

Posted: Tue Jan 25, 2011 3:07 am    Post subject:

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

Moderator Emeritus

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

Posted: Tue Jan 25, 2011 4:06 am    Post subject:

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.
Bill O'Boyle

CICS Moderator

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

 Posted: Tue Jan 25, 2011 4:12 am    Post subject: Reply to: Doubt corresponding with packed field 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

Moderator Emeritus

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

Posted: Tue Jan 25, 2011 4:16 am    Post subject: Reply to: Doubt corresponding with packed field

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

d
Pankaj Gupta
Currently Banned

New User

Joined: 07 May 2008
Posts: 50
Location: Bangalore

 Posted: Tue Jan 25, 2011 4:33 am    Post subject: 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

Active User

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

 Posted: Tue Jan 25, 2011 4:49 am    Post subject: 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

Global Moderator

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

Posted: Tue Jan 25, 2011 5:44 am    Post subject:

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

Moderator Emeritus

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

Posted: Tue Jan 25, 2011 7:27 am    Post subject:

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
Pankaj Gupta
Currently Banned

New User

Joined: 07 May 2008
Posts: 50
Location: Bangalore

 Posted: Thu Jan 27, 2011 4:25 am    Post subject: 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

Moderator Emeritus

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

Posted: Thu Jan 27, 2011 10:26 am    Post subject:

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

Global Moderator

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

Posted: Thu Jan 27, 2011 2:55 pm    Post subject:

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

Active Member

Joined: 22 Aug 2006
Posts: 771
Location: Germany

 Posted: Thu Jan 27, 2011 4:29 pm    Post subject: Hi gent's ! DISPLAY-7 is mentioned in the ILE COBOL Reference Summary. Has to do with WebSphere Development Studio.
 All times are GMT + 6 HoursGoto page 1, 2  Next
 Page 1 of 2

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics BMS map length field greater than zero Ziko13 CICS 3 Fri Oct 09, 2020 5:40 pm Break a record into fields, each fiel... jackare SYNCSORT 2 Thu Oct 08, 2020 5:26 am SYNCSORT Error - CONTROL FIELD BEYOND... arunn SYNCSORT 10 Sun Oct 04, 2020 4:10 pm How do i verify the char field is hav... Raghu M N PL/I & Assembler 1 Tue Sep 22, 2020 9:26 pm RPLDDDD field for extended VSAM - ESDS amitsjcntl JCL & VSAM 0 Tue Sep 22, 2020 1:45 pm

 © 2003-2020 IBM MAINFRAME Software Support Division
 Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us