how are you handling binds and newcopy, etc after backout?

[Karen Turner]

we're hoping to activate pkg backout, on the surface peice of cake, obviously.  the problem is how to automate everything the move processor did for the original executable, after backout: 0-3 binds (do you need to rebind if dbrm and load are both backed out?), backbinds, 0-20 cics newcopy's, wlm refresh for db2 stored procedures? endevor is licensed to 3 single lpars on 3 separate sysplexes.  the production db2 subsystems and/or cics regions are not necessarily on the same lpar (but within the same sysplex).  In the move processor all this is done today by a combination of  processor overrides, ite and assorted rexxes that route the binds and newcopys to the appropriate regions.

 

Basically, I need to get to the processor group name, db2sys and cics symbolics from exit7 (COBOL preferably) and I assume pass them to an external rexx routine that resembles the move processor.  Keep in mind all these years the only exits I've touched were the ones you guys submitted for support issues .

 

I'm open to suggestions!

 

Thanks!

Karen

[John Dueckman]

Well, as far as binds go, get the DBA's to turn on "bind versioning". Then when you back out, DB2 already has the previous bind to match the executable and no further action is required.

[Anon Anon]

Hi Karen. The native backout facility is definitely not a piece of cake. First thing I learned the hard way with backouts is if the proc group of the source changes the proc group on the target then the backout, if needed, will fail. Makes sense when you think about it. On a proc group change the first thing that happens is the delete processor is invoked. So, what would have become your -1 encrypted executable just got bloown away. Then when you try to backout the previous executable it is not there. You may also want to consider deletes and new elements. Both offer twists during backout. AS far as binds and newcopies go, well....Wow, there must be dozens of different answers and none of them are tailored for your installation. I go along with John on DB2 DBRM versioning. At ST we have production on a different sysplex than Endevor. So that means when I do a backout I have to reship. Reshipping rebuilds all my bind and phasein (we use CPSM) job steps, including elements to be bound/phased lists in files. So, DB2 versioning is not even really needed for my prod. On the sysplex where Endevor is housed, though, versioning does connect the backout load to its previous dbrm. On this sysplex the CICS reegions are recycled nightly anyway, so I have so far gotten away with just letting that action sync up the CICS regions there when I back out. Good luck. I see going forward as a well oiled machine and going backward as a CMM level 1 chaotic nightmare.

[SBAshby]

Hi Dan,

 

I think that recent PTFs have fixed your scenario where a processor group change loses backout. It is no longer a problem for me.

 

Stuart

[Anon Anon]

Indeed. I just tested and a proc group change was no problem. Thanks for the tip

[SBAshby]

HI Karen,

 

Is shipment an option with post shipment scripts? Even if you don't use the implemtation JCL it could still build the backout JCL for you.

 

Stuart

[Karen Turner]

HI Stuart, no we don’t ship, the binds are executed on the other system by an APPC assembler program called by a rexx from the processor’s bind step.  I need post backout  scripting !

Karen