OpenFrame OSI 7.2

This chapter briefly describes the new features of OpenFrame OSI 7.2.

1. New Features

This section describes the new features of product.

1.1. Multi-node support

OSI multi-node function is supported by adding and changing the following functions. For details, refer to the description of each section.
- Managing resources in RDB tables.
- Changing 3270 gateway to 'OFGW'.
- Changing the structure of region server startup/shutdown by adding a new osiomsvr server.
- Changing MPP server by TranClass unit.

1.2. Managing with resource tables

Resources used by OSI are managed in the RDB table. Tables are created and deleted with the osiinit tool.

The following is a description and list of tables that manage resources.

SD and RTSD information

The System Definition Resource, which was managed in the system library and shared memory, has been changed to be managed in the RDB table.

OFM_OSI_SD_APPLCTN
OFM_OSI_SD_DATABASE
OFM_OSI_SD_LTERM
OFM_OSI_SD_TERMINAL
OFM_OSI_SD_TRANSACT
OFM_OSI_RTSD_APPLCTN
OFM_OSI_RTSD_DATABASE
OFM_OSI_RTSD_LTERM
OFM_OSI_RTSD_TERMINAL
OFM_OSI_RTSD_TRANSACT

CI information

The CI resource (terminal session information) managed in the existing shared memory has been changed to be managed in the RDB table.
```
OFM_OSI_CI
```
MODSTAT information

MODSTAT information managed in the existing system library has been changed to be managed in the RDB table.
```
OFM_OSI_MODSTAT
```
Message Queue

The existing shared memory and VSAM were used as storage, and it was changed to be managed in the RDB table.
```
OFM_OSI_MQ
OFM_OSI_MQ_BMP
OFM_OSI_MQ_MASTER
```
Region information

Region information managed in the existing shared memory has been changed to be managed in the RDB table.
```
OFM_OSI_REGION
```

For details on how to use osiinit tool, refer to OpenFrame Tool Reference Guide.
For more information about tables, refer to 'Appendix D. Resource Tables' in OpenFrame OSI Operator’s Guide.

2. Changed Features

This section describes the changed features of product.

2.1. Changing 3270 gateway to 'OFGW'

Removed the existing osi3270gw server and changed it to 'OFGW', a web gateway.

2.2. Changing structure of starting and shutting-down regional servers by adding a new osiomsvr server

Use the same as the existing method of starting through JOB submit using JCL.
Start a region as a system server after booting.
Execute tmboot in osiomsver and invoke service call with osiomsver in Runner (DFSMVRC0, DFSRRC00).
When the server is shut down through the /CHECKPOINT FREEZE command or the /STOP REGION command, respond to the Runner after executing tmdown in osiomsvr.

2.3. Changing MPP server by TranClass unit

Previously, one MPP server processed four TranClasses, it has been changed to process one class per server from this version.
When IMSAMSG job is submitted, 4 MPP servers are started for each described class.

2.4. Changing MPP service unit from class to transaction

As Tmax is changed to a structure dedicated to scheduling, it has been changed to match the message unit with the IMS DC.

2.5. Changing terminal management tool to VTAM module of OpenFrame Base

Search for VTAM resource with vtamadm tool and compile BEGINVTAM macro with vtamgen tool. VTAM dump is executed with vtamdump too.

For details on vtamgen and vtamdump tools, refer to the OpenFrame Tool Reference Guide.
Terminal information is managed in the VTAM module of OpenFrame/Base without using Vtam Definition (VD) managed inside the existing OSI.

2.6. Changing osisdgen and osisddump

Changed to use the IMSID instead of the dataset which is the target of osisdgen and osisddump tool.

For details on osisdgen and osisddump tools, refer to OpenFrame Tool Reference Guide.

2.7. Tmax server configuration

As the server is started in TranCass unit, the server name must be described by each class in the Tmax configuration.

*SERVER
OSIMPPSVR       SVGNAME = svg_node1, MIN = 0, MAX = 10

IMSAMPP_TCL1    SVGNAME = svg_node1, MIN = 1, MAX = 10, TARGET = OSIMPPSVR,
                CLOPT="-o $(SVR)$(CDATE).out -e $(SVR)$(CDATE).err"
IMSAMPP_TCL2    SVGNAME = svg_node1, MIN = 1, MAX = 10, TARGET = OSIMPPSVR,
                CLOPT="-o $(SVR)$(CDATE).out -e $(SVR)$(CDATE).err"
IMSAMPP_TCL3    SVGNAME = svg_node1, MIN = 1, MAX = 10, TARGET = OSIMPPSVR,
                CLOPT="-o $(SVR)$(CDATE).out -e $(SVR)$(CDATE).err"
IMSAMPP_TCL4    SVGNAME = svg_node1, MIN = 1, MAX = 10, TARGET = OSIMPPSVR,
                CLOPT="-o $(SVR)$(CDATE).out -e $(SVR)$(CDATE).err"

2.8. Managing OpenFrame configuration information by tables

The OpenFrame configuration information managed as a file has been changed to a structure managed by the database.
The format of the configuration meta file to be loaded into the database has been changed, and the files have been separated by product.
To synchronize the configuration information and respond to the multi-node environment, the information has been loaded and used in Tmax TCache.
The ofconfig tool has been added to manage the configuration information structure changes.
For more information on OpenFrame configuration, refer to OpenFrame Configuration Guide.

For details on ofconfig tool, refer to OpenFrame Tool Reference Guide.

2.9. Managing by error code tables

OpenFrame error information managed as a file has been changed to a structure managed by the database.
To load error information into the DB, insert function has been added to oferror tool.

For details on oferror tool, refer to OpenFrame Tool Reference Guide.

2.10. Arranging log output format of system and server

The log format between OpenFrame products and modules has been unified.

Date-time output format of log has been added.

Service log format

[YYYY-MM-DDTHH:MM:SS.ffffff] [SERVICE-NAME(PID)] [M] [MSGCODE] MESSAGE-CONTENTS

System log format

[YYYY-MM-DDTHH:MM:SS.ffffff] [EXECUTED-MODULE] [CODE] [MSGCODE] EVENT FREE-FORMAT-CONTENTS

Operation log format
```
[YYYY-MM-DDTHH:MM:SS.ffffff] [EXECUTED-MODULE] [CODE] [MSGCODE] EVENT FREE-FORMAT-CONTENTS
```
For more information about OpenFrame logs, refer to 'Appendix.D Log Management' in OpenFrame Base Guide.