asked on

Why so many jobs for a qshell command?

I've created a command, thanks to the help of some of the experts here, that retrieves the record count of a .csv file in the IFS. When I call this command interactively, I don't have any problems. But if I call the command from a program running in batch, all heck breaks loose. I get 5 different jobs that start, which causes my command to fail because the subsystem we run it in only allows a total of 4 jobs to run at a time. I'll post the QSH command that I run at the end of this post. The questions I have are as follows:

1. Why so many Jobs for this command?
2. Is there a way I can limit the number of Jobs a QSH command starts?

Here is the command I run.

QSH CMD('datarea -w /qsys.lib/mylib.lib/ifsrcdcnt.dtaara `cat file.csv | wc -l`')

Any help will be appreciated.
Peteie

Member_2_276102

Peteie:

Simple answer is that you're running a kind of emulated Unix shell on a non-Unix system. Those additional jobs are kind of the equivalent of additional threads. If you limited the number of active threads under Unix, you'd have similar results. Under OS/400, these generally appear as BCI (batch immediate) job type.

However, that doesn't address your concern about your subsystem limit of 4 jobs.

We limit our subsystems similarly, but don't have the same problem. We place our limits on the job queues that feed the subsystem. Beyond that, we generally allow *NOMAX for the subsystems themselves.

So, while 4 jobs at a time might be allowed to enter the subsystem through job queue ABC, once a job starts, it's allowed to spawn additional helper jobs as needed. Since the only way such jobs can get into the subsystem is by an already running job spawning them off, we haven't had to be concerned about *NOMAX.

I'm not sure that limiting QShell spawned jobs is a workable direction to go. I haven't explored the possibility, but I don't see how it could be made to work.

Tom

peteie

ASKER

I found a post on iseries network, that showed some examples of calling QShell commands just like a regular program. Have you heard of anyone else doing this? It seems like a feasible sollution and apparently when you call a command this way it runs in the same job that you called it from. I've begun playing with it, but I'm not to where I would like to be yet.

As for the limiting the JOBQ to 4 jobs at a time and having the subsystem be *nomax, wouldn't that cause a bunch of jobs to be running in the subsystem at the same time? Correct me if I'm wrong but wouldn't the following happen?

jobq max jobs = 1
subsystem max jobs = *nomax

The operator submits pgm1 to the jobq. Since there is open space on the subsystem to run it is run, thereby taking it off the jobq.
The operator submits pgm2 to the jobq while pgm1 is still running. Again there is open space on the subsystem to run so it too is run, again taking it off the jobq.
etc...
Now I've got 2 or more programs running even though the jobq only allows 1 at a time?
Or does the program stay on the JobQ until it is done running?

We don't actually limit the jobq or subsystem to 1 job, I just used it for simplicity.

Thanks for any help.
Peteie

ASKER CERTIFIED SOLUTION

Member_2_276102

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

peteie

ASKER

Tom,

Thanks for the help. After reviewing your suggestions with my dept. manager, we decided to raise the number of jobs allowed on the subsystem. We only went to 10 for now. We wanted to see what affects it might have before raising it any higher. That was a great explanation of the relationship between JOBQs and SubSystems.

Peteie