Comments on: Recovering deleted records

By: rbdsilva

rbdsilva — Tue, 24 Nov 2009 14:06:25 +0000

Tom, thanks for your help,

I wanted to detail from the DSPJRN, modifying the SQL database and then restoring the records before the update, you may notice that 7349 records has been restored.

Regards,
Roberto

By: tomliotta

tomliotta — Tue, 24 Nov 2009 01:46:11 +0000

Well, I’m not sure exactly what the images show, but they’re detailed enough to give an idea. If those record images in the journal are records that you want back in the file, then they’re perfectly valid for a couple possible methods.

Are you done with this question? Are there details you’d like added to the discussion?

Tom

By: rbdsilva

rbdsilva — Sun, 22 Nov 2009 15:26:28 +0000

Sorry friends, the problem was solved, I have 11 pictures with step by step but I am having problem to insert this photos here.

Thanks a lot,
Roberto

By: rbdsilva

rbdsilva — Sun, 22 Nov 2009 15:09:11 +0000

By: rbdsilva

rbdsilva — Sun, 22 Nov 2009 15:07:44 +0000

Thanks for Charlie, Tom and Phil, now step by step below the problem was solved.

By: rbdsilva

rbdsilva — Sun, 22 Nov 2009 15:04:59 +0000

Thanks for Charlie, Tom and Phil, now step by step below the problem was solved.























Regards,
Roberto

By: tomliotta

tomliotta — Thu, 19 Nov 2009 22:16:41 +0000

Minor note…

Journal images  . . . . . . . . . . . . . . : IMAGES     *AFTER
Journal entries to be omitted . . . . . . . : OMTJRNE    *NONE

It’s a little odd to only retain *AFTER images but also to retain all *OPNCLO (opens and closes). I’d assume it was set up automatically.

Was there a reason for the choice (other than it being the default)? I usually go the other direction with *BOTH and *OPNCLO. When I’ve wanted to track opens/closes, it’s always been for a specific termporary purpose and I can enable it when needed. It’s much harder to enable *BOTH when needed because it’s usually needed before it can be enabled…

Tom

By: tomliotta

tomliotta — Thu, 19 Nov 2009 18:46:35 +0000

@RBDSILVA:

Because your journal only has *AFTER images, you cannot use RMVJRNCHG.

You must restore the file from before the problem, and then use APYJRNCHG to apply the updated *AFTER images.

There are no *BEFORE images to available to work your way backwards. There are only images that can go forwards from a point in time. If the journal was holding *BOTH (before and after), you could go either forward or backward.

Tom

By: philpl1jb

philpl1jb — Thu, 19 Nov 2009 02:28:45 +0000

It would using rmvjrnchg but first dspjrn to check the stuff that would be selected – you want to specify the file & time range or job. I’m not sure if that will work with delete on an after image.
Phil

By: rbdsilva

rbdsilva — Thu, 19 Nov 2009 02:03:37 +0000


Hi Tom, it´s correct the name of the journal is QSQJRN.

Access path size  . . . . . . . . . . . . . : ACCPTHSIZ  *MAX4GB         
Maximum record length . . . . . . . . . . . :              395           
File is currently journaled . . . . . . . . :            Yes             
Current or last journal . . . . . . . . . . :            JOURNAL         
Library . . . . . . . . . . . . . . . . . :            MASTER         
Journal images  . . . . . . . . . . . . . . : IMAGES     *AFTER          
Journal entries to be omitted . . . . . . . : OMTJRNE    *NONE    

I´m testing, this example:
by SQL
> delete from PRODUCT/MASTER                
  62819 rows deleted from MASTER in PRODUCT.

How can I restore that 62.819 rows deleted ?

Thanks,
Roberto