Is there a technique called 'dynamic commit'?

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

Because batch programs and online programs are updating the same tables, I want batch program commit changes more when less online programs are updating , and batch program commit less when more online programs are updating. Thus, lock can be heavily avoided .

I wonder if there is a technique called such 'dynamic commit'?
If yes, how?

dbzTHEdinosauer · Posted: Sat Sep 01, 2012 4:24 pm

no, there is no such thing as dynamic commit.

there is such a thing as decent design.

what is your lock level? page?,row?

what is your commit frequency for batch?

how many updates are you making in cics before you syncpoint
or terminate the transaction?

you mentioned before that you are/have 'batchitzed' your cics system.
have you given any thought to having the 'online-batch processes'
redesigned so as to process them in batch environment?

enrico-sorichetti · Posted: Sat Sep 01, 2012 4:26 pm

The commit frequency is completely free to choose.
the only thing to take care is to have enough info for a restart
( basically to reposition correctly input and output - non DB2 - entities )

but why change it dynamically, choose a reasonable one to start with and stick to it

dbzTHEdinosauer · Posted: Sat Sep 01, 2012 4:58 pm

problem with the word dynamic is that it implies/means
that some program/system is making decisions on a real-time basis.

you could have for each job/transaction
a db2 row that indicates level 1,2,3,4 (3 is usually enough) commit frequencies.
another table that contains level indicator for job/transaction.

at each commit or syncpoint, the job/transaction refreshes its copy of the commit level indicator,
and adjusts the commit/syncpoint frequency accordingly.

the commit level indicator would be maintained by dba's monitoring the system processing.

i have written syb-systems that follow this type of design,
and as long as you have good monitoring tools,
and the dba's are experienced with the work flow,
so that can anticipate - based on knowledge - when the system will probably incur stress points
and react accordingly,
it sorta works.

i imagine you could later write a subsystem to replace the dba's activities
with respect to monitoring and reacting - setting commit level indicator.

that is about as dynamic as you could get,
remembering that the last part can get you into trouble
if not written well,
/start personal opinion/
sort of like electing democrats to US congress and president.
/end personal opinion/

prino · Posted: Sat Sep 01, 2012 5:36 pm

dbzTHEdinosauer · Posted: Sat Sep 01, 2012 6:33 pm

prino,
who would you rather have buy the presidency to feather their own interests(rep) or pockets(dem)?

dick scherrer · Posted: Sun Sep 02, 2012 3:57 am

Hello,

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

Thanks, experts,
I'll think over that. your suggestions are very valuable.