Managing the OSC System

This chapter covers the OSC startup and shut down processes. It also describes the functions provided for managing and modifying the OSC system while it is running.

1. Startup and Shutdown of the OSC System

The oscboot and oscdown tools can be used to boot up and shut down the entire OSC system or specific regions.

  1. If you want to start up or shut down a specific server instead of the entire OSC system, use the Tmax tools tmboot or tmdown.

  2. TCache needs to be initialized by using the pfmtcacheadmin tool before starting a region.

1.1. Starting the OSC System

The following describes the process for starting OSC.

  1. Starting the OpenFrame system servers

    If the ofsys.seq file exists in the ${OPENFRAME_HOME}/config directory, oscboot starts the servers listed there in the order in which they appear. This "sequential start" function prevents common errors from occurring during the startup process, such as one server trying to call a service from another server that hasn’t yet been started. During the installation of OSC, ofsys. seq is given a default configuration.

    Internally, oscboot first executes any tasks registered in oscboot.pre, then sequentially start up the OpenFrame system servers, and finally execute any tasks registered in oscboot.post.

  2. Starting the OSC system servers

    After the previous process is complete, oscboot starts the OSC system servers internally specified in an engine.

  3. Starting the OSC user servers

    After the previous process is complete, oscboot starts the OSC user servers specified in ofosc.seq.

  4. Starting the OSC regions

    After the previous process is complete, OSC regions specified in osc.region.list are started one by one. The resources for each region are prepared, and then the servers included in OSC regions are started.

    The process for preparing the resources needed to start the OSC regions is as follows:

    1. A system memory area to be used by OSC regions is allocated in the shared memory.

    2. A user memory area to be used by OSC regions is allocated in the shared memory.

    3. A TSQ area to be used by OSC regions is allocated in the shared memory.

    4. A directory is created for the task control function.

    5. The intra-partition TDQ data set is initialized.

    6. Create RTSD and system tables.

    After the process of resource preparation is complete, application and auxiliary servers included in the OSC regions are started. When each OSC region is started, programs listed in the PLPTI are sequentially executed regardless of the PROGRAM=DFHDELIM item in the DFHPLT macro. Transactions requested by an EXEC CICS START command from a PLT program will be run after all PLPTI programs finish executing. After these transactions are completed, the OSC startup process is finished.

    1. The oscboot tool allows individual regions to be started by using the [-r] option. The [-s] option allows servers to be started without allocating resources that are used by the regions.

    2. The DFHPLT macro is compiled and deployed through the oscpltc tool. For more information about the oscpltc tool, refer to OpenFrame Tool Reference Guide.

    3. For more information about the FHPLT macro, refer to OpenFrame OSC Resource Definition Guide.

1.2. Shutting down the OSC System

