topic Re: COBOL REDEFINE question in Operating System - OpenVMS

COBOL REDEFINE question

Homer Shoemaker — Thu, 29 Jan 2009 16:44:53 GMT

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?

Re: COBOL REDEFINE question

Homer Shoemaker — Thu, 29 Jan 2009 17:36:01 GMT

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??

Re: COBOL REDEFINE question

Hein van den Heuvel — Thu, 29 Jan 2009 18:17:54 GMT

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.

Re: COBOL REDEFINE question

Hein van den Heuvel — Thu, 29 Jan 2009 18:24:27 GMT

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.

Re: COBOL REDEFINE question

Homer Shoemaker — Thu, 29 Jan 2009 20:18:45 GMT

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.

Re: COBOL REDEFINE question

Homer Shoemaker — Thu, 29 Jan 2009 20:29:05 GMT

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.