RE: Roll-back program questions

From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Tuesday, May 21, 2013 4:08 PM
To: Midrange Systems Technical Discussion
Subject: Re: Roll-back program questions

Have you considered using my Make tool (COMPILE) at
www.think400.dk/downloads.htm. You can put your instructions for how to
create the objects in the header and have your change management run
the
COMPILE command to create the object.


On Tue, May 21, 2013 at 11:03 AM, Koester, Michael
<mkoester@xxxxxxxxxxxxx>wrote:

We use a home-grown (circa 1980's) change management system that does

a

pretty good job of archiving source, but was not designed to handle

the

various ILE objects I'm now using, so I've been augmenting our turn-

over

process with a CL program to create *PGM, *BNDDIR, *SRVPRM objects in

the

desired order with the desired optional parameters, etc., to simplify

the

SysAdmin's life. I would like to add some code to these "implementer
programs" to facilitate an easy/speedy recovery if I should ever

screw it

up and need to roll back my changes. We do not use journaling, and
recovery from tape might be slower than acceptable.

We develop and test on the same box, using test database objects and
production application objects, except where our test library (higher

in

our test environment *LIBL) may have a new-and-improved version.

Been at

7.1 for a long time now.

A typical turnover these days may involve:
OPM stuff (created from PDM option 14),
binder source updates,
*PGMs created from source,
*MODULEs created from source,
*PGMs created from *MODULE,
*SRVPGMs created/updated with CRTSRVPGM or UPDSRVPGM

commands,

*BNDDIRs created/updated with CRTBNDDIR and ADDBNDDIRE

commands

We don't mess with *LIB objects, and updates to websites are handled
somewhat differently.
The database may get a new file or two (from DDS source), but we

aren't

using DDL, triggers, constraints, views, etc.

In the event a roll-back was required, users of the effected

applications

would be asked to stay out until the roll-back was complete, so

operating a

partially restored application is not an issue.

My thought was that I would add CRTDUPOBJ statements for each object

being

changed to the "implementer program". I would then prepare a

recovery CL

that would be able to dltobj each of the new/changed pieces and then

rnmobj

the copies to restore everything to their original places.

My questions: Are there object types that would not be easily

recoverable

in this manner?
What objects might be especially sensitive to the existence of

others, and

thus require that sequence is critical? Or does order not matter, so

long

as all the original objects are renamed to their original places

before

they are accessed?
I'm guessing that binder source is only used with CRTSRVPGM, so that

could

be restored to original after the objects are in place and users are

back

on-line? In an urgent situation, I'd envision getting the objects

back in

place, getting the users on-line and happy, and then getting all the

source

(of all types) back where it belongs.

I appreciate the advice,

Michael Koester