Subject: RE: CICS error
From: Frank Swarbrick (Frank.Swarbrick@efirstbank.com)
Date: Mon Apr 07 2008 - 14:41:16 EDT
>>> On 4/4/2008 at 1:47 PM, in message <003701c8968c$df396e90$9dac4bb0$@com>, Dennis McLoud<dmcloud@systronicsinc.com> wrote: > Are you running CICS/TS? Are the programs all running below the line? We > have not seen this problem since going to CICS/TS and moving most of our > programs above the line. You should only see this error after program > space > compression. CICS doesn't need the pointer to the library unless the > program > is flushed from memory. You could at least make the problem less > frequent by > giving CICS more DSA. I think there is one other case when this can happen. It appears, though I can't prove it, that if a program is not used for quite a long time it also gets 'removed'. We have a CICS that is only used during business hours. For a while we were not cycling it at night, we'd just leave it up. We generally implement CICS programs while the primary production CICS region is down; thus no PHASEIN. But the secondary region (the 9-5 region) would still get this error the first time an attempt was made to use this program in the morning. My assumption is that at some time during non business hours, which lasts over 12 hours, all of the 'inactive' programs are 'flushed', so that an attempt is made to reload it; bit it fails since the pointer is no longer pointing to the correct area (since the phase has moved elsewhere). If anyone has more information on this I'd be interested to know about it. What I don't understand is why CICS/TS cannot be modified so that, if it hits the situation where it would currently issue the DFHLD0203 error, it would instead do an implicit phasein. If I submitted this requirement to WAVV would you all vote yes on it? Frank
This archive was generated by hypermail 2b25 : Fri May 16 2008 - 23:50:07 EDT