It wasn't a Zombie at all! It was just Old Man Jenkins in a scary costume
!
What started as just an operator console message of "BATCHRDR ENCOUNTERED
UNEXPECTED ERROR 20034" and a RDR file being left open turned out to just
be a
disk full error on a less-than-obvious disk.
Don DeCosta
We have an ancient home-grown batch system that runs on AUTOLOG1 and take
s
it's command from RDR files sent to it.
It's trying to read from the RDR, getting an error and leaving the RDR fi
le
open. When I re-ipl (because, I'm a PC, I reboot to fix everything) it t
ries
to read the RDR again,
There could be some PSF software server active: it opened spool files and
had to "agree" with a purge. When such a server didn't react, the file
remained in *PURGED* state. Isn't there a FORCE option on the PURGE commad?
You lay look for userids SFCM* and PDM*, which where used in sample files.
C
On Wed, 10 Mar 2010 15:09:19 -0600, David Boyes w
rote:
Nope, nothing on the CONSOLE statement in the directory entries for MUCOP
ER or
AUTOLOG1.
But if that had been the problem, Wouldn't I be getting a different SPOOL
ID
whenever the spooling id was logged off/on and certainly a new SPOOLID
On Wed, Mar 10, 2010 at 4:09 PM, David Boyes wrote:
> Check the directory entry for MUCOPER and if the CONSOLE statement has the
> word MUCOPER on the end of it, remove it and log MUCOPER off and on. It
> will
> stop spooling it's console, and that file will go away and never come back.
>
Unlike
Check the directory entry for MUCOPER and if the CONSOLE statement has the
word MUCOPER on the end of it, remove it and log MUCOPER off and on. It will
stop spooling it's console, and that file will go away and never come back.
This is a small disaster recovery VM/ESA 2.2 system whose spool space
was allowed to fill up while on standby.
After running SFPURGER and re-ipling I still have a RDR file that won't
die.
The SPOOLID is 5237, here's what I've done.
q rdr autolog1 all
ORIGINID FILE CLASS RECORDS CPY HOLD DATE T
