IBM Support

Sockets INITAPI Call Fails: Process Initialization Error

Troubleshooting


Problem

An application that uses the Macro Extended Sockets API (EZASMI) or one of its derivatives (EZASOKET or EZACICAL) performs an INITAPI call or another valid first call (for example, TAKESOCKET) and receives Errno 009C (156) - EMVSINITIAL 'Process Initialization error'.

Symptom

Other symptoms caused by this same problem include:

  • TSO commands that use TCP/IP (such as FTP) failing:

    • CEE5101C During initialization, the callable service BPX1MSS failed. The system return code was 0000000156 , the reason code was 0B250012 . The application will be terminated.
      CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4093 TO DATA SET: xxxx
       FTP      ENDED DUE TO ERROR+
       READY
      ?
       USER ABEND CODE 4093  REASON CODE 00000090
       READY
  • Attempts to login to the FTP server fail. If ACCESSERRORMSGS TRUE is specified in the server's FTP.DATA input, the following replies will be sent to the client:

    • 331 Send password please.
      Password:
      530-Error on setuid() function call, errno=112, rsncode=0B880012
      530-The process is currently not able to change UID
      530 PASS command failed
    If using FTP with SSL/TLS, the following replies may result:

      >>> PASS
      421 Open rejected due to insufficient resources.
      CZ1170 SETCEC code = 11
  • Attempts to use the OMVS command fail with the following messages:

    •  No session was started.  No more processes can be started for this UID.+
       READY
      ?
       Function = sigprocmask, return value = FFFFFFFF, return code = 0000009C, reason code = 0B250012
       READY
  • Attempts to logon to a Unix Telnet session will fail:

    • EZYTE27I login: user5
      EZYTE28I user5 Password:
      Welcome to z/OS CS telnet

       EZYTY10E login_tty: spawnp error -1
       EDC5112I Resource temporarily unavailable. rsn=0B250012

Cause

One of the OMVS limits on the maximum number of processes has been reached for this application.

Diagnosing The Problem

The SYSOMVS CTRACE entries for the event (and SYSTCPIP CTRACE OPTION=(SOCKET) entries for Macro Extended Sockets APIs) will also show reason code 0B250012 - JRMAXCHILD 'The maximum number of processes for this user ID has been exceeded'. This same error can occur in applications using other sockets APIs on their first socket call.

If the address space generating this error is still active, the following commands can be used:

  • DISPLAY A,jobname, and note the reported ASID.

  • DISPLAY OMVS,ASID=aaaa, specifying the above ASID. Note the reported Process IDs and select one.

  • DISPLAY OMVS,LIMITS,PID=processid, specifying the above Process ID. The line reporting MAXPROCUSER will list the number of active processes on the system using this userid, the peak usage for these since IPL (high water mark), and the current limit being used.

Resolving The Problem

You can modify the following items to correct the problem:

  • The MAXPROCUSER specification in the BPXPRMxx PARMLIB member. This can be updated dynamically using the SETOMVS command. By default, this applies to all users on the system.

  • The PROCUSERMAX specification in the OMVS segment associated with the started task(s) userid. If specified, this value will override the PARMLIB specification for all applications running under this userid. This is managed by way of the SAF product being used. Consult the associated documentation to understand for information on how to update (for RACF, this is the ALTUSER command) and when the updates apply.

    • TIP: Use this mechanism to increase the value for started tasks that need it, rather than increasing the system wide specification.

  • Assign separate userids to all server started tasks. If multiple address spaces use the same ID, all of their processes count towards the total (not just what one address space uses).

    • NOTE: The key item here is the OMVS UID being assigned. Even if each started task has a separate userid assigned to it, if they all have the same OMVS UID they all are restricted to the single limit. This is also controlled by the OMVS segment for the userid.

You may also want to consider setting LIMMSG to either SYSTEM or ALL in the BPXPRMxx PARMLIB member, so that a BPXI040I message is issued whenever one of the OMVS limits is being reached.

[{"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"All","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"1.6;1.7;1.8;1.9;1.10;1.11;1.12;1.13;2.1;2.2;2.3","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
15 June 2018

UID

swg21222921