Re: Insure DB consistency in case of recovery

This is an area where I am not proficient in HOW to do this, I am somewhat
knowlegeable only in WHAT can be done.

One of the nice things about DB/2 is that you can put rules in the definition
of files, that trump 100% of your programs.

For example, you could say that some specified field can never be a negative
number.
It does not matter who or how anything tries to make it so ... user tool,
application software bug, it aint going to be violated.

In other words, some of your application's business rules can be transferred
from traditional programming to a set of rules imposed over your data base at
the file definition level, which I think can bring your data base structure
closer to the people who make the decisions as to what the rules should be.

You might try to have some of your people attend the IBM classes in SQL,
because there is a goodly chunk of time expended on DB topics like this & the
literature brought back from the classes will also be of interest to
collegues who were unable to attend.  In fact, I learned about the above DB/2
rules concept, at such a class.

For people who like this approach, Rob Dixon takes this to an extreme of
putting everything in the business rules & nothing in traditional software,
via his offering at http://www.erros.co.uk/ which can be a bit difficult to
grasp at first so you might want to check out the review at
http://www.400times.co.uk/Documents/ERROS1.htm

For DB recovery, I learned something recently of potential value.
You know how you have to recover physical file before logical because if the
physical is not there & you try to restore logical, it aint going to work.
Now if you do SAVE21 RESTORE21 everything will work fine, but if you doing
some other restore in alphabetical sequence of library & you have logicals in
one library that point to physicals in another that happen to be
alphabetically named after library of logicals, there is a potential problem
there, and some applications come from the vendor that way, and some get
setup that way before in-house tech staff learns what a good idea this is NOT.
Well if you doing some other kind of restore in this reality, you can follow
up the first restore with a second restore of just what is different /
missing & it will get the logicals it missed on the first go round.

If you have files that you do not want IBM Journaling to mess with in
recovery, do you still need to IBM Journal those files?

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

> Subj:  Insure DB consistency in case of recovery
>  Date:    04/12/2002 6:12:38 AM Central Daylight Time
>  From:    Refaie.Heba@khb.hu

>  Hello All,
>
>          We are implementing a financial application which has got a
>  certain development structures and it own recovery procedures based upon
>  Database files used as journals instead of the native AS/400 journal files
>  and has separate update programs that maintain the database integrity in
>  case of recovery.
>
>  This application has been in-house customized and some new physical files
>  have been created in order to save some extra data that we can not save in
>  the original application database. The customized programs are not
>  following up the same rules like the application and the new files are
>  only AS400 journal led and there are relations between our files and the
>  original application files.
>
>  How can we maintain the whole database consistency, in case of recovery
>  the recovery procedure of the application will run first and then
>  APYJRNCHG for our files.
>
>  I know that this process is 99% will be OK, but the management (as usual
>  my Boss) is a bit doubtful that there will be a great inconsistency
>  because the normal AS400 journal will apply everything no mater how the
>  recovery of each record in  the application is successful or not. He asked
>  the whole department to change the already developed and tested programs
>  to follow up the same development rules as the application. Which in my
>  opinion will add a lot of performance slow down (we need to create 5
>  separate programs per file to imitate the application). Is there something
>  in DB2 to check for the consistency when applying or removing journal
>  changes? Or is there any other suggestion?
>
>
>  Thanks beyond measures,
>  All the best.
>  Heba.