The following describes the process for shutting down OSC.

  1. Shutting down the OSC regions

    oscdown sequentially shuts down OSC regions in osc.region.list in the $OPENFRAME_HOME/config directory. When each OSC region is shut down, the pre-shutdown programs registered in PLTSD are executed. During the OSC shutdown process, load the PLT and execute the programs specified in the PLT after referring to the osc.{servername} subject in the OpenFrame environment setting and the VALUE item of the PSTSD key in the GENERAL section.

    The execution of programs listed in PLTSD is divided into two steps:

    1. Programs specified in the DFHPLT macro are executed until the PROGRAM=DFHDELIM line is reached. In this step, the OSC application server accepts and processes only when a transaction specified in the SHUTDOWN(ENABLED) item in the TRANSACTION resource definition is requested or a transaction set in the DFHXLT macro, specified in the VALUE entry of the osc.{servername} subject and the XLT key in the GENERAL section in the OpenFrame configuration, is requested from the terminal.

    2. Once all user transactions are finished, any programs after the PROGRAM=DFHDELIM item will be executed. After this, OSC will not accept any new user transaction requests.

      1. The DFHXLT macro is compiled and deployed by using the oscxltc tool. For more information about oscxltc, refer to OpenFrame Tool Reference Guide.

      2. For more details on the DFHPLT and DFHXLT macros, refer to OpenFrame OSC Resource Definition Guide.

      After the previous process is complete, application and auxiliary servers included in the OSC regions are shut down. Resources used by the OSC regions are deleted in the following order:

      1. The TSQ area allocated for OSC regions is deleted.

      2. The user memory area allocated for OSC regions is deleted.

      3. The system memory area allocated for OSC regions is deleted.

      4. The directory created for task control is deleted.

      5. Delete RTSD and system tables.

  2. Shutting down the OSC user servers

    oscdown shuts down all servers in ofosc.seq in the $OPENFRAME_HOME/config directory in the reverse order that they were booted.

  3. Shutting down the OSC system servers

    oscdown shuts down OSC system servers internally specified in an engine in the reverse order that they were booted.

  4. Shutting down the OpenFrame system servers

    If the ofsys.seq file exists in the $OPENFRAME_HOME/config directory, oscdown will shut down the servers listed there in the opposite order in which they appear (the opposite order in which they were booted). This keeps servers from requesting services from servers that have already been shut down.

    After the previous process is complete, the oscdown tool first executes any tasks specified in oscdown.pre and then shuts down the system servers. After shutting down the system servers, it executes any tasks specified in oscdown.post. oscdown.pre and oscdown.post files must be located in the ${OPENFRAME_HOME}/bin directory.

    Shutting down the servers using the [-i] option in the oscdown tool skips resource cleanup in the OSC regions. Therefore, it is recommended to use the method sparingly. If the method is used, start the OSC Regions using the [-m] option in the oscboot tool.

2. Managing the OSC System

Management of the OSC system can be divided into two categories: system-level management and region-level management.

System-level management includes system log lookup and system resource lookup and management. Region-level management includes both general regional resources such as region status, OSC SD tables, and the RTSD and specific regional resources such as transactions, terminals, and maps.

It is recommended that the administrator manage the system and regions separately.

2.1. System-level Management

A number of functions are provided to help manage the OSC system and its regions. These functions manage:

  • RESP and RESP2 code lookup

  • System server and application server log lookup

  • System resource lookup and management for named counters, scheduled transactions, and terminals

System-level management functions can be found through the [OSC] menu in OpenFrame Manager.

RESP code lookup can also be managed with the oscresp tool, and terminal connection information lookup and management can also be managed with the oscadmin tool.

For more information about OpenFrame Manager system management, refer to OpenFrame Manager User Guide.

2.2. Region-level Management

A number of functions are provided to help manage regions in the OSC system, including region status view, OSC SD and RTSD management, EDF and so on. Also, each resource used in a region can be individually managed.

The items of region-level management are as follows.

  • General region information lookup

    Provides general information about regions. You can view any region’s general basic information (APPLID, JOBID, SYSID and others) as well as system memory usage, spool usage and server logs. This feature can be used through the [OSC] > [Regions] menus in OpenFrame Manager.

  • Region status view

    Provides information about processes of active regions. The administrator can check the PIDs of active server processes, the SPRI managed by Tmax, transaction-related information, and the user application’s use of the EDF feature in debugging - all in real-time. In addition, if a server process stops working because of system or application errors, the process can be terminated, its queued jobs stopped, and a new process started. However, since terminating processes can cause resources to become corrupted, this function must be used with particular care. This function can be found through [OSC] > [Regions] of OpenFrame Manager.

  • OSC SD data set management

    Views/adds/modifies/deletes resource definitions for a more efficient management of OSC SD tables. With the oscsdgen tool, you can add resource definitions into the OSC SD table by using the tool as well as modify or delete the defined resources. You can also view the defined resources by using the oscsddump tool. These functions are found through the [OSC] > [Regions] > [System Definitions] menus in OpenFrame Manager.

  • OSC RTSD table management

    Manages the OSC system in real-time through the following three methods.

    • Method 1)

      You can view and modify resource definitions loaded in the database tables through [OSC] > [Regions] > [Runtime Resources] menus in OpenFrame Manager. However, deleted resources can no longer be accessed from application servers.

    • Method 2)

      You can view, add and modify resource definitions loaded in the database tables by using the RTSD tool provided by OSC. However, deleting resource definitions is not supported. There are two types of RTSD tool: oscrtsdupdate and oscrtsddump. oscrtsdupdate updates information about currently running application servers, and oscrtsddump creates RTSD information as a macro format text file.

    • Method 3)

      You can create an OSC application for management by using the system programming interface.

      In the case of runtime resource, modifiable resources are limited. Therefore, you must first check the list of modifiable resources before making any modifications.

