MVSFORUMS.com

[misi01]

First of all, a simple, stripped-down program that illustrates the problem.

[William Collins]

You have what is called a Complex ODO (you have data-definitions following an ODO under the same 01-level, meaning those data-items are variably-located).

NOTERINGAR_RUBRIK1 exists only once, it has a fixed length, but it has 51 potential locations depending on ix-placeringsprofil. When you did you MOVE, you only set the first of those (or whatever ix-placeringsprofil happened to contain - actually, looking at ix-placeringsprofil, it has no defined value by the time you do the MOVE of space, it is packed-decimal, so you are either using NUMPROC(NOPFD) as a compile option, or you got (and continue to get) extremely lucky)).

The fix I suggest is to use fixed-length OCCURS for all your preparation of the data. Once that is complete, immediately before the generation of the XML (I'm guessing that is why you want the ODO, to not have "empty" entries) then, and only then, set up the data in the variable-length occurs.

It will greatly simplify things, take a lot of technical clutter away, leaving just the business processing and your program easier to understand.

The alternative, which is absolute standard, is to MOVE all (as in all) the items which follow an ODO-group to a location to save them. Change the ODO value. Then MOVE them back to their original names. The position of the data will have changed. To preserve the content, you have to go through that.

Micro Focus's ODOSLIDE does that processing for you (as I understand it). There is no IBM COBOL that has an equivalent option or functioning.

I'm curious as to why you have a mixture of usages for you loop-control/subscripting, but that's something else.

[misi01]

In answer to your questions/comments.

NUMPROC(NOPFD) - correct, this is the default compiler option here

[William Collins]

What I'm suggesting is that you use fixed-size OCCURS while you are "loading" and doing whatever else you need with the data.

Then. After all that is complete. Set up the table lengths and copy the data from the fixed-length table to the variable-length table, so you can generate the XML without having to remove unused items.

That way you have the data-manipulation made without the additional complexity of the ODO, and the XML generated without the need to remove "empty" items.

Your program will be smaller, simpler, and easier to understand (the ODOs only existing to ease the production of the XML).

[misi01]

Aha ..... (eureka moment). That would make it a LOT simpler I think. I'll certainly give it a go and get back to you. Thanks a lot
_________________
Michael

[misi01]

I'll include the logic here so it might be of use to others.

First all, the actual XML document (I'll only include the first few entries since the rest is the same)

[William Collins]

Thanks for posting the code.

Updating the ODO values as you go along will work, as will copying the final values once you know them. I prefer the latter, firstly because it used to be a more efficient way to do it (IBM compilers recalculated lengths with the ODO values changed, they now only do it when making a reference requires the current length of the table) and secondly because an unwary maintainer doesn't have to keep two things in step.

I'd also do the final MOVEs to the table in the order you chose, because it seems clearer. However, as long as all the ODO values are set before starting the MOVEs, the order does not matter in this type of case. As soon as you have code which changes a prior ODO value, whilst you already have data in the table, that is where you get the problem.

There is an Appendix in the Programming Guide which deals with Complex ODOs. I guess the use of ODO will be expanding, exactly as the use of XML generation expands. Many people trip up with ODOs, so good to have your example.

Note, the Complex ODO is an IBM Extension. from the Appendix on Extensions in the Language Reference:

[kolusu]

misi01,

You may want to read this which describes with examples about modifying and referring variable ODO objects.

Complex OCCURS DEPENDING ON
_________________
Kolusu
www.linkedin.com/in/kolusu

[misi01]

Thanks Kolusu. Good link, pity I never found it in my searches
_________________
Michael

[William Collins]

Noticed now, with COBOL V5, the Complex ODO is no longer in an Appendix, but in the body of the Programming Guide.

The problem in Kolusu's link, that of an index on a variable-length item, occurs only when an ODO is subordinate to another table (OCCURS or OCCURS DEPENDING ON). Yes, the length of the subordinate table changes, but it is the concomitant change in length of the item with the INDEXED BY which is the problem. True, you can't have one without the other, but the documentation is a little unclear.

The save, change ODO value, restore for the index is analagous to the save, change ODO value, restore to preserve data which follows an ODO within the same 01-level. However, that does not mean the index-preserving has to be done for all indexes on an ODO.

In Michael's final sample code, the index-preserving technique would not be required (and use would therefore confuse), as all the OCCURS items themselves are fixed-length.

[misi01]

William, just so there's no confusion, your last sentence "the index_preserving technique....." is only relevant with Cobol 5 ????? (Or am I missing something that would make code even easier in cobol 4)
_________________
Michael

[William Collins]

Sorry, no, the index-preserving technique is only relevant when a table is variably located (and only impacts when the start-position of the tale changes. This is the same in all versions of Enterprise COBOL. I'll try to clarify here, and look at editing the original.

The point about V5 was that the text had been "promoted" from an Appendix to the main body of the manual, perhaps supporting the idea of an expectation of Complex ODO usage becoming more common.

That is, if there is an ODO within a table (whether or not the table it is within is also an ODO).