Finding Quiesce Point - for only some Areas

[Dennis Warren]

Is there interest in this ?

 

 

Request for additionally functionality - enhance IDMS by adding a utility function to produce input for a subsequent Roll-Forward - the output of this function would provide the earliest possible STOP times for quiesce points applicable for the parameter specified Segment.Area names and journals.

 

Given Roll-forward can be used in time of Stress (an emergency), we need a more automated way to determine  available queisce times.

 

The Print Journal and/or Journal Extract utility functions have been used for this, however this is requesting a way to automate what has traditionally required a manual process to locate potential Queisce points using the current reports when the recovery-units happened but do not determine which Times would work for the Roll-Forward parameter - for the limited set of Areas.

Perhaps this automation can be done by using the date/time stamps on the Area Journal records (i.e. only those readied for Update) and then using the Start and Stop times on the Transactions associated with those Area records in order to determine which quiesce times (i.e. when there are no overlaps of recovery-units of the subset of Run-units). The idea is that the output of this process could be parameter lines in Roll-Forward syntax containing each of the earliest possible STOP times which should be usable as input to the Roll-Forward process. 

Note:  Even if  it were to turn out that "absolute for sure" times might not be possible to produced ... even Educated guesses would be better than requiring the manual process involved with digging the information out of very big reports on our own.

[Paul Schulz]

I am interested.

 

There are other possibilities that may make this effort easier on folks doing recoveries:

1. Can a DBA choose an somewhat arbitrary point in time and have IDMS produce a consistent recovery for all areas included? (ie. Will IDMS adapt your point in time to make sure it only restores to an appropriate commit point near the point in time we chose? If our chosen point in time is in the middle of a withdrawal from one account and a deposit into another account, it would be nice if IDMS would move the recovery to one side or the other side of that commit scope – Unit of Work.)
2. If CA would create a repository that stores quiesce points that we specifically create using the Quiesce command, then it would be easier for applications and DBAs to take quiesces for ourselves and then look into the quiesce repository for a quiet time for a recovery.

 

Paul

[MartinRCox]

We (Cogito, now a Syncsort Company) already have a product that can do this. EZ-SQP - Soft Quiesce Point. 

Contact me offline [e-mail] if you want further details.

 

Cheers

Matin Cox

[Dennis Warren]

Paul - Yes, I see the value in what you mention, in fact my manager who works with DB2 suggested the ability to pick a quiesce point is much easier as DB2 apparently has built in code to provide more help to the DBA (I haven't worked with DB2 but overall I get the idea it provides more safeguards, while perhaps not so much flexibility).

 

In this case I probably should have been more clear that when I ask for help in finding Quiesce points limited to a sub-set of specific Areas within a given Segment - the assumption would need to be that no cross-area pointers/Sets would be present from those Areas to other Areas not in the Areas listed as parameters.    The technique I alluded would need to select recovery-units for consideration as consisting with only those Run-Units where the subset of Areas would be the ONLY Areas readied in an update mode (for that Run-Unit and hence each Recovery-Unit for that Transaction-ID).

 

My guess is it may be that CA has held off with much automation in these areas because on-site DBAs would need to be very careful to communicate with Applications people and/or likely even End-Users about the possibility of cases where logical relationships might not be "rolled forward".  Though there would not be any physical "broken chains" ,  logical relationships relating fields in other records stored in different areas might not always look like a user or program could expect.  < I think the concept of referential integrity (enforced by the DBMS) in relational databases may help either IDMS SQL and/or DB2 to handle this kind of thing. >

 

One aspect that I like about IDMS is how in some cases we probably have more liberty than if the DBMS is limiting us to only things that qualify as "very safe".  If/when  we think we are "big boys" and understand the risks involved -- we are sometimes free to use ways to come out of a crises in better shape.   For instance by relying on specific knowledge concerning how applicable update programs actually work - or whether it is relatively safe to trust assurances provided by Applications and/or End Users in regard to whether logical-only relationships might not (in this case) be an issue if we restore and roll-forward only a sub-set of Areas.

-Dennis