RE: An ugly exit. *EXITRG that is.

I nkow what product I would be dropping...

> -------- Original Message --------
> Subject: An ugly exit.  *EXITRG that is.
> From: "Jeff Crosby" <jlcrosby@xxxxxxxxxxxxxxxx>
> Date: Wed, March 02, 2005 11:20 am
> To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
> 
> All,
> 
> I have posted on this before, and here I go again.
> 
> For the 3rd time since going to V5R3 last September, I lost all FTP and
> REXEC exit points.  This happened yesterday morning.  Since 98% of customer
> orders arrive on the i5 via FTP and are processed by a command issued via
> REXEC from another system, this is a real problem for us.
> 
> The first time this happened was on the 270, we have since gone to an i5 520
> where it has happened twice.  This morning many of the MSF exit points were
> missing.  All 3 times it has happened this way.  FTP and REXEC one day, MSF
> the next.  A simple call replaces the FTP and REXEC exit points, but MSF
> exit points must be replaced manually one by one.
> 
> Each time it has happened, it was immediately after either loading or
> upgrading the Standguard Antivirus from Byteware.  I pitched a Holy H***fit
> to Supportline.  They have at least 8, and maybe 10, developers working on
> finding out what in the world is going on.  IBM says they don't believe that
> Standguard is the problem, per se, but that something that Standguard is
> doing is not being handled properly by IBM.  IBM and Standguard are in
> contact with each other on this issue.
> 
> We made a bit of headway yesterday by finding this in a joblog:
> 
> CPD3C69 Diagnostic 30 03/01/05 05:02:42.839032 QUSRGFA2 QSYS *STMT QP0FEPFS
> QSYS *STMT
> >From module . . : QUSRGFCM
> >From procedure  : CHKAUT_OBJ_HDLR
> Statement . . . : 78
> To module . . . : QP0FSCAN
> To procedure  . : Qp0fCallScanExit__FP10EPFS_VnodeiLUi23qp0lScan
> ExitProgramType
> Statement . . . : 99
> Message . . . . : Object QUSEXRGOBJ in library QUSRSYS recreated.
> Cause . . . . . : The secondary space pointers in object QUSEXRGOBJ were not
> set, and the object is not usable.  The object has been recreated with new
> secondary spaces.  A loss of data may have occurred.  It is recommended that
> you restore this object from your backup tapes.
> 
> The above was from job 068258/QSYS/QCSTCTHRMD.  (A clustering job.  We don't
> use clustering so IBM removed the autostart job entries.)  This explained
> how the exit points disappeared (because QUSEXRGOBJ was recreated) but not
> what caused QUSEXRGOBJ to become unusable.
> 
> The Standguard virus scan also failed last night.  Something about an exit
> point.  Go figure.  I'll be calling them shortly.
> 
> If anyone else is having a similar issue with exit points and/or Standguard,
> I think IBM would be interested.  They're looking for all the info they can
> get.
> 
> -- 
> Jeff Crosby
> Dilgard Frozen Foods, Inc.
> P.O. Box 13369
> Ft. Wayne, IN 46868-3369
> 260-422-7531
> 
> The opinions expressed are my own and not necessarily the opinion of my
> company.  Unless I say so.
> 
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.