Job Entry Subsystem (JES/POWER) Interface Modules

The Com-plete Remote Job Entry (RJE) functions and online utility UQ require an interface with the operating system's Job Entry Subsystem (JES) in order to submit jobs and retrieve job queue information. In order to provide modularity and JES independence, all RJE and UQ functions requiring interface with the installation's JES pass through the Com-plete JES Interface Module (JIM). The JIM is a collection of routines used by Com-plete and its utilities to accomplish functions that are dependent upon the installation's JES. A JIM exists for each JES or spooling system supported by Com-plete.

The Com-plete JIMs, along with the JES systems and operating systems in which they are supported, are listed below.

System JES2 JES3 z/VSE/Power OS
z/OS JESCSERV JESCSERV   z/OS 1.4 and higher
z/VSE     TTJIPOW3 z/VSE 3.1 and higher

This document covers the following topics:

z/OS JES Interface Modules

Com-plete’s JES interface uses the same interface as the Entire System Server. It addresses the life-of-job subsystem, i.e., the primary or alternate JES subsystem where Com-plete was initiated. Whenever you are upgrading your OS and/or JES environment, please contact Software AG support for updates to XCOMJESC. XCOMJESC issues SAF checks for class JESSPOOL. Applymod 10 has no influence on these checks.

Extended Console Server

On systems that support Extended Console the Com-plete Console Server should be used to receive the Console messages. If running in a Sysplex environment this is the only way to receive Console messages since there is no CRWTOTAB any more. The console messages are stored in a table an can be displayed with the UQ M (console display) function. Messages from 1, 2, 3 or all systems in a sysplex may be received according to the server configuration. Also the number of stored messages can be configured (default=512 messages). The Console Server is started automatically at Com-plete startup if a SERVER statement (see below) is encountered in the SYSPARM member. It can also be activated/deactivated dynamically using the SERVER statement in UCTRL.

Syntax:

SERVER=(name,TLINCONS,slots,consname,hcset,automsgs,scope1 ,scope2 ,scope3)

where:

name is a unique server name within each copy of Com-plete.
TLINCONS is the name of the server initialization program.
slots specifies the number of messages held in the incore table.
consname is the console name for MCSOPER Macro. It must be unique in the sysplex.
hcset (Y/N) specifies whether the hardcopy set is to be received by this console.
automsgs (Y/N) specifies whether messages that can be automated are to be enqueued to this console.
scope1 specifies the name of the first system from which messages are to be received or ALL to receive messages from all systems in the Sysplex. If not specified, only messages from the local system will be received.
scope2,scope3 specifies a second or third system from which messages are to be received. Do not code if scope1 is ALL.

Example:

SERVER=(CONSOLE,TLINCONS,2000,COMP51A,Y,Y,DAEF,DAEY)

Notes:

  1. Hcset=Y is required if outstanding replies are to be displayed. Note that only outstanding replies that arrived after the console was activated can be displayed.
    If Automsgs=N is specified, users will not see the system replies to their operator commands.
  2. If you experience a security message like the following during startup:
    ICH408I USER(complete) GROUP(SAGTEST ) NAME(TEST ID )
    MVS.MCSOPER.consname CL(OPERCMDS)
    WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED
    FROM MVS.MCSOPER.* (G)
    ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
    then you must give READ access to the MCS console for the Com-plete started task in your Security system. Contact your RACF/ACF2/TOP-SECRET administrator for assistance.