The specific region resources that can be managed are as follows:

Item Description

Transaction

Information about transactions such as a region where a transaction is executed, a terminal that requests a transaction, a program name for a transaction, and transaction starting time. The transaction resource lookup function is found through the [OSC] > [Regions] > [Transaction Status] menus in OpenFrame Manager.

Storage

Information about the allocated storage area and processes that use GETMAIN are displayed with this function. The storage area lookup function is found through the [OSC] > [Regions] > [Storage] menus in OpenFrame Manager.

Terminal

A searchable list of terminals that are connected to applications, as well as their NETNAMEs and gateway numbers, are displayed with this function. This information can be managed by the administrator while the system is running. The terminal lookup function is found through the [OSC] > [Terminals] menus in OpenFrame Manager.

TDQ / TSQ

Searchable TDQ and TSQ lists used by application servers, as well as the contents of the TSQ list, are displayed with this function. Additionally, the contents of TDQ can be moved to TSQ, and the contents of TSQ can be copied to TDQ. The TDQ and TSQ management function is found through the [OSC] > [Regions] > [Queues] menus in OpenFrame Manager.

For more information about how to use the [OSC] menu in OpenFrame Manager, refer to OpenFrame Manager User Guide.

2.3. Log-level Management

The OSC system log level can be divided into two levels: OSC system and user server log level and each region log level.

The OSC system and user server log level is managed by configuring the VALUE of the SYSTEM_LOGLVL key, in the GENERAL section from the osc subject under OpenFrame Configuration. During startup of each server, the respective values are read and applied. The OSC system allows the user to view and modify each region’s log level by using the oscadmin tool, and such modified values are applied to each region in real time, unlike the server log level.

There are three log levels. Descriptions for each are as follows:

Level Description

E (Error) level

Logs error events.

I (Information) level

Logs details about error events. You can get more information, but the log file may be larger. This is the default log level in the OSC system.

D (Debug) level

Logs more details about error events, including which components were running and which of their tasks were affected when an error occurred. The log may be significantly larger than those recorded in the I level.

  1. For more information about how to configure the osc subject, refer to OpenFrame Configuration Guide.

  2. For more information about the oscadmin tool, refer to OpenFrame Tool Reference Guide.

The following example views the log level set for OSC00001 Region.

oscadmin -l OSC00001

The following example assigns the debug level to the logger for OSC00001 Region.

oscadmin -l OSC00001:D

3. Security Management

Security management for the OSC system is based on TACF(Tmax Access Control Facility). Providing an authentication process for users who want to access the OpenFrame system, TACF protects the system and prevents unauthorized users from accessing resources in the system.

TACF allows different security management settings for each application server. This can be set up in the SAF section of the osc.{servername} subject, under OpenFrame Configuration. The administrator can specify whether to use the same security settings for the entire system or to use different security settings for each resource.

For more information about security configuration for region servers, refer to OpenFrame Configuration Guide.

3.1. User Security

Access to an OSC region is controlled through TACF user registration. This user registration process lets administrators assign users to security groups and then provides a sign-in process for users to access transactions and resources.

The following example adds the CICSGRP group and then registers the default user CICSUSER of the OSC application to the CICSGRP group through TACF.

ADDGROUP CICSGRP
ADDUSER CICSUSER DFLTGRP(CICSGRP) NOPASSWORD

To get permission to access transactions and resources, the user must go through a sign-in process after connecting to a terminal. After the user finishes using the OSC system, he or she can securely sign out through CESN in order to prevent unauthorized access. The user can go through the same authentication process directly by using the SIGNON and SIGNOFF commands in application programs. If the application server does not pass through any additional authentication process, it operates with the default user permissions.

