Endevor

We've got a development team who have 5 applications (and all of their source in the same System/Subsystem). Each of these applications has it's own version of a particular program. If they make a functional change to one program they want to ensure that this is made to all 5 versions of the program, so we want Endevor to throw a warning or an error if they only make a change to one of the programs.

Now I'm sure I can fiddle with the processor for this particular use case to get it to throw an error, however I've been told they might have a number of other similar use cases for other types.

So to avoid filling my processors with hardcoding I wonder if anyone has got any other solutions or have come across similar requests? I was thinking maybe an additional 'LINKELM' type containing a list of linked elements?

There's a couple of ways you could approach this. Starting with the easiest from an Endevor perspective would be to change the bulk of the program into a COPYBOOK (or multiple COPYBOOKs). Then have the 5 different programs with unique names use the copybook as the body of their program. Changes take place in the commonly shared copybook rather than in the "skeleton" member itself.

Once the developers have done that, it's easy-peasy for Endevor to keep track of which programs are using which copybooks! And package validation gives you the integrity you need.

A messier suggestion I can think of has to do with CONRELE.... but you could create a stub type that tracks the other "versions" of the code and then use CONRELE to associate the member to the program. When it changes, an ACM query in the generate processor could trigger an alert to the other applications. But like I said, from an Endevor perspective, that's messier...

Thanks John, when I said 'program' I was telling a little white lie, these are actually IMS PSBs. I used the 'program' analogy as IMS seems to be a bit of a dark art and I didn't want to put anyone off. Unfortunately when looking at the PSB source I don't think they easily lend themselves to the copybook approach as "variable" names will be slightly different throughout depending on your database.

Well, why didn't you say so? Being from the west coast I'm much more familiar with IMS DB/DC than I am with CICS!

So..... I'm assuming your PSB has shared PCB source that it wants to use? According to my now-very-old processor that I wrote oh-so-many-years-ago, PSB source is compiled using the regular Assembler compiler. So THAT means your PCB source or whatever you want to share COULD THEORETICALLY be the Assembler version of a copybook: a MACRO.

IMS source is fairly unfamiliar to me but from doing a line compare there is very little similarities between them. From the comments:

IMPORTANT NOTE - PLEASE READ !
PLEASE REFLECT ALL CHANGES TO THIS PSB TO THE SEPERATE PSBS
USED IN SWF FOR MULTISTREAMING. THERE ARE CURRENTLY 8 SUCH
PSBS ***1, ***010, ***011,
***012, ***013, ***014, ***015, ***016
NOTE MORE WILL BE ADDED AS OTHER PAS STREAMS ARE CREATED.
THANKS

I know that PSBs are assembled but I don't see how they'd break these modules down into shared Macros (and I hope if they could have they would have already done this).

I've asked the development team if they could use Assembler Macros, this was their response - 

The analysis and spreadsheet I’m working on at the moment I’m sure will clarify.

But yes, our PSB naming is based on stream naming – where we have main update processing we have a different PSB for each of the eight streams, for outputs we have 17 streams resulting in 17 different PSBs, etc.

Let me know if you want to trade notes and we can take this "offline". You can reach me at john.dueckman@telus.net