Overview

This chapter introduces OpenFrame/OSC, one of the OpenFrame system modules, and describes its features and structure.

1. Introduction to OpenFrame/OSC

The OpenFrame/OSC (hereafter OSC) module provides a suitable open system environment for the migration and operation of mainframe CICS and IMS applications.

The following issues must be considered when migrating a mainframe legacy system to a more cost-effective and flexible open system environment.

  • Does the new system provide the same or higher levels of performance and stability compared to the mainframe?

  • Is the migration of system resources relatively easy?

OSC provides the same functions that CICS (IBM CICS Transaction Server) does and is built around TmaxSoft’s market-verified TP monitor, Tmax. This allows OSC to ensure high performance and reliability.

Having Tmax as a base allows OSC to access many of its features including:

  • Convenient process management

    In OSC, the Tmax engine manages all processes from startup to shutdown. This means that the monitoring information provided by Tmax is always accessible and process management is greatly simplified.

  • Mass transaction support

    Tmax has been recognized for its stability in handling mission critical tasks in open system environments. Its scheduling and queue management features allow it to handle high transaction volumes - even in very large databases.

  • Load balancing and failover features

    Servers in an open system environment are generally smaller and less powerful than mainframe machines. As a result, when a system is migrated from a mainframe environment to an open environment, two or more machines are networked together to make up for the difference in computing power.

    Where a single system is composed of two or more machines, load distribution and failover between the machines become major issues. These are handled by the Tmax engine, which provides load balancing and failover functions at a hardware level.

  • Flexible integration features

    Inter- and intra-system integration must also be considered in an open system environment, especially if the system will frequently grow or must regularly communicate with other systems. In these cases, OpenFrame/OSC is the optimal rehosting solution, because Tmax is capable of fully integrating with other commercial TP monitors that comply with X/Open DTP models, such as Tuxedo. Additionally, OSC can be seamlessly integrated with JEUS, TmaxSoft WAS (Web Application Server) solution. This enables complete web integration and facilitates the provision of services via the web.

OSC can be used to migrate mainframe applications into an open environment without any modification of the original business logic or code. Tools provided with OSC allow it to support "EXEC CICS" and "EXEC DLI" statements in COBOL applications, as well as the "CBLTDLI" function.

Some other features of OpenFrame/OSC are:

  • Efficient server process handling

    • Multiple, identical server processes can be active simultaneously in a system. When many transaction requests for the same server type are received, they are routed to whichever server process is most capable of efficiently processing the request.

    • Distributed processing can be optimized according to load by controlling the number of active server processes.

  • Parallel transaction processing

    • Dynamic control of configuration files, as well as the information managed by OSD (Online System Definitions) and RTSD (Run-Time System Definitions), ensures that multiple server processes can all access the same system resources.

    • OSC regions, consisting of one or more application servers and auxiliary servers, work the same way as CICS regions. Clearly defined regions allow multiple server processes running on the same server to use the same configuration settings and resource definitions.

  • Support for CICS programs without code modification

    • The OSC module incorporates a variety of tools, utilities, and components that work together to emulate resources provided by CICS.

    • Since these resources can be migrated without modification, user-created CICS application programs can also be used in the open system environment after a simple migration.

      The list of services provided by OSC includes:

      • Abend support

      • Authentication/Authorization through TACF

      • Channel command

      • Environment services

      • Exception support

      • File control through TSAM

      • Interval control

      • Journaling

      • Mapping Support

      • Named counter server

      • Program control

      • Security

      • Spool interface through TJES

      • Syncpoint

      • Storage Control

      • Task control

      • Temporary storage control

      • Terminal control

      • Transient data control

  • Tools and utilities for convenient system management

    • OpenFrame can be integrated with TmaxSoft SysMaster software to provide transaction tracing and monitoring information about the status of active server processes, the number of services processed, and the execution duration of service processes.

    • tmadmin programs, which are utilities for managing Tmax, can be used together.

      tmadmin is an Tmax TP monitor utility.

  • User convenient GUI via the [OSC] menu in OpenFrame Manager

    • OSC provides a unified environment for querying OSC system logs and for creating, querying, or editing service resource definitions.

    • OSC allows administrators to access dynamic system status information, such as the status of OSC server processes, server process information and terminal information.

    • OSC emulates mainframe CICS supplied transactions through the GUI environment.

2. OSC System Structure

The OSC module is made up of OSC system servers, which take care of system administration, and OSC application servers, auxiliary servers, and OpenFrame GW, the main components of OSC regions. The following is a diagram showing the structure of the OSC module.

figure 1 1
OSC System Structure

2.1. OSC System Servers

OSC provides the following system servers:

System Server Description

OSCMGR

Serves as the administrator for an entire OSC system. It provides SPI and TX_TIME configuration functions, and can start and shut down regions.

OSCSCSVR

Schedules transactions that run according to specified internal time conditions and communicates with application servers through the Tmax engine.

OSCDFSVR

Supervises the EDF functions of OSC application servers. It communicates with OSC application servers and OpenFrame Manager.

OSCMCSVR

Monitors OSC application servers.

OSCNCSVR

Manages named counters. It uses a UNIX file system and communicates with OSC application servers through the Tmax engine.

OSCJCSVR

Supports TYPE MVS of OSC JOURNALMODEL.

OSCMNSVR

