CPF1269: Program start request rejected

What it means

A program start request is how a remote system asks IBM i to start a program for it over an APPC (LU 6.2) conversation. DDM over APPC, SNA distribution, display station pass-through and many older client connections work this way. The target system has to check the user, find a subsystem with a matching communications entry, build a job from the job description, and start the program. If any step fails, the request is rejected.

The target system then posts CPF1269 to QSYSOPR and the history log (QHST). The message includes a reason code. On V2R3 and later the message help also includes the meaning of that code. The same codes can appear in CPF1267, and on the system that sent the request they can show up in CPF4805.

The codes fall into groups. Codes in the 400s mean a resource couldn't be reached, such as a device not allocated to an active subsystem (401) or the QSERVER subsystem not active (413). The 500s mean an object is missing or damaged, such as the job description (501). The 600s cover routing and program problems. The 700s are security, such as 704 (password not valid), 705 (not authorized to the device), 726 (user profile disabled) and 730 (password expired). The 2000s are protocol errors in the request header.

Common causes

• The user ID or password sent by the remote system is wrong (704 or 713), or the profile is disabled (726) or its password has expired (730).
• The user has no authority to an object the job needs, such as the device, job description, program or a library on the library list (705 to 712).
• No active subsystem has the communications device allocated (401), often because QCMN or the subsystem with the communications entry isn't started.
• No routing entry matches the request (604), or the program to start isn't in the named library or the system library list (605).
• A job description, output queue, class or library named for the job doesn't exist (501 to 504).
• A subsystem, communications entry or routing entry has reached its maximum number of active jobs (406 to 408).

How to find the problem

1. Display QSYSOPR with DSPMSG QSYSOPR on the target system, put the cursor on CPF1269 and press F1. The help shows the device, the reason code and, on V2R3 and later, what it means.
2. Search the history log with DSPLOG LOG(QHST) MSGID(CPF1269) to see when it started and whether the reason code is always the same.
3. On the system that sent the request, look for CPF4805 in the requesting job's log. It may carry the same reason code.
4. For a security code, check the profile with DSPUSRPRF and the object's authority with DSPOBJAUT.
5. For a 401 or 604 code, check which subsystem should take the request with DSPSBSD and look at its communications and routing entries. WRKSBS shows which subsystems are active.

How to fix it

• For 704, 713, 726 and 730, correct the user ID or password on the sending side, enable the profile with CHGUSRPRF STATUS(*ENABLED), or change the expired password.
• For 705 to 712, grant the user the missing authority with GRTOBJAUT, for example to the job description or library named in the job's setup.
• For 401, start the subsystem that has the communications entry, such as STRSBS QCMN, and check that it allocated the device.
• For 413, start the QSERVER subsystem.
• For 604 and 605, add or correct the routing entry, or put the program where the request expects it.
• For codes not listed here, look up the full reason code table in IBM's documentation for your release.

DSPMSGD MSGID(CPF1269) MSGF(QSYS/QCPFMSG)

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your IBM i release.