IMS 99 Log Record creation when multiple IMS Change Data Capture Exits are coded

With the coding of EXIT=((IMSDCAP0, CASCADE,LOG),(,NOCASCADE,LOG)). IMS treats these separately when building 9904 records. So it provides the data requested for the first exit statement, then the data requested for the second exit statement. In this case the 9904 for a delete would have DCAP header for IMSDCAP0 followed by concatenated key, and then data for every segment deleted from the segment being deleted and below; This would be followed by the DCAP for with concat key, and data for the segment being deleted and no data for the children. For ISRTS/REPLs, all the info (key, after image, before image) would be duplicated.

If IMS only logged one copy as a superset of what was requested, then there would not be a way to distinguish between the two specifications (without a re-architecture of the 9904 layout) and could fail if it gets data it is not expecting as requests may have said NODATA or NOCASCADE is required for their product. Now if the two products don't care about 'EXITNAME' and can tolerate data they do not need, then you might simply want to put LOG on only one specification. e.g ((IMSDCAP0, CASCADE,NOLOG),(,NOCASCADE,LOG) but this would not log the children deleted ever, but may exit based products don't need log anyway. Or just ((IMSDCAP0, CASCADE,LOG)) like they had in their sample DBD since this will log every thing the other will and more. But this would require the product that wanted ,nocascade,log to know it can use the info logged for IMSDCAP0.