RE: Is there a answer for this?

This thread has been very interesting.  We have the same problem here, but
we have already tried most of the suggestions.  I have saved the responses
from Neil Palmer and Jim Franz, as we haven't tried these previously.  We
have added *pssr subroutines to some of the programs which users seem to
shut down most often.  We have error indicators on the calls.  We have
MONMSG.

We have a standalone AS400 in each of our warehouse facilities which now
number over 20.  Obviously this means we have a lot of users signed on at
any given time.  The larger facilities are almost 24/7.  You can try to
educate people until you are blue in the face, but everytime you have
turnover and the new night warehouse manager shuts it down, you have it all
over again.

 I feel most of the problem here is that we use invite with an indicator in
all our screens, as we have coded a timeout as part of our standards in all
our online programs.  The indicator is set on just before the screen write
and set off right after it is read.   Most of the time the error handling
we already have in place does take care of the problem.  But occasionally,
we have one that gives an error that we have coded for, but the error
handler for some reason or other just goes to left field.  Recently we got
the following message over and over at one of our remote sites.  It
evidently went into a loop for several hours, before the system operator
finally contacted corporate, because the system was so slow.  It created
several hundred job logs.  The one I have saved is 260 pages.  We are still
scratching our heads.  Every scenario we check has error handling in place,
yet it still went in a loop.  It gave CPF4740 over and over.

 Message . . . . :   No invites outstanding for file SA3020FM in library
   GLAZER.  (C I)
 Cause . . . . . :   No invite-program-device operations were outstanding
when
   a read-from-invited-program-devices operation was requested. Recovery  .
. .
   :   Before the program attempts a read-from-invited-program-devices
   operation, ensure that at least one program device is invited. Correct
the
   error, if necessary, and try the request again. Possible choices for
   replying to message . . . . . . . . . . . . . . . :   C -- Request is
   canceled.  Escape message CPF4744 is sent. I -- Request is ignored.
Control
   is returned to user.

Anyone have a suggestion for this one!

Thanks
Valene M. Williamson
Glazers
Dallas TX




                                                                                
                
                    Buck Calabro                                                
                
                    <buck.calabro@aptissof        To:     
MIDRANGE-L@midrange.com               
                    tware.com>                    cc:                           
                
                    Sent by:                      Subject:     RE: Is there a 
answer for this?  
                    owner-midrange-l@midra                                      
                
                    nge.com                                                     
                
                                                                                
                
                                                                                
                
                    02/27/01 09:43 AM                                           
                
                    Please respond to                                           
                
                    MIDRANGE-L                                                  
                
                                                                                
                
                                                                                
                




Tom,
Aside from Don's motivational speech <big grin> look at your programs;
especially the one giving the error.  Your I/O should trap errors.  In RPG,
you should be putting an indicator in the LO columns or using the (E)
opcode
extender.  In CL, use MONMSG.  Once you've trapped the error, don't ignore
it - do something with it, even if it's DUMP and terminate.  The
post-mortem
is valuable in and of itself.

Buck

> -----Original Message-----
> From:   Don
> Sent:   Monday, February 26, 2001 6:49 PM
> To:     MIDRANGE-L@midrange.com
> Subject:     Re: Is there a answer for this?
>
> Yeah, tell the sales idiod that if he/she can't learn to signoff properly
> that their replacement will be given a shot at trying...!
>
> On Mon, 26 Feb 2001 tkennedy@harcourt.com wrote:
>
> > Someone in the Telesales department shuts down there AS/400 session
> without
> > properly signing off the system, when this occurs that session
> > will consume more than 65% of the CPU unless the job is manually ended.
> >
> > Does anyone have any ideas or suggestions to combat this problem? Our
> > system is at V4R4...
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---