Commonly-shared Components - Who Is Responsible?

[John Dueckman]

Here's a best/most common practice question for everyone...

How does your site handle shared components? For example, a shared copybook...

1) Who is responsible for regenerating the where-used elements? The person who changed the copybook or the owner(s) of the "using" code?
2) How do you handle testing?
3) How do you handle promotions?
4) How "strict" are your processes?
5) Do you rely on component validation or do you automatically recompile all code regardless of where it is in the life-cycle?

[Joseph Walther]

These are good questions, and I see there are no responses yet. In the hopes of seeing others provide their answers, I am offering multiple answers for the variations I have seen.

1) Who is responsible for regenerating the where-used elements? The person who changed the copybook or the owner(s) of the "using" code?

• A changed Copybook requires no action for the where-used elements
• A Generate on a Copybook automatically identifies the where-used elements and generates them too
• A packaged copybook causes the where-used elements to be identified, and the approvers for the where-used elements are added as approvers for the packaged copybook. Package comments indicate the where-used element relationships.

2) How do you handle testing?  

• If ACM is incomplete, then a developer must scan for the where-used elements to test
• If ACM is complete then a developer can query for the where-used elements to test
• IMS, CICS, IDMS, DB2 (etc) regions are associated with specific locations of the Endevor life cycle
• IMS, CICS, IDMS, DB2 (etc) regions are associated with specific Deploy for Test target locations
• Someone manually tailors a production JCL and submits it for a test
• A Generate action on a JCL element causes an automated tailored version of the JCL to be placed into a library where it can be submitted.
• (There is now Test4Z and more to come on this topic)

3) How do you handle promotions?

• Rely on Endevor delivered email, and manual package executions and shipments
• Automate package executions as soon as they are approved.
• Automate package shipments as soon as the package executes.

4) How "strict" are your processes?

• For processor changes - require walkthroughs for code and test results, lead times, and a package approval
• Install when ready

5) Do you rely on component validation or do you automatically recompile all code regardless of where it is in the life-cycle?

• Some have incomplete ACM information and cannot depend on component validation
• Some can depend on component validation, and allow it to help identify what is missing in their package (Additional SCL statements are Added)

 

 Looking forward to seeing how others reply.

[Mathew Goldstein]

• We define a "common" system for shared generate time input components.
• We define subsystem level libraries at the entry stage and repeat all of the other subsystems for authorization.
• The migration to a subsequent stage eventually results in the many subsystems being merged into fewer system level subsystems (all of the other systems become subsystems for the common system) and at the same time we switch to a single set of common system level libraries. So anyone with authorization to work in that system (as the common system subsystem) can edit the common input component. Switching ownership would require a transfer action.
• We enforce cross system duplicate blocking of common generate time input components in our generate processors. In other words, the generate time input components in the common system cannot be duplicated in any other system and vice versa.
• The developers have the option to use AUTOGEN the use of which we encourage.
• We avoid load modules for subprograms. Subprograms are statically linked object modules with only those exceptions that are well justified (such as fourth generation languages that only support dynamically linked subprograms), in which case we usually create both an object module and a load module.

[Philip Gineo]

Hi John,

This could be a good topic to discuss at our next EUNE (Endevor Users of Nearly Everywhere) Meeting.

🙂