• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Sleeper performance


Well Known Member
Is it me?
Job's submitted through Sleeper that take as much as 15 minutes to complete
only take 10-20 seconds to complete when manually ran.

Are there performance issues with Sleeper? I don't think it's the SBS set
up, though it could be.


Active Member

You aren't giving us much to go on here. Since I don't know you level of
expertise on the AS/400, I am going to risk insulting your intelligence, (but
then, if you ask the question, I guess you'll have to take what you get).
Simple things first.

1. Does it really take 15 wall clock minutes of run time, or is the job waiting
in a job queue?
2. Is Sleeper submitting the job at the actual schedule time, or is the submit
delayed. It seems to me that there is a parameter in Sleeper to indicate how
often it is supposed to "wake up" and check for jobs to run, but I might be
wrong there.
3. Have you check the "Job Ended" message in the System Log to see how much CPU
time the jobs are using in each environment? That may or may not give you a
4. You question the SBS setup yourself. Why not run it manually in the same
SBS that Sleeper uses. That might rule this variable out, or indicate that you
need to go down that path farther.
5. This one is a little more complex (and long winded). We have a job that
runs several times a day and cruises through the F4211 file. During regular
office hours it runs in less than 5 minutes. However, at 4:00 AM it takes 10-15
minutes. Now you would think that at 4:00 AM when the system is very inactive,
the job would run faster. What we discovered (or at least deduced) is that this
is a result of the way that OS/400 manages memory. If a program needs a record
from a file, OS/400 reads it from the disk into memory and them provides the
program with the memory address. When the program is done with the record,
OS/400 does not necessarily purge it from memory. If another program needs the
record, OS/400 just provides the memory address to the new program rather than
waste time by reading from disk again. Eventually, OS/400 does purge records
from memory that have not been used recently. To make a long story longer, we
deduced that during regular office hours, there is lots of activity against
F4211, so lots of F4211 records are in memory. Therefore, the job runs faster.
At night, there is little activity and OS/400 has purged all the records, so it
has to read every stinking record from disk, resulting in a longer run time.

Hope this helps.

dale_draper <dale.draper@seu.sega.com> on 07/20/2001 11:06:38 AM


Well Known Member
Your right, I did assume a lot. I know enough about OS400 to be dangerous,
but performance issues are a weak point.

1.Yes, the looking at the joblog (dsplog) the job in question takes about 20
minutes to run (the CPU time slice is much smaller of course @140? seconds)
2. sleeper is awake at all times, and is submitting the jobs on time. So
it's not a matter of the job submitting late and me mistaking that for a
long running job . :)
3. CPU time slice is smaller when not submitted via sleeper
4. Both the manual and Sleeper submitted jobs go through the same subsytem,
I realized that after I sent the 1st message. So the subsystem's size can be
ruled out as a factor.

5. Oh, I've noticed this before with some other things as I'm usually the
1st person signed on. I kind of *intuited* that this was the case from
things I've learned, but it's nice to have confirmed. But the speed
difference from this I wouldn't think would cause the massive disparity I'm
seeing in run time.

6. My thought (guess!) was that these job's, being submitted by Sleeper may
be running under another layer of programming that is slowing it up? That
is, that sleeper is indexing(?)(keeping track of) the jobs as they run to
track them?

That's why I asked if Sleeper was a know performance inhibitor, AFAIK ,
everything else has been discounted. But I've been wrong before.


Active Member

If both jobs are running in the same subsystem, I guess the next thing I would
do is to compare the JOBD for each job. There may be some parameter in the JOBD
that would affect run time.

As far as I know, Sleeper is a "job launching" tool only. It does not monitor
the jobs after they are submitted, so I really don't think that the Sleeper
system itself is the problem.

What do you mean that the CPU time slice is smaller when not submitted from
Sleeper. Where are you seeing the time slice?

What is the Total CPU time used by each of the jobs?


"Draper, Dale" <dale.draper@seu.sega.com> on 07/20/2001 03:48:20 PM