Like over linkage section data

[TedHolt]

Re: Like over linkage section data

BTW, I went ahead with a COPY in place and it worked as expected. Too bad something like malloc is needed, but at least it only requires the two special registers and the SPECIAL-NAMES entry.

Too much sugar for a dime.

[JonBoy]

Re: Like over linkage section data

...
BTW, I went ahead with a COPY in place and it worked as expected. Too bad something like malloc is needed, but at least it only requires the two special registers and the SPECIAL-NAMES entry.

You don't need malloc Tom - there's nothing to prevent you from using WS or even File section defined variables as the address source for Linkage Items. As long as you ensure that PROCEDURE DIVISION USING ... doesn't reference any of the variables.

[tomliotta]

Re: Like over linkage section data

there's nothing to prevent you from using WS or even File section defined variables as the address source for Linkage Items.

Yes, but how do you get the LIKE to work over the given LINKAGE item? I realize that the address can be grabbed if one exists, but you can't define a WS item LIKE a LINKAGE item, right?

What Ted had was a COPY for a large group item in LINKAGE. Then he wanted just one or two elementary items declared LIKE one or two subordinates of the LINKAGE group, apparently without having to declare the whole group in WS. I'm not aware of a COBOL feature similar to RPG's TEMPLATEs to provide definitions without allocating memory, so malloc seemed to be appropriate. That is, there would be no WS nor FILE item that can be referenced.

Not true? Is there an alternative? It seems Ted and I were primarily exploring options to get around the restriction that LIKE has to reference a "previously defined" item and the initial definition was in LINKAGE.

[JonBoy]

Re: Like over linkage section data

I'd just accept the compiler limits and do it backward i.e. use the full copy in both WS and Linkage. It is not like we're talking about a huge chunk of memory.

If the copy consists of all the subfields and not the 01 level you can have the same field definitions in both places.

If memory is a major concern (which it doesn't seem to be here) the the closest to RPG's Template system would be to have a dummy File Section FD and use it to supply an external description for all the fields. Unlike RPG, COBOL won't allocate memory to the fields until the file is opened (in COBOL fields are mapped directly into the actual buffer).

If I remember correctly the old compiler could accept backward references and the ILE one was supposed to do the same thing. For a variety of reasons that requirement dropped out of the specification at some point and although I had a major bitch session about when I heard, it it was too late because it would have meant major changes in the underlying compiler architecture.

[tomliotta]

Re: Like over linkage section data

I might do the same, though I figure Ted is well aware of the trade-offs. Take up a debate with him if you think it's of interest here. I'm not sure enough from the info available so far. A malloc or two isn't a big cost; it's just a way that works according to the request (and a way to get others to add thoughts or make corrections.)