The general concept for the Remote IMS product is:
This chapter describes these steps in more detail and highlights specific issues with the Remote IMS product. It also covers CPI-C driven transactions in general.
When you are familiar with this basic operation you should also review the chapters Technical Specifications and Communication Details for more information.
The following list looks at each of these steps in detail.
An application running under IMS product makes a call to DL/I using a database PCB. All of the IMS Option supported call interfaces are supported. That is, CBLTDLI, ASMTDLI, PLITDLI, CBLHSSR, PLIHSSR, CEETDLI, AIBTDLI and any other language-dependent entry points supported by IMS Option. In addition, any user-written entry points based on the USRTDLI sample program in IMS Option are supported.
IMS Option looks up the DBD-name for the database PCB in its Database Catalog. If the DBD-name is not a Remote Database, the database call is processed by IMS Option as it would normally. If the DBD-name is a Remote Database, IMS Option edits the DL/I call construct using the DBD and PSB information Genned to the IMS Option system. For example, the call function and SSA syntax are validated against the dynamically created IMS Option "ACB". If call validation fails, the results are returned immediately to the application program.
IMS Option calls the Requester and passes it control information and the application program's DL/I call parameters.
If a conversation to the Server is not already active, one is established. A popup window is displayed indicating the conversation start-up is in progress - the popup is cleared when the conversation is established. Once established, the Remote Server occupies an IMS/ESA dependent region and can access IMS/ESA resources.
Security checking is performed by either the third-party communications product or Mainframe Manager, depending on the communications protocol in use. Authorization is confirmed via APPC/MVS using RACF, ACF2 or Top Secret as defined by your installation. If the conversation is rejected due to invalid authorization, the Requester prompts for a User ID and Password and re-tries the connection.
The Requester and Server exchange configuration information. This exchange coordinates variable options and enables changing the version numbers of the Requester and Server software versions at different times without disrupting ongoing applications.
For the first call to a Remote Database after a PSB scheduling in IMS Option, the Remote Requester sends a message to the Remote Server to have it issue an APSB call (allocate PSB). The PSB-name used is the same name used by IMS Option when it scheduled the application.
The Requester packages the DL/I call into a message and sends it to the Server. The message is constructed using the IMS Option PSB and DBD definitions to determine SSA lengths and segment I/O area lengths and types (such as fixed or variable, logical children, concatenated segments). The length information for the segments is used by the Requester to construct the message packets for update calls. This length data is sent to the Server so it can construct the packets for retrieval calls.
The Server receives the message and translates it into a call to CBLTDLI or AIBTDLI. It issues the call, packages the results into a return message and sends it back to the Requester.
The Requester receives the message and returns the results to the application program's calling parameters. The application resumes processing and can make subsequent calls to Remote Databases or any other IMS Option database type. In other words, processing returns to Step 1. The conversation between the Requester and Server is maintained so that database position and record locks are maintained between DL/I calls. The state of update calls remain "in-flight" until a syncpoint occurs.
Remote IMS automatically prompts for a User ID and Password (in Step 4 above) when connecting to a remote system which requires them. This is done using a popup window. This popup window includes an option to save the values for subsequent connections. You can save them in memory or in a disk file depending on the UseridFile setting in the rmtims.ini file. If saved, the password is encrypted to avoid unwanted disclosure. See the chapter Requester Configuration for details on saving the User ID and Password.
If the remote system does not require a User ID and Password, Remote IMS does not prompt you for one. Alternatively, some communication products enable you to store a User ID and Password in the CPI-C Side File definition. See the chapter Configure PC Communications for more details of each communication product's security handling.
The Remote IMS client will prompt for a User ID and Password depending on the MFMSecurity setting in the rmtims.ini file. If MFMSecurity is enabled, the client will prompt for User ID and Password before connection. If disabled, the client will attempt connection and only prompt for User ID and Password if a connection fails security authorization. See the chapter Requester Configuration for more information on security handling.
Syncpoint requests are issued by IMS Option to the Requester according to the rules for IMS applications. For example, commits at GU to the IO PCB and normal termination and backout on application request or abnormal termination. See the chapter Syncpoint Considerations for more information.
The Requester forwards syncpoint requests, if necessary, to the Server for processing. The Server issues SRRCMIT or SRRBACK calls to IMS/ESA for commit and rollback as required for CPI-C driven applications. The Requester does not send a syncpoint request to the Server if no Remote Databases were accessed in the unit-of-work.
When the application terminates, IMS Option notifies the Requester of the PSB termination. The Requester sends a message to the Server requesting it to issue a DPSB call to deallocate the PSB.
The Server occupies an IMS/ESA dependent region until the conversation between the Requester and Server is terminated. Once terminated, this region is available for use by other transactions.
The Requester can be configured to terminate the conversation at two different events:
Ending the conversation with the application program minimizes your use of IMS/ESA dependent regions. Ending the conversation with the Application Region provides the best performance when running multiple online applications in series, for example, when message switching from transaction to transaction. See the chapter Requester Configuration for a description of the KeepConversation and WhenStopTp configuration settings. By default, the conversation is terminated when the Application Region terminates.
The TCP/IP communications option supports an idle client timeout feature, whereby a connected client left sitting idle for a preconfigured time period will be disconnected. This releases server resources such as message region, and database record locks which would otherwise be constrained by the idle connection. This addresses the problem that would arise if a programmer took a lunch break in the middle of a debugging session.
This feature is configured in in the Mainframe Manager started task configuration file, Time out for connectionparameter.
Copyright © 2001 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.