Skip to Main Content
IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Categories Core OS
Created by Guest
Created on Feb 2, 2020

spawn() - Don't check "max active" of job queue and controlled end of subsystem for spawn() jobs (BCI)

Spawn jobs (BCI) are handled like normal submitted jobs. This mean that the current job queue needs to have enough "max active jobs" left to start a BCI job.

In my eyes the spwan() mechanism should always starts the requested jobs and ignore the "max active jobs" setting of the current job queue, because the spawn jobs are necessary parts/resources of the current running program/job. Because the OS has already checked and allowed the execution of the program, the program/job should then get all needed resources and no additional check against the job queue should be done anymore.

The second problem is, if a subsystem ends controlled it's not possible to start a spwan() job anymore. So the program can't finish its current work and stops with an exception instead of ending normally.


Use Case:

The best way for use is to call AIX/PASE functions like gzip, zip or sftp from RPG with spawn().
We are creating the BCI jobs only if they are needed and they end automatically after work is done.

- It's not possible to start such child processes on a job queues which allows only one job.
- If a job queue is used by different jobs parallel, it could happen that the job queue is temporally full so the program fails because spwan() is not possible
- In case of "end subsystem controlled" the program can not finish work, because spwan() is not possible anymore.


Idea priority High
  • Guest
    Reply
    |
    Apr 20, 2020

    Batch immediate jobs do not use a job queue, so the Max active jobs on the jobq does not apply to spawned jobs (BCI). However, the MAXJOBS on the subsystem description does apply to spawned jobs. Perhaps this is the limit you are experiencing. As for not allowing new jobs to start when the subsystem is ending, this may be an undesirable change in some environments, as well as an incompatible change. There may be other options you can use, such as iexits/cancel handlers to allow for proper cleanup.