|
View previous topic :: View next topic
|
| Author |
Message |
nanny
New User
Joined: 13 Jun 2006
Posts: 14
Location: India
|
|
|
|
Hi,
I have a cobol variable defined as follows.
| Code: |
10 WS-KEY PIC S9(4) COMP.
|
I have two fields
1. A Group-Number value ranging from 0 to 255 and this value is moved to the first byte of the WS-KEY
2. A File-Number value ranging from 0 to 255 and this value is moved to the second byte of the WS-KEY
3. If the Group-number doesn't exists then I have to move the File-Number to the First Byte (Not to the second Byte)
Re-Code'd |
|
| Back to top |
|
 |
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| Thank you for that description of your requirement. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Congratulations and good luck with your code.
Seriously, you asked no questions, indicated no problems, so just why did you post on this forum? |
|
| Back to top |
|
|
nanny
New User
Joined: 13 Jun 2006
Posts: 14
Location: India
|
|
|
|
Robert,
Sorry for some confusion.
WS-KEY field takes 2 bytes to store the data. And I want to split these two bytes into two 1byte fields and I want to move two different values to each of these 1 bytes. (As these values are less than 256). |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Several ways. REDEFINEing is going to be necessary, as two PIC X fields.
You need a similarly defined and REDEFINEd field.
MOVE your first value to the new COMP field then move the 2nd byte of the REDEFINEs of the new field to the first bye of the REDEFINEs for your original. Repeat, with the second data going to the second REDEFINEd field of the original.
If you only have the second data, MOVE ZERO to the original field, or LOW-VALUES to the second REDEFINEd byte of the original field, and your actual data, as in the paragraph above, to the first byte. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
You still have not indicated any problems.
Since REDEFINES is well documented in the COBOL Language Reference manual, and that manual is available via the Manuals link at the top of this page, I guess the first question is ... have you read about REDEFINES? If not, start reading. If you have, then you need to specify your question more precisely. I'm pretty sure there has been code posted before on this forum that does what you are talking about, too. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| nanny wrote: |
Robert,
Sorry for some confusion.
WS-KEY field takes 2 bytes to store the data. And I want to split these two bytes into two 1byte fields and I want to move two different values to each of these 1 bytes. (As these values are less than 256). |
Well.
First, remember that unless you compile with TRUNC(BIN), your value will be limited by the picture (i.e., to 9,999) despite the size of the variable; give it usage of COMP-5.
Second, as it is signed, a group variable greater than 127 will be interpreted as a negative number; make the key unsigned.
Then your code becomes:
| Code: |
IF GROUP-NUMBER-EXISTS
COMPUTE WS-KEY = (GROUP-NUMBER * 256) + FILE-NUMBER
ELSE
COMPUTE WS-KEY = FILE-NUMBER * 256
END-IF
|
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
The COMP-5 point is a good one (TRUNC(BIN) generates lots of extra code, but if that is the site standard, you don't need the COMP-5). As long as nothing does anything to the WS-KEY, the code will "work", but it is too easy for someone to mess up later and "do something" with it. Defining it as COMP-5 and documenting that it can have a value greater than 9999 is good practice. Same for the sign. Make it unsigned, and document why, as it is important.
Ah. The multiplication. Certainly needs COMP-5/TRUNC(BIN) and unsigned and will certainly work. The seperate MOVEs will be more alacrous (this spell-checker doesn't seem to think that that is a word) and with good names will be as clear.
There are other ways, as well... |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| Bill Woodger wrote: |
| (TRUNC(BIN) generates lots of extra code, but if that is the site standard, you don't need the COMP-5). |
And then someone comes along and says, "You know, TRUNC(BIN) generates lots of extra code; let's use TRUNC(OPT) and give anything that really needs it usage of COMP-5"... 
(ETA: Generally, I only like to use binary (or decimal!) fields for genuinely computational data. Defining a phone number as COMP-3 or FIXED DEC is asking for a call from Operations at 0-dark-thirty.) |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Some site which considers changing their standard from TRUNC(BIN) to TRUNC(STD) or TUNC(OPT) and who doesn't then do the necessary work... I'm available to help sort it all out :-)
Yes, the COMP-5 remains a good idea. The even better idea, you have pointed to and I also agree. Define it as PIC X and PIC X, forget all about making it numeric, there is no need to. No need to worry about COMP-5 or TRUNC(anything). The COMPUTE no longer works...
I have to "have a smile" when a record-layout comes along and it has ACCOUNT-NUMBER PIC 9(14), CUSTOMER-NUMBER PIC 9(5), PART-NUMBER-NUMERIC PIC 9(7) PART-NUMBER-ALPHA PIC XX, etc.
If there is to be no calculation, why make it numeric? All that "sign-fixing", particularly with NUMPROC(NOPFD), is just waste. You need it numeric at some point? There's always REDEFINES, or MOVE to another PIC X(...) with a REDEFINES. |
|
| Back to top |
|
|
nanny
New User
Joined: 13 Jun 2006
Posts: 14
Location: India
|
|
|
|
Hi All,
Thank you very much for the timely responses.
I tried with the multiplication method and it is working.
Thanks,
Ramesh. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
How did I guess that that would happen?
| Code: |
IF
D501 8028 A008 CLC 40(2,8),8(10)
4770 B136 BC 7,310(0,11)
COMPUTE
4830 8030 LH 3,48(0,8)
4C30 A014 MH 3,20(0,10)
1033 LPR 3,3
4030 8018 STH 3,24(0,8)
47F0 B148 BC 15,328(0,11)
GN=4 EQU *
COMPUTE
4830 8028 LH 3,40(0,8)
4C30 A014 MH 3,20(0,10)
4A30 8030 AH 3,48(0,8)
1033 LPR 3,3
4030 8018 STH 3,24(0,8)
GN=5 EQU *
IF
D501 8028 A008 CLC 40(2,8),8(10)
4770 B160 BC 7,352(0,11)
MOVE
D200 8020 8031 MVC 32(1,8),49(8)
MOVE
9200 8021 MVI 33(8),X'00'
47F0 B16C BC 15,364(0,11)
GN=6 EQU *
MOVE
D200 8020 8029 MVC 32(1,8),41(8)
MOVE
D200 8021 8031 MVC 33(1,8),49(8)
|
Nine instructions for the COMPUTEs, including two multiplies, four instructions for the MOVEs :-) (and this is assuming the Group and File are binary).
Oh, well, big, fast machines, and the Client pays anyway.
When there is no Group, the File is effectively a Group? Seems a curious way to do it. Can the values of Group/File "clash"? Do you then have to have lots of "if the File is zero, it is a File" if you ever do "get me all the records for a Group"? |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
