24/7 CV Operation

[Gary Cherlet]

Our Production CV is shutdown each evening at 20:00 so that the daily batch can be run and is then brought back up at 01:00. We have a number of ‘pseudo’ Production CVs which are accessible whilst the ‘real’ Production CV is down.
This set up is becoming increasingly difficult to administer and pressure is growing for us to go ‘24/7’. We know that we will have to make significant changes to the daily batch so that it will run ‘in CV mode’ but we are not clear on the changes required to the CV.
Has anyone any experiences/advice on going ‘24/7’ that they would be willing to share?
Thanks in anticipation. Paul Clarke

[Gary Cherlet]

I guess the question is - what is the difference between the 'pseudo' and real CVs? Is it just a matter of areas being update vs. retrieval? Do you have native VSAM that is deleted/defined during the pseudo time frame? Do you have difference SYSGEN or default SYSGEN options in these 2 environments?
IDMS has readily improved its commands to accommodate 24x7 processing - OFL/RET/UPD/DEALLOCATE/ALLOCATE can be done at the segment level - I think many SYSGEN changes can be made dynamically - and the default SYSIDMS module maybe can be swapped and newcopied ???
If you can provide the list with the differences (i.e. what needs to happen at 8:00 pm and 1:00 am) - the list might be better able to provide guidance.
Chris Hoelscher

[Gary Cherlet]

As a follow-on, I would have to ask whether a true 24 X 7 operation is necessary or a more common approach of running CV or DC system(s) through most of the week and doing backups on the weekend.
There are also strategies for using "shadow databases" which can be refreshed by disk-to-disk backups on the weekend and then updated as journals are offloaded. This can allow the "near current" shadow databases to be used for less time-sensitive processing. This can alleviate traffic on the primary databases and allow time for the weekend backup.
If necessary, these alternatives could be used to gradually "ease into" the 24 X 7 mode you describe.
Harold Govan

[Gary Cherlet]

I think the most important change you will need to make is to ensure that your batch programs contain adequate COMMITs. If they don't, you risk filling up all of the journals at which point the CV will hang up.
Unless you have a hot backup solution, you will need to take the areas offline while backups are being run. So you will need a method of ensuring that the areas are actually offline before starting the backups. Unfortunately, CA does not provide such a method. There are various home-grown solutions.
Kay

[Gary Cherlet]

I agree with Kay. In addition, other programming, operational and recovery issues will need to be addressed.
Considering the potential complexities and scope of changes necessary, it might make sense to map out a step-wise process to achieve the goal of 24 X 7 operation if that is truly required.
Harold Govan

[Gary Cherlet]

How's about a modified DB2 approach? Code an Resource Limit Exception exit for DBLOCKS > nnnnn and issue a commit from there? That would save all the source code updates for the program . . .
That's a theoretical possibility . . . haven't tested it . . . but tho' it was conceived half-in-jest, I'm starting to like it . . .instead of abending a program for excessive locks, just commit it . . . 8^D . . .
You already would have a problem in such a case, so any solution is probably better, even if it presents other issues .. .
FWIW . . . david

[Gary Cherlet]

If running with no commits, there are less problems (not no problems) with the CV, but longer recovery time, if the area(s) are readied in PROTECTED UPDATE. Could have problems with that scenario if you have a LARGE number of updates and an inadequate amount of journal space.
So what did you do at 20:00? Bring the CV down (obvious) and do a backup of your database, then run your batch cycle, and then do another backup? Or what?
My shops are (have been) set up with no local update and frequent commits in the programs.
Remember, commit interval is an art, not a science. There are no standard rules that apply except to do them (commits) frequently enough.
Dick

[Gary Cherlet]

The thoughts expressed so far lay out your basic challenge; batch jobs that do a lot of updates without COMMIT logic will be problematic.
Strongly suggest you establish and test out a generic COMMIT and restart methodology for your shop. You need to be able to not only take COMMITs, you need to be able to start from a COMMIT point if something fails.
In a shop I worked at previously, a standard paragraph with COMMIT and checkpoint logic was copied into all batch programs. Checkpoint/COMMIT interval was driven by a parameter, so the frequency could be adjusted.
Perhaps someone from that site could share?
Don Casey

[Gary Cherlet]

I'm from the shop that Don mentions. The checkpoint process uses a VSAM file with a standard layout that requires any application using it to record the status information uniformally. Our application architecture group maintains copybooks that provide the support for using that file, as well as template code. Commits are a part of that restart file usage.
We just upgraded to IDMS 17 and ran into a batch update job that was creating a large number of locks when trying to do an ERASE ALL. That job needed to reduce the commit count to avoid crashing the CV.
We've been 24x7 for over 25 years. Batch or online transactions are subject to deadlocks/timeouts, which are also an art to avoid.
Roy

[Anon Anon]

We run 24/7 with no downtime running hotbacks under R16 SP7.

We implement changes now over lunch during the week upgrading DMCL, subschema and flipping physical files. Its not in my opinion for the faint hearted but it does work..Just make sure you keep copies of everything and have a rollback strategy in place, and vary journals..

[Gary Cherlet]

One other item to keep in mind is your[b] buffer strategy. Having batch run under CV might require a performance tuning exercise on your buffers.
Buffers tuned for online random access may not perform well with typical batch sequential access. You can tune for both, or maybe vary them up for batch and back down for online usage. Just something to consider.
Bill Boyce