Gary_Cherlet

inSUBORDINATION of Subordinate Record Elements

Discussion created by Gary_Cherlet on Nov 15, 2012
Latest reply on Nov 15, 2012 by john.h.collins
Subject: gross inSUBORDINATion < from an IDMS-L discussion thread in July, 2002 - republished for info - cheers - GaryC >

i just ran into a situation that I had not seen in 13 years and, quite frankly, had forgotten about.

element-a is defined as having subordinate elements b, c, and d (none of which are defined as multiply-occuring) record-z copies element-a - thus inheriting subordinate elements b, c, and d.

At some point one of two things happened:

1) someone displayed record-z as syntax, and hard coded an OCCURS 3 for subordinate element-c (without changing element a definition) - OR -

2) someone changed element-a to have subordinate element-c occur 3 times - rebuild record-z and then change element-a back to no occurs for subo el element-c

Other work and database records maintained the non-occurs version of element-a - only one or two work records were intentionally mutilated in this manner

When I was requested to make changes to element-a - i did so – and displayed record-z "witho subo as syn verb replace" (i now see this was wrong in this circumstances - but this is how everyone else in our shop would have done it). When I replaced the record - I lost the occurs 3 on element-c's record definiton, since it did not exist in the element definition ...

is there any way to prevent someone (who has legit authority to modify records and elements) to override an element's "subordinate element" definitions (or, for that matter, change any element attribute (pic - usage) at the record element level? or is that something we just have to learn to live with ???

I guess I would prefer that if the element is used differently in different records, different elements should be used ... any thoughts?

chris hoelscher

[color=#16d710]--------------- Reply ---------------[color]

Subject: FW: gross inSUBORDINATion

I don't think there is a way to stop it but it is technically the correct way of doing it. But hardly anbody does it.

The original concept and design of the [color=#ee1111]SR-> RCDSYN -> SDR -> INQ[color] structure was to support the proper implementation of Data Analysis and Design techniques.

An INQ-058 which is an Inquiry entry and not really an element in the computing sense of the word would be identified and added at the Logical Design stage. It would represent an information item of interest in the business sense. At this stage a Picture or a Usage is irrelevant.

During the process of Physical design, the designer would collect the business items into working items called records and then assign the physical attributes within the context of the record. i.e. if it was a database record and it was a number it may be a COMP field in that record whereas in a work record used for printing it may have a DISPLAY usage. This would allow a Data Analyst to follow the progress of data through the application regardless of the storage media. (see Attachment below)

Mechanisms to simplify coding by assigning synonyms at the record, group or element level using the ELEMSYN, NAMESYN entities are also provided.

Documentation of the usage and variations of VALUEs etc. is provided by the SDES and NAMEDES record types in the IDD.

This complex but elegant structure in the IDD is completely pointless if you define a new element for each different usage of a business item. However most people don't use it and to a large extent would be much better off with a COBOL Copy Book library.

I believe (but I cannot prove) that the early implementations of the IDD did not allow you to add a picture at the Element level thereby forcing the correct usage of the structure.

Perhaps Kay Sussman the WIZIDD would like to comment?

Chris Trayler

[color=#16d710]--------------- Reply ---------------[color]

I could not have explained IDD's implementation of element overrides at record level better than Mr. Traylor. Good job, Chris!

Unfortunately for Mr. Hoelscher, as far as I know there is no "security" at record element override level to prevent what occurred. I do, however, concur with Chris - that defining a new element is NOT the preferred way to go.

Kay Sussmann

Outcomes