× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: An Interesting One
  • From: gmihajlo@xxxxxxxx
  • Date: Thu, 30 Mar 2000 16:08:41 -0600

One reason why an AS/400 job would not close down for some time after it had
ended processing is that there there is a large joblog created upon  completion
of this job and it simply takes time for system to spool joblog info to a spool
file which will prevent job from being ended until this is done. You can check
this by WRKSPLF for this job after the job had finished processing but still
hasn't ended where you should be able to see that there is a joblog spoolfile
(QPJOBLOG) still open with growing number of pages. You can avoid this for
example by changing LOG TEXT attribute in job description used by this batch job
to *NOLIST if you do not want to have joblog spoolfile created.
Another thing to watch for in the joblog is the excessive occurence of messages:
'Indicator variable required'. If you see a lot of them filling up the joblog,
you might consider getting rid of them by using a workaround for still open
BMR50023 (which will fix this problem in ORD400B) which requires a simple code
change, providing that you do have and use ADK to do in-house mods on BPCS
programs. If you want detailed description on how to change ORD400B to get rid
of this message, please let me know by replying to gmihajlo@ssax.com and I will
send you a document with the instructions, otherwise, you will have to wait for
BMR to become available.
If the above is not your case, you might want to change job (while active) to
have LOG atribute set to (4 00 *SECLVL) and LOGCLPGM(*YES) and look into joblog
after the job ends, in order to see what took so long for job to end.
Goran





tbutala@dentsply.com on 03/30/2000 03:28:00 PM

Please respond to BPCS-L@midrange.com

To:   BPCS-L@midrange.com
cc:    (bcc: Goran Mihajlovic/SSA/US)
Subject:  An Interesting One





I have an interesting one happening right now.  We have three AS/400s, two of
them identical.  We run BPCS 6.0.04.  We just upgraded our operating system to
V4R4.  On the one AS/400 our batch allocation program ORD400B completes
processing but does not close down for a long period of time.  That's right, all
BPCS jobs will clear through the job stack, the status of the job goes to END
but it sits in the END status for an hour or more before it finally closes on
its' own.

Personally I have never seen a job do this before, I've seen the hang where I
had to cancel them, but this job will eventually close out on its' own.  Because
this problem started once the new release was applied this weekend my
assumptions (yes I know about assumptions) is that this is an Operating System
problem.  However, this problem does not occur on either of the other AS/400s.
We have contacted IBM and they have had us load a number of new PTF's and wanted
us to run DBMON over the process to create new access paths (which we did) all
to no avail.  SSA does not have any answers for us either.

My question is simply, has anybody else had a similar problem and if so what
resolved the issue.


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---



+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.