COBOL REDEFINE question

[Homer Shoemaker]

15 ORDER-OVRCHG-FIELDS.
20 ORDER-OVRCHG-ITEM-SW PIC X.
88 ORDER-OVRCHG-ITEM VALUE "O".
20 ORDER-OVRCHG-OFFSET-CUST PIC X(06).
20 ORDER-OVRCHG-OFFSET-NO PIC X(08).
20 ORDER-OVRCHG-CUST-ID PIC X(06).


15 ORDER-DROP-SHIP-ITEM-PO-STATUS REDEFINES
ORDER-OVRCHG-FIELDS.
20 ORDER-PO-LN-ITM-ADDED-SW PIC X.
88 PO-LN-ITM-ADDED VALUE "Y".
88 PO-LN-ITM-NOT-ADDED VALUE "N".
20 ORDER-PO-LN-ITM-PO-QTY PIC S9(6)V9(2) COMP-3
20 FILLER (here is the question)



These fields are in the middle of a record.

1) Do I even need to fill out the rest of the NEW field to equal the space taken up by the original field?

2) If so, how many PIC X's do I need?

I think the answers are Yes, and eight. Is that right?

[Homer Shoemaker]

Actually, eight is how many bytes I think the order-po-ln-itm-qty field takes up. That would leave pic x(12) to fill up the group.


And it takes up eight because all comp-3's take up eight bytes (IA64).


Correct??

[Hein van den Heuvel · Accepted solution]

Hello Homer,

Yuck. Ugly file.

Anyway, just ask the compiler nicely!

COBO/LIST/MAP=[ALPH|DECL] /OBJ=NL:

If I add a little 01 in front of your structure, and added pic X after each, it shows exactly where you are, and how you do not have to fill out the re-define.

What you may want to do is put a 7-byte filler BEFORE to COMP-3 field to align that, although there is little point as it is ODD sized itself. Unless you have 10 billion instances of this, why not change that COMP-3 to a simple COMP!
"waste" a nibble in storage, gain performance and reduce executable size.

You may even want to add an other 15 redefine to set an 'outer boundary' for either flavor.

For the record source included below, here is what I get, re-arranged in an attempt to humor ITRC forum formatting:


Lvl Pos Siz Byt Name
--- --- --- --- -----------------------------
01 000 023 023 TEST_RECORD
15 000 022 022 ORDER-OVRCHG-FIELDS
20 000 001 001 ORDER-OVRCHG-ITEM-SW
20 001 006 006 ORDER-OVRCHG-OFFSET-CUST
20 007 008 008 ORDER-OVRCHG-OFFSET-NO
20 00F 006 006 ORDER-OVRCHG-CUST-ID
20 015 001 001 THE-END-A
15 000 007 007 ORDER-DROP-SHIP-ITEM-PO-STATUS
20 000 001 001 ORDER-PO-LN-ITM-ADDED-SW
20 001 008 005 ORDER-PO-LN-ITM-PO-QTY
20 006 001 001 THE-END-B
15 016 001 001 THE-END



hth,
Hein.


01 test_record.
15 ORDER-OVRCHG-FIELDS.
20 ORDER-OVRCHG-ITEM-SW PIC X.
88 ORDER-OVRCHG-ITEM VALUE "O".
20 ORDER-OVRCHG-OFFSET-CUST PIC X(06).
20 ORDER-OVRCHG-OFFSET-NO PIC X(08).
20 ORDER-OVRCHG-CUST-ID PIC X(06).
20 the-end-a pic x.

15 ORDER-DROP-SHIP-ITEM-PO-STATUS REDEFINES
ORDER-OVRCHG-FIELDS.
20 ORDER-PO-LN-ITM-ADDED-SW PIC X.
88 PO-LN-ITM-ADDED VALUE "Y".
88 PO-LN-ITM-NOT-ADDED VALUE "N".
20 ORDER-PO-LN-ITM-PO-QTY PIC S9(6)V9(2) COMP.
20 the-end-b pic x.
15 the-end pic x.

[Hein van den Heuvel]

Argh, not my day...

I posted the source for a record modified to use a simple COMP, but hte MAP is for a COMP-3. Sorry.

Also, the record layout is exactly the same on Alpha and Itanium.

You would not want to have to convert/re-arrange fields when porting to itanium. Well, maybe you should, but you should not _have_ to.

Hein.

[Homer Shoemaker]

So the size of the new group item does not have to be the same as the size of the group item being redefined?


I had already modified the RD of the file (in development, of course) adding filler pic x(12) while waiting for a response.

The sample.txt attachement is a portion of the listing produced by compiling the way you said.

[Homer Shoemaker]

You know, I thought about this after I sent it.

Duh. Of course not.

Just so I don't make the new group so large that it starts to cover data in the next item in the record that I really need.


Thanks, Hein.