Jobs Not Ending

[GlenKerner]

First I need to say I already know the resolution of getting the job out of the system (IPL). My question is: Why am I having jobs (1 friday and 1 today) not ending when I ENDJOB and even when I use ENDJOBABN. The first was Showcases SCSERVER job (4.0) running in a test environment and the last one happened when I used DSPJVAPGM hit Sys Req 2 because it had not done anything after 15 minutes. Then I ended the job *immed waited 1 hr and finally endjobabn. Of course the job is not in Joblog pending which means only an IPL will get it out of the system. I thought IBM had pretty much fixed these problems. I'm running V4R4 and I'm current on all PTFs. Glen Kerner Brookshire Brothers, LTD Gkerner@brookshirebros.com

[David Abramowitz]

Have you tried ending the job, and pressing F4 rather than ENTER. Then changing the end option from *CNTRLD to *IMMED? Dave

[GlenKerner]

Yes I did. I even tried disconnecting the job it didn't work. Varying off the device didn't help either. I know that once a job goes end with Joblog pending that is is no longer in any subsystem it is in never never land. My question is why are jobs going to this state more often. There was a problem with DSPTAP and a PTF to fix it now I have DSPJVAPGM do it and whatever command Showcase is using in there AS/400 server (usually call SCSERVER).

[Guest.Visitor]

Did you try LOGLMT(1) on ENDJOB? Chris

[GlenKerner]

I tried changing the log limit to 1 (was 0) and I got the message the job completed, BUT the job is still in Joblog pending status. As I said before I've run into this before and even IBM says that once the job goes to this status only an IPL will correct it. The question was: Why is this happening?

[nycsusan@hotmail.com]

This same thing has happened to me before and I have never received a good explanation for it. I tried ending the jobs with *IMMED and a 0 delay, but no luck. The log indicated it was ending but it never would clear out of the queue. Sometimes ending the subsystem was sufficient, an IPL was not always necessary. This has not happened since we upgraded to v4r4 last March. Also, maybe it's coincidence, but every time a couple of jobs get "stuck" this way, the system seems to crash right afterwards ... as if this is a warning of some sort. It could be coincidence; I am just reporting my observation. If you find an explanation, I'd appreciate it if you would post it here.

[Guest.Visitor]

Susan, We had a similar problem a while back (could have been March but I think it was longer ago) due to a defective PTF. We were able to limp along until we got it removed (some recent PTFs greatly simplies the removal of PTFs by fixing several bugs in the removal process). The first thing to check is the service recommendation. What do you mean by "crash". If you system is beging taken down without intervention you should have IBM do a post mortem analysis to determine the cause. We have had our system take down five times this year due to two problems. Prior to this we had at least three years of flawless service. Each time IBM was able to pinpoint the problem and provide a workaround until a fix was completed. David Morris

[nycsusan@hotmail.com]

What do you mean by "crash"? I mean that we had one of those "unplanned outages" that the 400 is not supposed to have! Our machines are not located here with the developers, they are physically in another city in another time zone, so it's our data center team that works with IBM to get the machines up and running again. In my experience, when this has occurred, it's typically preceeded by a LOT of activity - job queue's backing up with a lot of IO intensive things running at once. The last time, a TON of CPYF's were submitted to several different JOBQ's at once (hitting different files of course). That seemed to hose things up. A day or two later, we had what the data center called a "disk crash".

[GlenKerner]

So the answer to my question is that not even IBM seems to know why it is still happening with different functions (not consistant either). Thanks for all the input. I think my AS/400 Support (3rd party) will hear about this in detail and hopefully they will report it to IBM.