Re: Disappearing exit points (Jeff Crosby)

[Steve.Hinrichs@xxxxxxxxxxxxxxx]

Jeff - Here is something to try.  It is from SI06294, Missing
System-Supplied Exit Points.  I can send you a document off-line if you
would like about SI06294.

CALL QSYS/QUSDRGPT PARM('EXIT_NOT_FOUND      '  'NOTF0UND' X'00000000')
                                                              
 After the recovery code has run, all exit points stored in   
 the                                                          
 registration object (QUSRSYS/QUSEXRGOBJ) should be           
 displayed       via the WRKREGINF command.  This is object   
 type *EXITRG                                                 
                                                              




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steven Hinrichs
Software Engineer
Help/Systems Inc.
Phone: 952.563.1672
Fax: 507.356.2285
steve.hinrichs@xxxxxxxxxxxxxxx

>
> message: 6
> date: Thu, 28 Oct 2004 07:26:10 -0500
> from: "Jeff Crosby" <jlcrosby@xxxxxxxxxxxxxxxx>
> subject: Disappearing exit points
>
> This has been quite a week.
>
> After Monday night's (10/25) SAVLIB(*NONSYS) backup in a restricted
state,
> neither FTP nor REXEC would start again.  This is a real problem for us
> since that is how _all_ our sales reps orders get into the iSeries.
After
> trying everything I could think of (which doesn't take long) I opened a
PMR
> with Supportline.  What the tech determined after a relatively short
period
> was that all the exit point for FTP and REXEC were gone.  Completely.  In
> toto.  It wasn't just that the programs weren't listed in the exit
points, I
> mean the actual exit points themselves did not exist.
>
> It was a known problem that usually happens 'right after a release
update'.
> I upgraded this 270 to V5R3 a month ago, and we do a SAVLIB(*NONSYS)
every
> night so it had quite a number of chances to fail.  He had me do a couple
of
> program calls out of lib QTCP that reinstalled all the exit points and
all
> was well.  Or so I thought.
>
> Tuesday at 1pm or so, I did a CHGSMTPA (which will be the subject of
another
> post later).  When that didn't work as planned, I changed it back and
tried
> to STRMSF and STRTCPSVR(*SMTP).  MSF would not start.  No email in or
out.
> One of the escape messages indicated an exit point program.  I called
back
> in on that same PMR, thinking it might be related.
>
> To make a long story short, it wasn't related.  We were without email
Monday
> afternoon, all day Tuesday, and I missed part of a WDSC seminar Wednesday
> morning getting it straightened out.  MSF was missing 15 exit points.
They
> had disappeared between Monday night and Tuesday noon.  It took a _long_
> time for the tech to find it, but there was an internal document that
> started out with the following:
>
>
|--------------------------------------------------------------------------|

> | These exit points and exit programs are for QMSF/ SNADS and any other
|
> | application that will be using the mail server framework exit points
and |
> | programs.  These are part of the Operating System and should always
exist|
> | if the installation was completed correctly.
|
> |
|
> | On occasion, errors may be encountered with the system load and some,
if |
> | not all, of the exit programs will be missing.  The data below can be
|
> | used by IBM Support to get the exit programs re-defined.
|
> |
|
> | These should not be faxed to the customer.  Walk-through assistance on
|
> | the exit programs should be worked under a Consult Line contract.
|
>
|--------------------------------------------------------------------------|

>
> What followed was a list of 26 exit points that might be missing.  We
were
> missing 15 of them.  Note the last line.  There is no program to put
these
> back in, IBM wants to charge Consult Line fees to fix a 'failed
> installation'.  The installation showed no failure a month ago and worked
> for that long.  Note also the document was also not to be faxed to me,
the
> customer.  I put the exit points in manually.  My other alternatives were
1)
> reload TCP1, 2) reload OS/400, or 3) pay IBM to do 1 or 2.  The tech also
> told me that a complete reload would not necessarily fix the problem.
>
> Hey, this goes a long way toward increasing my trust in IBM.  Why the
> secrecy?  I think I will call back and talk to a duty manager or someone
to
> try to find out the whole story here.  Any suggestion of who to call is
> welcome.  The handling of this sounds more like Microsoft than IBM.
>
> --
> 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.
>
>