The following is an example of the basic transaction CESN screen. Users can sign in to the OSC system here.

figure 5 1
Default Transaction CESN Screen

  1. For more information about user registration, refer to OpenFrame TACF Administrator’s Guide.

  2. For more information about user authentication commands, refer to OpenFrame OSC Developer’s Guide.

3.2. Resource Security

OSC regions provide security functions for resource requests by the users. When a request for an individual resource is made, the user’s authorization is checked before the user is allowed to access the resource.

OSC provides security services for the following resources:

  • Transaction

  • TDQ (Transient Data Queue)

  • File

  • Started Transaction

  • Program

  • TSQ (Temporary Storage Queue)

Security can be applied at the resource level by using the default member resource class. To apply security at the resource group level, use the default group resource class. The default resource classes used by TACF for individual resource security are as follows:

Default Class Target Type

TCICSTRN

Transaction

Member

GCICSTRN

Transaction group

Group

DCICSDCT

TDQ

Member

ECICSDCT

TDQ group

Group

FCICSFCT

File

Member

HCICSFCT

File group

Group

ACICSPCT

Started transaction

Member

BCICSPCT

Started transaction group

Group

MCICSPPT

Program

Member

NCICSPCT

Program group

Group

SCICSTST

TSQ

Member

UCICSTST

TSQ group

Group

To use security for each resource, the following steps must be followed.

  1. Register the resource to which the security rule is applied to the default member resource class of TACF. Or the resource group profile in which the resource is registered as a member is registered in the default group class.

  2. Register users and authorities to the resource’s access list.

  3. Set the osc.{servername} subject, the SEC key of the SAF section, and the VALUE of each resource security key to YES in the OpenFrame configuration.

The following example registers the OIVP transaction to TCICSTRN and GCICSTRN, and grants the READ authority to CICSUSER. Use TCICSTRN to apply security at the transaction unit level, and GCICSTRN to apply security at the transaction group unit level.

RDEFINE TCICSTRN OIVP UACC(NONE)
PERMIT OIVP CLASS(TCICSTRN) ID(CICSUSER) ACCESS(READ)
RDEFINE GCICSTRN OIVPGRP UACC(NONE) ADDMEM(OIVP, OIBR, …)
PERMIT OIVPGRP CLASS(GCICSTRN) ID(CICSUSER) ACCESS(READ)

The following example registers OIVPFILE to FCICSFCT and HCICSFCT, and grants the UPDATE authority to CICSUSER. Use FCICSFCT to apply security at the resource unit level, and HCICSFCT to apply security at the resource group unit level.

RDEFINE FCICSFCT OIVPFILE UACC(NONE)
PERMIT OIVPFILE CLASS(FCICSFCT) ID(CICSUSER) ACCESS(UPDATE)
RDEFINE HCICSFCT OIVPGRP UACC(NONE) ADDMEM(OIVPFILE)
PERMIT OIVPGRP CLASS(HCICSFCT) ID(CICSUSER) ACCESS(UPDATE)

The OSC system provides the security service for TDQ, TSQ, program, and transactions that have been started, through the same steps.

  1. For more information about user registration, refer to OpenFrame TACF Administrator’s Guide.

  2. For more information about individual resource, refer to OpenFrame OSC Resource Definition Guide.

4. Log Information

There are several logs that each record information about Tmax processes, OSC application and system servers, services executed in OSC application servers, and OSC system command operations.

4.1. Tmax Logs

Tmax logs are stored in a directory that is determined by the SLOGDIR and TLOGDIR environment variables in the Tmax configuration file. The file where Tmax system messages are stored will be created in the directory specified in SLOGDIR. The file for storing transaction-related messages triggered by XA will be created in the directory specified in TLOGDIR.

4.2. Server Logs

OUT logs and ERR logs record information from OSC application and system server processes. Both logs are stored in the directory specified in the ULOGDIR environment variable in the Tmax configuration file. Although any location can be specified for the directory, it is recommended to put it under the ${OPENFRAME_HOME}/log directory.