Monitors OSC system server processes. The system operates normally even if server process monitoring is not set up.

2.2. OSC User Server

OSC provides the following user servers. To use the servers, users need to configure them.

System Server Description

OSCMQSVR

Provides the queue trigger monitoring function for OSC transactions by integrating with IBM’s WebSphere MQ. If the function will not be used, this server does not need to be configured.

2.3. OSC Region

OSC Region is an independent entity that is equivalent to a CICS region. Each region provides user transaction services with their own settings and resource definitions. Each region has its own configuration file and uses its own OSC SD table for resource definitions. One region is composed at least one application server process and one or more auxiliary servers.

If multiple server processes are running on one OSC application server, the processes can provide the same or different transaction services simultaneously by dynamically loading copies of the same program. OSC application servers are capable of multi-tasking. Identical resource definitions must be used for multiple server processes to provide the same service. All processes refer to the same configuration and resource definitions. Because the system has dynamic copies of the engine and server configuration files when the system engine is started, all server processes can provide service based on the same settings, regardless of operation time. Sharing identical resource definitions is made possible through Run-Time System Definition (RTSD), which are resource definitions stored in a database table.

Auxiliary Servers

In addition to the application servers responsible for transaction services, OSC regions can contain one or more auxiliary servers to be in charge of handling specific tasks.

User Server Description

OSCTLSVR

Processes the log-type Transient Data Queue (TDQ). Internally, it uses the Unix file system and has an internal buffer to enhance performance. The server communicates with the OSC application server in the region using the TCP/IP protocol. If the application server will not use a log-type TDQ, this server does not need to be configured.

OSCOSSVR

Runs OpenFrame Manager. It must be set up if OpenFrame Manager will be used.
Resource Managers

To manage the resources offered by application servers, several resource managers are provided.

Resource managers can be divided according to function, as follows:

  • Service Resource Manager

    Manages various services of the OSC server.

    Resource Manager Description

    Program Control

    Manages program execution.

    Task Control

    Manages task-to-task connections.

    Interval Control

    Manages time-related tasks.

    Storage

    Manages dynamic memory allocation.

    TACF

    Manages security.

    TSQ

    Manages the temporary storage queue.

    TDQ

    Manages the data transmission queue.

    Journal Control

    Manages journals.

  • Data Resource Managers

    Manages the storage and querying of data.

    Resource Manager Description

    File Control

    Manages access to TSAM data sets.

    DL/I control

    Manages access to IMS/DB.

    NCS

    Manages access to the named counter server.

  • Data Communication Resource Managers

    Manages communication between terminals or other systems.

    Resource Manager Description

    Terminal

    Initiates and manages terminal connections.

    Mapping Support

    Manages mapping.

    Spool

    Functions as the TJES system interface.

Resource managers are made available in the form of shared libraries. When the application source for a new OSC application is being compiled to create a binary object, these resource managers will be linked to that binary. When an application server is created, the link is made automatically, without user input. Users can make use of linked resources in applications with the EXEC CICS or EXEC DLI commands.

For more information about each resource and resource manager, refer to OpenFrame OSC Developer’s Guide.

2.4. Connecting to OSC Regions

Connections to OSC regions can be made via the TN3270 and TN3270E emulators and EXCI client.

Type Description

TN3270 / TN3270E Emulators

This program emulates the IBM 3270 terminal in a Windows environment. It connects to OSC regions. Connections to OSC regions must go through the OSC 3270 gateway provided by the region. To connect to a particular OSC region, the LOGON APPLID (a region name) command is used.

EXCI Client

Connects to the OSC system from the OpenFrame/Batch program through the EXCI programming interface.

2.5. OpenFrame Gateway

Manages terminals that connect via a TN3270 / TN3270E emulator or WebBrowser, and requests transaction to OSC application servers.

For more information, refer to OpenFrame GW Administrator’s Guide.

3. OSC Startup and Shutdown

OSC startup and shutdown are divided into two steps: the startup and shutdown of the OpenFrame system servers, and the startup and shutdown of the OSC system servers and OSC regions. For more information about each step, refer to Startup and Shutdown of the OSC System.

3.1. Startup

During the OSC startup process, the OpenFrame system servers are booted first; the OSC system and user servers and OSC regions are booted next.

  1. OpenFrame system servers startup

    The OpenFrame system servers are started sequentially according to the ofsys.seq configuration file.

  2. OSC system and user servers startup

    The OSC system servers and user servers are started sequentially according to the ofosc.seq configuration file.

  3. OSC regions startup

    Resources such as the shared memory, directories and files are prepared. After that, the OSC regions are started. Any post-startup programs registered in the PLT (Program List Table) are executed. Once these initialization programs are executed, the OSC region startup process is finished.

3.2. Shutdown

During the OSC shutdown process, the OSC regions and OSC system and user servers are shut down first, and the OpenFrame system servers are shut down last.

  1. OSC regions shutdown

    Any pre-shutdown programs registered in the PLT (Program List Table) are executed just prior to shutdown. After the OSC regions are shut down, resources such as the shared memory, directories and files are deleted.

  2. OSC system and user servers shutdown

    The OSC system and user servers are shut down in the reverse order that they were started, according to the ofosc.seq configuration file.

  3. OpenFrame system servers shutdown

    The OpenFrame system servers are shut down in the reverse order that they were started, according to the ofsys.seq configuration file.