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)
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).
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.
Joined: 06 Jun 2008 Posts: 8696 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.
Joined: 03 Oct 2009 Posts: 1788 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.
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.
Joined: 03 Oct 2009 Posts: 1788 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.)
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.
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"?
