Endevor Webservices WSEWSSTC Parameters

book

Article ID: 195554

calendar_today

Updated On:

Products

CA Endevor Software Change Manager (SCM) CA Endevor Software Change Manager - ECLIPSE Plugin (SCM) CA Endevor Software Change Manager - Enterprise Workbench (SCM)

Issue/Introduction

Endevor WebServices requires the SPAWNED Task WSEWSSTC to be defined. Is there an explanation for the meaning for these parameters
WSEWSSTC SERVICE SERVER_NAME=MVS_START_SERVER,                
             DEALLOCATE=TERMINATE,                            
             LOST_CLIENT=DEALLOCATE,                          
             MAX£_SERVICES=100,                               
             MAX£_CLIENTS=1,                                  
             MAX£_PROCESSES=100,                              
             SERVICE_UNAVAILABLE=START_SERVICE,               
             START=SPAWN_ONLY,                                
             SIGNON/NOPASSCHK=SERVICE      


Resolution

The parameters used to define a service appear below.

service_name  SERVICE  SERVER_NAME=server_name,
              SERVER_RID=server_rid,
              SERVER_PRID=server_rid,
              SELECTION=FIRST¦BALANCED,
              MAX#_PROCESSES=,
              MAX#_SERVICES=,
              MAX#_CLIENTS=,
              SCOPE=LOCAL¦GLOBAL,
              CLIENT=ANY¦SPEC,
              SERVER_UNAVAILABLE=QUEUE_CLIENT¦
                                 FAIL,
              SERVICE_UNAVAILABLE=START_SERVICE¦
                                  START_SERVICE/QUEUE_CLIENT¦
                                  WAIT¦
                                  WAIT/QUEUE_CLIENT¦
                                  FAIL,
              START=SPAWN_ONLY¦EXTERNAL_PERMITTED,
              DEALLOCATE=TERMINATE¦AVAILABLE¦UNAVAILABLE,
              LOST_CLIENT=HOLD¦DEALLOCATE,
              SIGNON=SERVICE | SIGNON/NOPASSCHK=SERVICE
  • service_name
    Name of the service being defined. This name can be a maximum of 20 characters in length and is the service name segment of the 30-byte SPAWNID that a client uses with the #CCI SPAWN function call to request this service. (The SPAWNID is made up of the standard leading '#' character, the eight-byte SYSID, which is the CAICCI subsystem targeted for the SPAWN request, and the one-byte null followed by the 20-byte service name.)
  • SERVER_NAME
    The name of the server for this service. This name can be a maximum of 20 characters in length. The server is the platform-specific task that initiates and controls the physical process whose execution defines one or more logical services.
    Service definitions usually follow their respective server definitions, in which case the server name need not be re-specified here. However, if the service definition is for a built-in server or a server that was defined earlier, this parameter must be specified.
  • SERVER_RID
    The 30-byte CAICCI RECEIVER ID for the service's server. The Spawn Server assumes that the name of the server is also its RECEIVE ID unless it is overridden by this parameter. Use this parameter primarily when a service is supported by multiple copies of its server.
    Collectively, the servers are referred to by their common server name; individually, they are accessed by their unique CAICCI RECEIVE ID.
    As with the SERVER_NAME parameter, this parameter need only be specified when the service definition does not follow its server definition.
  • SERVER_PRID
    The 20-byte PRODUCT ID segment of the server's full RECEIVE ID; the SYSID defaults to the host where the Spawn Manager resides. This parameter should be used instead of the RID parameter unless the server resides on a remote host.
    As with the SERVER_RID parameter, this parameter need only be specified when the service definition does not follow its server definition.
  • MAX#_PROCESSES
    The maximum number of physical processes that the server is permitted to have active simultaneously. When a client spawns for a service, the Spawn Manager tries to satisfy the request from its queue of available services. If no applicable service is available or the client requests a dedicated process, the Spawn Manager directs the server of the service to start another process if the MAX#_PROCESSES value has not been reached. When this limit is attained, the SPAWN request is either failed or queued for a pending service, depending on other SPAWN or service options. The default is no limit.
  • MAX#_SERVICES
    The maximum number of logical services that can be supported by a single physical process. When a process becomes active, it can elect to remain as a single physical task, assigned only to its spawning client, and terminated at its completion, or it can optionally issue the #CCI SERVICE call to create one or more logical tasks limited by the MAX#_SERVICES value. These logical service tasks, in turn, can be shared by multiple clients concurrently, or be deallocated and reused by multiple clients serially. The default is no limit.
  • MAX#_CLIENTS
    The maximum number of clients allowed to share a single logical service concurrently. This parameter has no bearing on the number of clients that can serially reuse this service. As long as the service deallocates at its completion rather than terminates, the Spawn Manager continues to reallocate it to new or pending clients that spawn for it. The default is one client per service.
  • SELECTION
    When multiple instances of the service and its server are defined, this parameter designates the order that each instance of the service is selected:
    • FIRST
      All instances of the service with this attribute are selected prior to any instances with the BALANCED attribute. The first service with this attribute is repeatedly selected until a SPAWN request would be failed or queued because one of the maximum limits has been reached. At this point, the next service instance with the FIRST attribute is used. When there are no more FIRST services, services with the BALANCED attribute are selected.
    • BALANCED
      Instances of the service with this attribute are selected so that the client allocation is distributed evenly among them.
  • SCOPE
    Indicates the range of this service's availability:
    • LOCAL
      The service is only accessible to local clients (client applications running on the same system where this service is defined).
    • GLOBAL
      The service is accessible to all clients, both local and network; the default.
  • CLIENT
    Controls which clients a service is to be initially allocated or reallocated to:
    • SPEC
      An active and available service is only allocated to a client that specifically requests it by its unique RECEIVE ID (RID) in the SPAWN call, as well as by its generic SPAWN ID.
    • ANY
      An active and available service is allocated to any client requesting for it by its generic SPAWN ID; the RID on the SPAWN call, if coded, is ignored. This option is the default.
  • SERVER_UNAVAILABLE
    Dictates the action of the Spawn Manager when a client has spawned for a service whose server is not active. (The server may be defined to have a deferred start or started externally):
    • QUEUE_CLIENT
      The SPAWN request is queued awaiting the server.
    • FAIL
      The SPAWN request is failed; the default.
  • SERVICE_UNAVAILABLE
    Dictates the action of the Spawn Manager when a client has spawned for a service whose server is available but the service is not currently active or available for allocation (because one of the MAX# parameters has been exceeded):
    • START_SERVICE
      The Spawn Manager attempts to start a new service for the client. This typically results in the Spawn Manager directing the associated server to initiate a new physical process and assigning it exclusively to the client. If the Spawn Server is unable to start a process for the client (i.e., maximum number of processes has been reached), the SPAWN request is failed. This is the default.
    • START_SERVICE/QUEUE_CLIENT
      The Spawn Manager attempts to start a new service for the client. This typically results in the Spawn Manager directing the associated server to initiate a new physical process and assigning it exclusively to the client. If the Spawn Manager is unable to start a process for the client, the SPAWN request is queued until a process can be initiated.
    • WAIT
      The Spawn Manager determines if there is any active service currently allocated to another client that would satisfy the SPAWN request. If there is, the SPAWN request is queued for the service, pending its availability. Otherwise, the Spawn Manager attempts to start a new service for the client. This typically results in the Spawn Manager directing the associated server to initiate a new physical process and assigning it exclusively to the client. If the Spawn Manager is unable to start a process for the client (i.e., the maximum number of processes has been reached), the SPAWN request is failed.
    • WAIT/QUEUE_CLIENT
      The Spawn Manager determines if there is any active service currently allocated to another client that would satisfy the SPAWN request. If there is, the SPAWN request is queued for the service, pending its availability. Otherwise, the Spawn Manager attempts to start a new service for the client. This typically results in the Spawn Manager directing the associated server to initiate a new physical process and assigning it exclusively to the client. If the Spawn Manager is unable to start a process for the client, the SPAWN request is queued until a process can be initiated.
    • FAIL
      The SPAWN request is failed.
  • START
    Indicates whether the process for the service can be started outside of the SPAWN facility or if it must always be initiated by the Spawn Manager.
    • SPAWN_ONLY
      The process for the service must be initiated by the Spawn Manager. If an external process issues the #CCI SERVICE API call to create a service, the API call is failed.
    • EXTERNAL_PERMITTED
      A process started outside of the SPAWN facility is permitted to issue the #CCI SERVICE API call to create a logical service which can be allocated to pending or future client applications. This is the default.
  • DEALLOCATE
    Specifies the disposition of a service when it is deallocated by the SERVICE and CANCELS API calls or when deallocation is invoked by the LOST_CLIENT option.
    • AVAILABLE
      The service is available for reallocation to another client spawning for it.
    • UNAVAILABLE
      The service will not be reallocated. If no other client is using the service, it is terminated. If there is an outstanding #CCI SERVICE call, its feedback area is posted with a return code indicating that the service has been discontinued.
    • TERMINATE
      This option functions the same as UNAVAILABLE. In addition, if the process was spawned and if no other logical services exist for it, the process is also terminated. This is the default.
  • LOST_CLIENT
    Specifies the disposition of a service when its client application terminates first.
    • HOLD
      The service is held for reconnection by the recovering client. The client must issue the #CCI SPAWN API call with the SPAWN KEY that was returned when the service was originally spawned.
    • DEALLOCATE
      The service is deallocated as per its DEALLOCATE option; the default.
  • SIGNON
    Indicates that a valid user signon will be required in order for the spawned application to execute. The User ID and Password must be specified on the #CCI Spawn macro call.
    • SERVICE
      Indicates that the spawned Service will do the signon as it initiates. (A RACROUTE REQUEST=VERIFY is called by the #CCI INIT of the spawned application). A successful signon will switch the security environment to run under the scope defined for the User ID.
      If the signon fails, the service is immediately terminated; the specific security error is returned in the feedback area of the Spawn macro call.
  • SIGNON/NOPASSCHK
    Indicates that a valid User ID will be required in order for the spawned application to execute, however the password will not be checked. The User ID must be specified on the #CCI Spawn macro call.
    • SERVICE
      Indicates that the spawned Service will do the signon as it initiates. (A RACROUTE REQUEST=VERIFY is called by the #CCI INIT of the spawned application). A successful signon will switch the security environment to run under the scope defined for the User ID.
      If the signon fails, the service is immediately terminated; the specific security error is returned in the feedback area of the Spawn macro call.