Ok Charlie, thanks for all.

Roberto.

@RBDSILVA:

The journal you showed is QSQJRN, a standard for SQL journalling. If you display the product/master file description, what attributes are shown for the ‘Journal images’ (IMAGES) attribute? If it doesn’t say “*BOTH” you might need a specific method of recovery.

Also, was the file being updated under commitment control? Were other files involved in the same process? Was product/master update by other processes after the erroneous updates were applied?

Tom

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

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

@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

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

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























Regards,
Roberto

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

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

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

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