|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.