OUT logs

The file where the OUT logs will be stored is defined by the [-o] option in the CLOPT section. All log messages sent by OSC application and system server processes using STDOUT will be stored in this file. For OSC system servers, the VALUE of the SYSTEM_LOGLVL key in the GENERAL section, from the osc subject under OpenFrame Configuration is used. For OSC application servers and auxiliary servers, the logs are recorded to the file depending on the log level of the individual OSC region.

  • Format

    The format of the OUT log is as follows:

    Time  LogLevel  MessageCode  [10:ModuleName:SPRI:PID]  Log
    Item Description

    Time

    HHMMSS type (except date) of timestamp.

    LogLevel

    One of the following.

    • E (Error): Indicates a system error that has occurred as a result of an incorrect input or internal system error.

    • I (Information): Indicates a message containing general information for the user. This can contain a variety of server process information.

    • D (Debug): Indicates that the message is for debugging.

    • T(Test): A detailed debugging log will be displayed if there is input or output data.

    MessageCode

    A unique code number for a log message.

    [10:ModuleName:SPRI:PID]

    • 10: The OSC product number.

    • Module Name: A module name of the OSC system which prints messages.

    • SPRI: An application server’s Tmax SPRI value.

    • PID: An application server’s process ID.

    Log

    A log message.

  • Example

    The following example is an OUT log for the OSC00001 application server.

    172703 I OSC0011I [10:CICSRES:59:19582] OSC00001 server boots
- resource manager initialization completed
172703 I OSC1705I [10:DFHSIPLT:57:19584] PLTPI : PLT suffix(I1)
173905 E OSC2010E [10:CICS:57:21240] : cics command error - EIBRESP =
0x0000001b(PGMIDERR),
EIBRESP2 = 0x00000001, EIBFN = 0x0e0e(HANDLE ABEND), VALFLAG = 0x18000001,
FLAG = 0x20000000

For more information about how to configure the osc subject, refer to OpenFrame Configuration Guide.
ERR logs

The file for storing the ERR logs is defined with the [-e] option in the CLOPT section. All logs for OSC applications and other OpenFrame modules that are displayed through STDERR are recorded in this log file.

4.3. Service Logs

When terminating the transaction on the transaction server, store the log directly in the log table (OFM_OSC_OLOG). Users can query statistical information about transactions by using osclogrpt tool or through OpenFrame Manager.

The items managed by the log table are as follows.

Item Description

REGION_NAME

Region name.

DATE

Transaction date.

TIME

Time when the transaction was executed.

NODE_NAME

Node name. ALL: all nodes.

SYSID

Region SYSID.

TCL

Name of the class that performed the transaction.

SPRI

Tmax Server ID.

PID

Server PID.

TRANS_ID

Transaction name.

SVC_TIME

Transaction execution time.

CPU_TIME

CPU execution time.

USER_ID

User ID.

IP_ADDR

Terminal IP address.

NETNAME

Terminal NETNAME.

SYS_ERR

System error code, if any.

USER_RET

User error code, if any.

4.4. Command Logs

Command logs are recorded in the osc_cmd_{YYYYMMDD}.log file under the ${OPENFRAME_HOME}/log/cmd directory. The command logs contain the results of OSC system commands, such as startup and shutdown, and TDL memory modification.

  • Format

    The following is the format of the command log. LogLevel is S when the OSC system command is successfully executed or E if an error has occurred. Time, ModuleName, and LogMessage are the same as the "OUT logs".

    Time  LogLevel  ModuleName  LogMessage
    Item Description

    LogLevel

    One of the following.

    • S (Success): Indicates that the OSC system command executed successfully.

    • E (Error): Indicates that the OSC system command failed.

  • Example

    The following is an example of command logs.

    135017 S OSCBOOT OSC system servers boot start
