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/