IBM Mainframe Forum

dick scherrer wrote:Hello,

If one or more checkpoint(s) is issued by the run and it later abends, there Will be a partial update.

Hi,

Here i mentioning pure ROLLBACK. What i mean is a 'ROLB' without any COMMIT/CKP.

Befroe that i need to know. Is it possible to issue a 'ROLB' alone in ims call without COMMIT/CKP.

Scenario: (I have TABLE(IMSDB) containing 10 records. i'm updating 10 records to the TABLE(DB2). If 9th record cause mismatch/invalid data on the updating TABLE(DB2). i need to perform a rollback for entire record. Then,again the update start from 1st record onwards.inbetween no more checkpoint(s) in that table.)

Ed Goodman wrote:I can't tell the difference between what you asked for originally and what you said to clarify it.

A pure ROLB will rollback all updates to the last commit point. I'm nit sure what you meant when you wrote 'I don't want a partial update.'

Try a longer example and maybe it will get through to me!

Here, i meant pure rollback. That was, a rollback should perform a funtion as no more checkpoint(s) in a table. if any invalid or mismatch of data occures. It could be rollback entire updated records from the table and again it starts from 1st rec to the table.

Sorry for my poor english.

If IMS thinks it weird that you issue a rollback without having a checkpoint to roll back to then issue a checkpoint before you start but I would imagine that a rollback before a checkpoint is reached should be no problem - it probably happens every day when testing a new application.

Hello,

If, while processing, a checkpoint is issued, there is no way to rollback to a point prior to when the last checkpoint was issued.

You're not going to like my answers...

Take checkpoints when you reach a logical unit of work in the IMS table read (like when the DB2 key changes or something).

If you have a problem, do the ROLB, like a normal program, then do whatever you were going to do after the 'pure' roll back.

Alternately, run a read-only version first to do all the matches and write them to a flat file. Then use that flat file to do the DB2 updates.

dick scherrer wrote:Hello,

If, while processing, a checkpoint is issued, there is no way to rollback to a point prior to when the last checkpoint was issued.

Hi scherrer,

Thanks for your suggestion.

See, If IMS having there is chance of doing Partial Update means, is it might be have the chance to do a full rollback(without partially) right.


Regards,
Purushoth

Ed Goodman wrote:You're not going to like my answers...

Take checkpoints when you reach a logical unit of work in the IMS table read (like when the DB2 key changes or something).

If you have a problem, do the ROLB, like a normal program, then do whatever you were going to do after the 'pure' roll back.

Alternately, run a read-only version first to do all the matches and write them to a flat file. Then use that flat file to do the DB2 updates.

Hi Ed,

What's the point of using a flat file in between the process.If suppose we use the flat file means the same things will happen in the rollback funtion right.

Sorry,i didn't get you. Why you telling this. Please Do help me with any other idea...

Are you updating both the IMS database(s) and the DB2 table(s)? Or one? Or the other?
No such thing as a "pure" rollback. A rollback is a rollback. It rolls back to the last checkpoint whether that is taken during processing or simply the beginning of processing. If you are taking checkpoints but need to ignore them when rolling back then why take the checkpoint? If it is under special circumstances then simply restore your databse/table with backups taken prior to the updating.
But as you seem to be having trouble understanding the advice given why not consult with your DBAs - after all, giving guidance is part of their job description or should be.

These users thanked the author NicC for the post:

purushothaman (Wed Nov 27, 2013 7:02 pm)

Ed Goodman wrote:Ah, then two options that I can think of:

1) Don't take any checkpoints during the program, just one at the VERY beginning, right after the XRST call. Then the ROLB will go all the way back.

2) Take an early checkpoint, abend when you find that you need rollback, then do a batch backout specifying the first checkpoint.

I'm the last guy to do this to a honest question, but WHY are you trying to do this?

Hi Ed,

Thanks for your response.

Here no use of checkpoints . Hence,i won't do a partial update. And,also that's not my approach for rollback.

Yes, i'm trying to do this, because that was my requirement.

Hello,

Yes, i'm trying to do this, because that was my requirement.

Sorry, but i disagree. . .
This is How you are trying to meet the requirement - not the requirement itself.

We still need to understand the requirement if we are to help with suggesting alternatives. You need to explain the business/code function this will support. Why does someone believe this is necessary or even acceptable?

This sounds like a bit of missed communication in your organization.