SET OBJECT IN CA-IDMS (RELATING RECORDS and USING DATA
STRUCTURE / BUBBLE DIAGRAMS TO REPRESENT RECORD
RELATIONSHIPS)
https://plus.google.com/105480211036566033816/posts/LS1AqZ6E3Jm
Hello Mainframe folks,
I decided to share an interesting fact regarding the z/OS database CA-IDMS.
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.
So assume we have 2 records in 2 different tables- say T1 and T2.
So while relating records in T1 to records in T2 we can use T1 and T2 as "record structure
identifying" keys and create set relationships within them
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.
create unique calc key on <schema>.T1(field1,field2,field3.....);
create unique calc key on <schema>.T2(field2,field1,field3.....);
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.
Based on the above CALC keys RECORD statements need to be created:
add record name is T1
share structure of record T1
of schema <schema where T1 and T2 exist>
location mode is calc using field1
duplicates are not allowed
within area <area where schemas and segments associated with T1 & T2 are defined>
add record name is T2
share structure of record T2
of schema <schema where T1 and T2 exist>
location mode is calc using field1
duplicates are not allowed
within area <area where schemas and segments associated with T1 & T2 are defined>
Now define the SET statement
add set name is t1andt2
order is next
mode is chain
owner is t1
member is t2
Now let us visualize what happens during runtime:
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:
||||||||||| field1 ||||||||||| field2 ||||||||||| field3...……
||||||||||| val11||||||||||| val12 ||||||||||| val13...…..
||||||||||| val21||||||||||| val22 ||||||||||| val23...…..
||||||||||| val31||||||||||| val32 ||||||||||| val33...…..
……………………………………………………………………………….
……………………………………………………………………………….
……………………………………………………………………………….
So the CALC will look like this:
(FIELD1 CALC)==> field1
(FIELD1 CALC)==> val11
(FIELD1 CALC)==> val21
(FIELD1 CALC)==> val31
………………………………………………...
………………………………………………...
Similarly the CALC on T2 might look like this:
(FIELD2 CALC)==> field2
(FIELD2 CALC)==> val12
(FIELD2 CALC)==> val22
(FIELD2 CALC)==> val32
………………………………………………...
………………………………………………...
Now the RECORDs defined on the CALCs will look like this:
(T1 RECORD)==>||||||||||| field1 ||||||||||| field2 ||||||||||| field3...……
(T1 RECORD)==>||||||||||| val11||||||||||| val12 ||||||||||| val13...…..
(T1 RECORD)==>||||||||||| val21||||||||||| val22 ||||||||||| val23...…..
(T1 RECORD)==>||||||||||| val31||||||||||| val32 ||||||||||| val33...….
(T2 RECORD)==>||||||||||| field2 ||||||||||| field2 ||||||||||| field3...……
(T2 RECORD)==>||||||||||| val12||||||||||| val11 ||||||||||| val13...…..
(T2 RECORD)==>||||||||||| val22||||||||||| val21 ||||||||||| val23...…..
(T2 RECORD)==>||||||||||| val32||||||||||| val31 ||||||||||| val33...….
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.
But field3 values match exactly, so:
Ist T2 record (<field2>,<field1>,<field3>=val12,val11,val13) will become a member of the Ist T1
record (<field1>,<field2>,<field3>=val11,va12,val13)
IInd T2 record will become member of IInd T1 record and so on.
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.
Thanks & Regards
Infra App
infra.app.supp.se@gmail.com
visionplus.trams@outlook.com
Google Plus profile:
https://plus.google.com/105480211036566033816
LinkedIn profile:
https://www.linkedin.com/in/visionplus-development-995a44115/