135017 S OSCBOOT OSC system servers boot successfully
135017 S OSCBOOT OSC region(OSC00001) boot start
135029 S OSCBOOT OSC region(OSC00001) PLTPI ok
135029 S OSCBOOT OSC region(OSC00001) boot ok
135035 S OSCTDLUPDATE OSC region(OSC00001) module(PGM00001) tdlupdate ok
135041 S OSCDOWN OSC region(OSC00001) shutdown start
135101 S OSCDOWN OSC region(OSC00001) PLTSD(suffix:) ok
135102 S OSCDOWN OSC region(OSC00001) shutdown ok
135102 S OSCDOWN OSC system servers shutdown start
135102 S OSCDOWN OSC system servers shutdown successfully

4.5. Monitoring Logs

Monitoring logs are automatically be created in the SMF data set of the account that the OSC monitoring server is running on. When a transaction is executed, system and resource information related to it are recorded in this log. To create a monitoring log, an environment for the SMF function and a necessary data set must be prepared in advance. If the SMF function is not set up, the monitoring log cannot be created, resulting in malfunction.

The format of the monitoring logs varies according to the environment settings of the OSC monitoring server.

For more information about the type of data recorded in the SMF data set, refer to the CICS Monitoring section of IBM CICS Customization Guide.

5. Server Restoration

OSC system server processes and application server processes are sometimes forcibly terminated by the operating system, in order to handle internal errors or user programs' problems. Additionally, hardware problems may result in the shutdown of entire nodes at unexpected times. This can cause a shutdown of the node that the OSC system is running on, or may sever the links between application server processes and resource modules. Any of these cases may be cause for server restoration.

5.1. OSC System Server Restoration

When a problem occurs in a server process, the OSC system server will refer to the Tmax configuration file (especially the RESTART option) and then restart the terminated application server process, which will then resume processing transactions. Unless there is a problem in the internally-used server information structure, the new process will be restored to its previous state and continue providing services to OSC application servers. However, if OSCDFSVR is restarted, all existing connection information will be reinitialized.

In a multi-node environment, if an error occurs in active nodes used by system servers like OSCNCSVR, OSCSCSVR, and OSCDFSVR, new server processes will restart in different nodes.

The following servers react differently when an error occurs.

Server Description

OSCNCSVR

Even if the server restarts in a different node, consistent service can be provided if the NCS_FILE set in the GENERAL section of the osc subject, under OpenFrame Configuration, points to the previously used file on the shared disk.

OSCSCSVR

If BACKUP settings are enabled, any queued requests are processed; if BACKUP settings are not enabled, only new requests are processed.

OSCDFSVR

Any existing EDF function is processed as an error, and the EDF feature must be restarted.

For more information about how to configure the osc subject, refer to OpenFrame Configuration Guide.

5.2. OSC Application Server and Auxiliary Server Restoration

When server processes are terminated because of unexpected errors, their OSC application server can recover them at the application level. When a problem occurs, current transactions are abnormally terminated and all resources that can be recovered will be rolled back. The application server will then refer to the Tmax configuration file (specifically, the RESTART option) and, either automatically or manually, start new server processes that will resume processing transactions. In situations where an entire node is terminated, the Tmax engine itself will handle the recovery.

During startup, the OSC application server processes connect to the Tibero server (or other database product) to access the TSAM data set. However, in situations where this connection may be severed because of a network error or other problems, requests to access the TSAM data set, auxiliary TSQ, or intra-partition TDQ will return error results. This will result in TSAM data set access requests being rolled back. Transactions requested by application server processes will remain in a pending state until a new connection is established. If no new connection is established in the timeout period, an error will be sent and the transaction terminated when the next TSAM connection is required.

A working database connection is also required to use TACF. This connection may fail because of network or other errors. In this situation, requests made to TACF will produce errors. These errors will then be returned to the application server process. The next time a TACF request is made, the system will attempt to recover the connection.

OSC application server processes use TCP/IP socket communication to exchange data with the OSC TDQ Log server (an auxiliary server). This connection can also fail in the event of network error. If the connection is lost, access to log-type TDQ resources will be lost. This will result in the system attempting to reconnect and recover the connection when the next user request is sent.

For more information about resource usage, refer to OpenFrame OSC Developer’s Guide.

6. Time Change

