ca.portal.admin

PAGE RESERVE AND CALC ALGORITHM

Discussion created by ca.portal.admin on Jan 5, 2006
Hi everybody !!!!

We are trying to unload/reload a page with calc records and defining a page
reserve for the future new records. Is there any effect in the calc
algorithm with the page reserve sentence in the area ??? I remember than in
the past I had some problems extending a page with calc records, because the
clac algorithm consider the page range and if you extend the page range
there is a change in the calc algorithm. I'm wonder if in the case of page
reserve is there any effect in the calc algorithm ?? The idea is
unload/reload one area using page reserve of *** characters and after that
switch the page reserve to 0 characters.

TIA.

Javier S.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
consolidating journals ???
"how do other shops consolidate journals?

1) at offload time, append to daily file?
2) af offload time, append to file until X journals are appended, then
start with new tape?
3) at and of day, accumulate all journal tapes onto daily file?
4) do not consolidate - keep X number of journals (enough to cover data
since last full backup)

I chose to implement #1, but about once a year a jobs goes wild and
updates/deletes millions (or at least many) of rows and , despite 6
journals, the offloads cannot keep up with updating (the offloading and
appending taking more than the previous, sometimes over 10 minutes)

I am willing to admit that my approach my not be the best and look for
other alternatives ... so I am looking for how others do it

in other shops. is the time needed and possible delays caused by realtime
consolidation be worth the time saved if a non-auto recovery IS needed?,
or do other shops just waint until ""an event"" to consolidate the journal
offloads?

thanks,

Chris Hoelscher
IDMS & DB2 Database Administrator
Humana Inc
502-580-2538
choelscher@humana.com




The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: consolidating journals ???
"Chris,
I implemented the following years ago. I never had a problem with
journals getting backed up, but in a large volume shop, I could see it
happening. Then again, you can define a lot of journals to the system if
necessary. This also assumed a daily cycle of the system, or at least a
point in time that was considered ""end of day"".

1. An OFFLOAD GDG is started every day with no generations (empty).
2. A CUMULTVE file is created every day as an empty (NULL) file.
3. Every time a journal offloads, it creates the next generation of OFFLOAD
and it gets MOD onto the CUMULTVE file. This is done in the same job.
5. At the end of day, the CUMULTVE file is copied to the ARCHIVE file GDG
(and given a retention period), all the OFFLOAD generations are deleted and
the CUMULTVE is deleted and recreated (NULL). This is also done in one job.

I do the same thing with the log.

Doing it this way provides a few levels of comfort:

1. Since you read the OFFLOAD tape as soon as you create it, you know it
can be read.
2. If the CUMULTVE tape goes bad, you've got all the pieces (OFFLOAD tapes)
that went into it and it can be rebuilt easily.
3. You don't have to worry about how many times the journal offloaded - all
the data is in the CUMULTVE file.
4. You can easily see how many offloads occurred by seeing how many
generations of OFFLOAD have been created.


Joe Lupico
IDMS System Support
""Our World is a Happy World""

Outcomes