Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
https://plus.google.com/105480211036566033816/posts/LS1AqZ6E3Jm
I have a little bit of experience in the 2 core z/OS databases (DB2 & IMS). Recently my project
involved some work on CA-IDMS as well.
I dont know whether this capability of CA-IDMS exists in other databases as well but my
development team said that this capability of relating records is a really useful feature while
searching specific records in IDMS schemas
Most of the time proper indexes may not be in place and hence enabling records to point to each
other and clubbing them within a set enables record search easily.
Below are the steps and an approximate syntax (there are many more aspects to creating sets,
the syntax below is the basic version):
1) Define CALC keys on the tables which will be involved in the set relation
2) Define RECORDs on these CALC keys
3) Define a SET on these RECORDs
In the CALC keys include as many fields / columns of the base table so that the RECORD is
more elaborate and the SET becomes more tightly coupled.
Observe that in the above CALC statements the field combination for T1 is the normal order
field,field2,field3.... but for T2 the combination is field2,field1,field3...…
This is because only one CALC key can be defined on a table and the first- primary identifying
key has to be unique. Hence as soon as a CALC on T1 is created it is identified using field1.
From hereon no other CALC will be allowed on any other table with field1 as the identity.
Since T2 has the same table structure as T1 and the field / column sequence is also the same
(.i.e field1,field2,field3...…… in both tables), the CALC on T2 has to be on a different key, hence
field2.
I have taken the example of T1 and T2 as having the same structure but in real life business
scenarios RECORDs and SETs will be created on tables having different structures but serving a
particular functionality.
When the IDMS schema is loaded all tables and their CALCs are loaded.
So pointers to all records within T1 & T2 are created which are identified by the combination of
fields / columns based on which the CALCs are created. Hence if T1 has the following records:
Now the RECORDs defined on the CALCs will look like this:
and finally the SET called T1ANDT2 will have a T1 record pointing to a T2 record and again the
same T2 record pointing back to the owner T1 record
So in the set each owner T1 record will have a member T2 record with the following order of
associations:
1) If field2 value of a T2 record is exactly matching a T1 field1 value then these 2 records will be
associated first
2) If a T1 field1 value is not matched in any of the T2 field2 values then amongst the ascending
sorted order of field2 values all COMPLETE column value combinations or their fragments will be
matched and associated
So in our example none of the field2 values match with any of the field1 values.
This is because even though <field1>,<field2> combination differs from <field2>,<field1> the
combination <field1>,<field2>,<field3> is the closest owner match for <field2>,<field1>,<field3>
And that's it. The CALCs are in place, the RECORDs are in place and the SETs are in place.
So if a COBOL program is trying to frequently access a record in T2, IDMS will automatically
invoke the appropriate SET and quickly retrieve the specific T2 record
My development team tells me that their COBOL applications are able to access records via
SETs much faster than indexed tables, though I haven't run any "record retrieval statistics" so far.
Also I am not sure whether a similar record-to-record coupling facility exists either in DB2 or IMS
I will try finding more information on this and post more articles.