Journal Offloads - Don't Try This at Home

Discussion created by ca.portal.admin on May 17, 2005
Hi All,
I figured I'd pass on something I think I discovered today. It's not
something anyone should do, but....

There is a CV which cycles immediately on Saturday night, and apparently
stays up the rest of the week. As the CV was shutting down, a journal
offload was submitted. It started running just before the CV shut down, and
continued to run even after the CV had restarted. The offload indicated it
was going to offload J4JRNL even though it wasn't full. Everything was
clean with that job.
Now, last night I get a call that a journal offload job got a cc of 4.
This is a very little used CV and this offload was the next one to run after
Saturday night. When I looked at the job, it showed J1, J2 and J3 journals
as CV ACTIVE YES and J4 as NO. It also showed J1 and J4 journals as FULL.
The job got a cc 4 because it said that journal J4 was empty, even though it
was marked as FULL.
What appears to have happened is a journal offload was submitted, the
region was shut down (it got down before the journal started offloading I
think), the region was restarted (while the journal offload was still
going), then the journal offload completed. Because the CV started while
J4JRNL was offloading, the system marked it as FULL and not active to the CV
(even though it would be empty once the offload completed) and started using
J1JRNL. When J1JRNL filled, the submitted offload job picked the first
journal marked as FULL (J4JRNL) and tried to offload it. Since it was
empty, the job got a cc4 and I got called. I submitted another journal
offload which offloaded J1JRNL and everything got caught up.

I guess I learned that if a journal offload is running while a CV is
starting, CV marks that journal as not active to the CV and FULL. So even
though it gets offloaded, it doesn't get reset to empty and active to the CV
until the next time around. Interesting.

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

IDMS Public Discussion Forum


Re: CPU Effectiveness
"The fields used by DCMT D SUBTASK are different than the fields used in
displays such as DCMT D STAT SYS. The sysgen parm does not apply to the
subtask display.

The transition from Usermode to System mode and back is handled in
module RHDCWAIT. RHDCWAIT issues a call to the operating system
dependent module requesting the amount of CPU time expended since the
last time it was called. This called routine figures out the value and
adds it into the proper SCA time field, SCASYSTM if we were in System
mode, or SCAUSRTM if we were in User mode. These are the fields used for
CPU effectiveness.

The value is then passed back in a register where wait checks the sysgen
parms and adds the value to the proper non SCA time fields. These fields
are contained in the STR pointed to be TCETSTA.