OSC system server’s date and time are set to those of a currently running system server by default. The date and time can be obtained by using the CICS ASKTIME command. If you need to test the OSC system or specific user programs at a specific time, use the TX_TIME function supported by OSC. With the function, you can set desired date and time for the OSC system, a specific region, or a specific user program.

For more information about how to configure TX_TIME, refer to "Chapter 4. OSC" in OpenFrame Manager User Guide.

6.1. Pre-change Tasks

Perform the following preparatory tasks to use TX_TIME.

  1. Checking a database table

    Check the OFM_OSC_TX_TIME system table, created by the oscinit tool during OSC installation.

  2. Setting OSC

    Set the VALUE of the ENABLE_TX_TIME key to YES, in the GENERAL section of the osc subject, under OpenFrame Configuration.

    For more information about how to configure the osc subject, refer to OpenFrame Configuration Guide.

  3. Setting TCache

    Set the following in the pfmtcache.cfg file, which is created by default during OSC installation.

    # cache for OFM_OSC_TX_TIME
CACHE_NAME=OFM_OSC_TX_TIME
SIZE_MEM=32         # the total cache memory size in kilo-bytes
SIZE_HASH=32        # the number of hash key (MAX=65536)
SIZE_KEY=14         # the number of digits of the index column
SIZE_REC=38         # the size of a single record in bytes
INV_TIMEOUT=10      # invalidation timeout in sec

6.2. Setting Time

TX_TIME sets OSC system time by using data stored in a database table.

The following describes the database table data.

Item Description

CONTROL_TYPE

One of the following KEY_ID types for which user-specified date and time are set.

  • Transaction (TX)

  • Terminal (TM)

  • User (UR)

  • Region (RG)

The priority order is as follows: Transaction > Terminal > User > Region.

KEY_ID

ID of the Item for which user-specified date and time are set. One asterisk ('*') can be included to specify the ID range.

USER_DATE

User-specified date in the format of 'YYYYMMDD'.

TIME_TYPE

One of the following user-specified time type.

  • Absolute time (A): Fixes to user-specified time.

  • Subtraction time (M): Subtracts user-specified time from system time.

  • Addition time (P): Adds user-specified time to system time.

USER_TIME

User-specified time in the format of 'hhmmss'.

LAST_REG_USER

Name of a user who has last saved data.

LAST_REG_TIME

Last save time in the format of 'YYYYMMDD hhmmss'.

LAST_UPDT_USER

Name of a user who has last modified data.

LAST_UPDT_TIME

Last modification time in the format of 'YYYYMMDD hhmmss'.

6.3. Changing Time

The following are the methods for changing date and time of data existing in the TX_TIME table.

  1. Initializing TCache

    Initialize the existing data in TCache to load new date and time, by using the pfmtcacheadmin tool (TCache administrator tool) or by deleting the existing time information by changing the time through OpenFrame Manager.

    The following example uses the pfmtcacheadmin tool to initialize the existing data associated with TX_TIME loaded in TCache.

    pfmtcacheadmin -i OFM_OSC_TX_TIME

  2. Updating date and time

    Modify the date and time of the existing data in the TX_TIME table, by using the TX-TIME function of OpenFrame Manager.

    In 32-bit environments, which are affected by the 2038 problem, do not use any time beyond the year of 2038. If you go beyond the January 19th of 2038, the time returns to the 1st January of 1970.

7. Automatic Resource Installation

To operate the OSC system server, the required resources must be defined in the System Definition. However, certain resources can be automatically installed as needed without being defined in the System Definition. If the user define a resource model to be installed automatically in the System Definition, the automatic resource installer (AutoInstall) can create a resource based on the predefined model whenever there is a request for a resource that is not defined in the System Definition.

7.1. Automatic Program Installation

