Re: Multi- Occurrence Data Structure

john e wrote:

4. RE: Multi- Occurrence Data Structure (john e)

date: Wed, 12 Dec 2007 11:26:33 +0100

I don't know if it's "official" (whatever that means) but i would say that MODS should be considered depricated and the use of it is bad practice, for several reasons.

Except, of course, for cases where nothing else will do well but a MODS.

I've twice run into large old programs that needed enhancements where complex data structures needed to be duplicated. (Complex -- think of mandated federal reporting standards.) The enhanced structures were essentially like two records, e.g., a before- and after-image.

I could have made them into arrays and gone through every bleepin' reference for each subfield through the program source and added an array index qualifier if I had time, but no time was allocated for such extensive work. Likewise, I could have created new fields -- SaveFld1, SaveFld2, SaveFld3, etc. -- and added code to save the old values, done the work, restored the old values, etc.; but again, the time for extensive change was limited. Thousands of lines of code; many, many field references.

It was _far_ easier simply to give the structure an OCCURS(2) and set the occurrence number when needed in the added enhancement sections. There was no need for mucking around changing source that I wasn't actually 'changing'. The programs were old and ugly already; I made only a minor additional increase in ugliness.

I know that's not a ringing endorsement of MODS, but they sure came in handy.

On a side note, I actually had a good reason to use record-identifying indicators and The Cycle a couple weeks back. I was thinking of many possible ways to do the work, including text-processing in REXX which was the leading candidate until I remembered record IDs. In the end, good ol' basic obsolete RPG was far and away the best method.

Every once in a while, the oddest features of a language can be useful.

Tom Liotta