View previous topic :: View next topic
|
Author |
Message |
Banuchandar
New User
Joined: 02 Jun 2010 Posts: 4 Location: Chennai
|
|
|
|
Hi All,
What is the difference between CBLTDLX and CBLTDLI IMS calls. Planning to upgrade the CBLTDLX calls, Would it reduce the CPU time of which a CBLTDLX call consumes.
Regards,
B_G |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
why not look at the manuals Yourself ???
here is a link to a list of bookshelves where You can find the manuals for Your level of IMS
www-03.ibm.com/systems/z/os/zos/bkserv/zappls2.html
if You find any issues reading the manual explanations somebody will be glad to help! |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
You should not upgrade your CBLTDLX calls to CBLTDLI to expect significantly faster or cheaper processing. I would expect current version IMS modules to have performance characteristics tuned over the years, but as functionality increases, so do overhead.
The primary reason for converting should be that CBLTDLX has been obsolete for over 10-15 years, and no documentation or support for it exists any more.
CBLTDLX was a pre-IMS BMP checkpoint/restart interface using DL/1 data bases for storing checkpoints. |
|
Back to top |
|
|
Banuchandar
New User
Joined: 02 Jun 2010 Posts: 4 Location: Chennai
|
|
|
|
Hi Kjeld,
Many thanks for you views and suggestions.
All,
Adding some information about the CBLTDLX call. PFB.
CBLTDLX
When we began writing IMS update programs (in the early 1980s), we needed a mechanism to ensure integrity. At that point, GSAM was not available (or did not have sufficient functionality) and BMC/ARC was not available. So our systems programmers worked with IBM to provide a stopgap mechanism.
The solution was CBLTDLX. This had two components :-
A Checkpoint database. This was a conventional IMS database keyed by Job/Step/ProcStep that could be used to store checkpoint areas.
An application can take a checkpoint (CHKP) using CBLTDLX (passing the checkpoint area). CBLTDLX inserts the data onto the Checkpoint database, issues a basic IMS checkpoint and then deletes the checkpoint data.
So if there is an abend, the updates to all databases (includinging the Checkpoint database) are backed out to the last successful checkpoint and the checkpoint area is magically restored and can be used for a restart (XRST) call.
Checkpoint pacing criteria are also stored on the Checkpoint Database. Eg you can specify to skip checkpoints if there have been less than 'x' reads or 'wy' updates since the last successful checkpoint.
XSAM functionality. This was an attempt to second-guess what GSAM should do (when IBM made it available). The XSAM module keeps track of the position of each XSAM file. An XSAM file is a normal QSAM file that is accessed via CBLTDLX. The XSAM field position (RSA) is stored on the Checkpoint Database along with the Checkpoint area. So in the event of a program failure (and subsequent restart), XSAM knows exactly where are in each XSAM file and can reposition accordingly.
XSAM calls a further module called BSAM to handle the flat file I/O.
CBLTDLX was used for a number of years until we got BMC/ARC. Incidentally, when we first started using BMC, we had a major performance problem. The idea with BMC checkpointing is to offer a CHKP at each LUW and allow the pacing criteria to decide whether to honour it. It turned out that BMC flushed buffers even when checkpoints had been skipped by the pacing logic. So we had all the overheads of doing real checkpoints even when they weren't honoured. We had to write an additional module (CBLTBMC) to use until BMC got fixed.
Regards,
B_G |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
As far as I know, checkpoint pacing in IMS BMPs are solely controlled by application logic (or may be 3rd party software). So what you save in CBLTDLX for pacing logic may be spent in your application module.
I have even coded automatic restarting in some BMPs for parallel processing jobs that were prone to DB2 deadlocks. |
|
Back to top |
|
|
|