The following are preparatory tasks for automatic installation of a program.

  1. Configuration

    Set the name of an automatic installation control program to the VALUE of the PGAIEXIT key in the AUTINST section, from the osc.{servername} subject under OpenFrame Configuration.

    For more information about how to configure the osc.{servername} subject, refer to OpenFrame Configuration Guide.

  2. Writing control program

    A control program defined in OSC Configuration is invoked internally in the OSC system when the user runs a program that is not defined in the System Definition.

    The control program returns the name of a program resource model corresponding to the input name of a program to be installed, according to the user-specified logic. As the result, a new program resource having the same attributes as the resource model defined in OSC is created and executed.

    The following example writes a control program that returns the program resource model name 'MODELPGM' after receiving the input program name 'TARGETPGM'.

            IDENTIFICATION DIVISION.
        PROGRAM-ID. OSCPGACC.
        ENVIRONMENT DIVISION.
        DATA DIVISION.
        WORKING-STORAGE SECTION.

      * Commarea constants
        01 PGAC-CONSTANTS.
      * Module type
         03 PGAC-TYPE-PROGRAM      PIC X VALUE '1'.
         03 PGAC-TYPE-MAPSET       PIC X VALUE '2'.
         03 PGAC-TYPE-PARTITIONSET PIC X VALUE '3'.
      * Language
         03 PGAC-ASSEMBLER         PIC X VALUE '1'.
         03 PGAC-COBOL             PIC X VALUE '2'.
         03 PGAC-PLI               PIC X VALUE '3'.
         03 PGAC-C370              PIC X VALUE '4'.
         03 PGAC-LE370             PIC X VALUE '5'.
      * CEDF status
         03 PGAC-CEDF-YES          PIC X VALUE '1'.
         03 PGAC-CEDF-NO           PIC X VALUE '2'.
      * Data location
         03 PGAC-LOCATION-BELOW    PIC X VALUE '1'.
         03 PGAC-LOCATION-ANY      PIC X VALUE '2'.
      * Execution key
         03 PGAC-CICS-KEY          PIC X VALUE '1'.
         03 PGAC-USER-KEY          PIC X VALUE '2'.
      * Load attribute
         03 PGAC-RELOAD            PIC X VALUE '1'.
         03 PGAC-RESIDENT          PIC X VALUE '2'.
         03 PGAC-TRANSIENT         PIC X VALUE '3'.
         03 PGAC-REUSABLE          PIC X VALUE '4'.
      * Share status
         03 PGAC-LPA-YES           PIC X VALUE '1'.
         03 PGAC-LPA-NO            PIC X VALUE '2'.
      * Execution set
         03 PGAC-DPLSUBSET         PIC X VALUE '1'.
         03 PGAC-FULLAPI           PIC X VALUE '2'.
      * Dynamic status
         03 PGAC-DYNAMIC-YES       PIC X VALUE '1'.
         03 PGAC-DYNAMIC-NO        PIC X VALUE '2'.
      * Concurrency
         03 PGAC-QUASIRENT         PIC X VALUE '1'.
         03 PGAC-THREADSAFE        PIC X VALUE '2'.
         03 PGAC-REQUIRED          PIC X VALUE '3'.
      * Api
         03 PGAC-CICSAPI           PIC X VALUE '1'.
         03 PGAC-OPENAPI           PIC X VALUE '2'.
      * JVM
         03 PGAC-JVM-YES           PIC X VALUE '1'.
         03 PGAC-JVM-NO            PIC X VALUE '2'.
      * Return code
         03 PGAC-RETURN-OK         PIC X VALUE '1'.
         03 PGAC-RETURN-DONT-DEFINE-PROG PIC X VALUE '2'.

        LINKAGE SECTION.
      * Include Program Autoinstall commarea
        01 DFHCOMMAREA.
           COPY DFHPGACO.

        PROCEDURE DIVISION.
               IF  PGAC-MODULE-TYPE = PGAC-TYPE-PROGRAM
                   IF PGAC-PROGRAM = 'TARGETPGM'
                       MOVE 'MODELPGM' TO PGAC-MODEL-NAME
                   END-IF
               END-IF.
               MOVE PGAC-RETURN-OK TO PGAC-RETURN-CODE.
               EXEC CICS RETURN END-EXEC.

  3. Defining program model

    Define an automatic installation program model in the System Definition, in the same way as defining normal program resources. When a program is installed automatically, the attributes of the model defined in this step are used.