The Remote IMS Server runs on IMS/ESA as an "explicit mode" transaction - commonly known as a "CPI-C driven" transaction. This transaction type was introduced in IMS/ESA Version 4. A CPI-C driven transaction does not use an IO PCB to send and receive messages from the IMS queue, it uses calls to APPC/MVS to send and receive messages directly from APPC/MVS - effectively bypassing the IMS queues.
In addition to managing the communications by itself (instead of relying on IMS), it is also responsible for scheduling PSBs and issuing syncpoint requests. The Remote IMS Server product is written in COBOL and is supplied partly as source code and partly as object code (OBJ). The COBOL source is the main program for the Server and the OBJ is a subroutine called by the main program. The main program performs all of the CPI-C calls for communications, calls SRRCMIT and SRRBACK for syncpoint and calls AIBTDLI for PSB scheduling and termination. The subroutine is called to process all DL/I database requests and calls CBLTDLI or AIBTDLI as appropriate.
The Server software must be transferred from the distribution media to your IMS/ESA computer, compiled and linked for execution. The Server product is distributed on CD. The basic steps to create the executable module on your mainframe are:
The sections which follow provide a detailed explanation of these steps. After you have successfully tested Remote IMS you should review the chapter Server Configuration.
Choose the Server program files you want to use. This usually means selecting the files to match your mainframe COBOL compiler version. In addition, you can choose files for some different compiler options.
Please contact your sales representative if your company requires support for a COBOL compiler version or options that are not already provided.
Each folder contains a copy of the MFDBSRVR source program and a matching MFDBDLIC object module. The MFDBSRVR source program contains a PROCESS statement listing its compiler options. The options in this statement are used by the COBOL compiler when compiling the program. These options match those in the MFDBDLIC object module which resides in the same folder as its MFDBSRVR source program.
Most of the compiler options in the PROCESS statement are required for proper compilation or operation of the Server. For example, APOST and DATA(31). However, different sets of Server files are provided to enable you to vary the setting of the DYNAM and OPTIMIZE compiler options. To vary these options upload the files from the folder containing the options you want. You do not have to change the PROCESS statements in the MFDBSRVR program.
Suggestions on choosing the appropriate DYNAM and OPTIMIZE options are provided in the sections which follow. Locating the files which match your compiler version and options is described later in this chapter.
If your company inhibits use of the PROCESS statement in source programs, you need to consult the staff responsible for your mainframe COBOL installation for instructions on enabling the compiler options listed in the PROCESS statement.
The IMS/ESA Administration Guide for TM states that you must include the DFSCPIR0 module during link-edit to get the copies of the SRRBACK and SRRCMIT modules provided with IMS/ESA. These modules may be provided with other software products on your MVS system and may be product-specific. For this reason we recommend that you use the set of Server files with the NODYNAM compiler option. This makes the calls to these programs "static" calls which are resolved when linking the program.
You include the IMS/ESA and APPC/MVS libraries during the link-edit step to resolve the entry points. Using NODYNAM also ensures all the entry points are resolved when linking which reduces the number of problems you can encounter when executing the Server.
If you need to have calls to modules used by the Server resolved as a dynamic call, for example, AIBTDLI or CBLTDLI, select a set of Server files which specifies the DYNAM compiler option.
For special cases you can modify the MFDBSRVR source program's CALL statements. By changing the CALL to a "CALL identifier" instead of the "CALL literal" you can selectively choose which entry points are static calls and which are dynamic. If you do this, keep in mind that AIBTDLI and CBLTDLI are called in the MFDBDLIC object program and those calls are controlled by the DYNAM or NODYNAM compiler option.
These compiler options control whether the compiler should produce optimized object code. We recommend using a set of Server files with the OPTIMIZE option. You should only choose NOOPTIMIZE if you encounter conflicts with other mainframe system software.
The MFDBSRVR source program and the MFDBDLIC object module are contained in separate folders for the various COBOL compiler release levels and compiler options. The initial folders indicate the version of the COBOL compiler; subfolders under them provide for different compiler options.
The initial folders are:
\VSCOB40 - for VS COBOL II, Release 4.0
\COBMVS12 - for COBOL for MVS and VM version 1.2.0
Under each of these folders are four further folders named OPTION1, OPTION2, OPTION3 and OPTION4. They contain the combinations of the DYNAM and OPTIMIZE options as described above.
\OPTION1 - NODYNAM OPTIMIZE
\OPTION2 - DYNAM OPTIMIZE
\OPTION3 - NODYNAM NOOPTIMIZE
\OPTION4 - DYNAM NOOPTIMIZE
For example, the set of Server files for VS COBOL II release 4.0 using the recommended NODYNAM and OPTIMIZE compiler options are:
x:\VSCOB40\OPTION1\MFDBSRVR.CBL
x:\VSCOB40\OPTION1\MFDBDLIC.OBJ
Where x: is the name of the drive containing the CD.
When you have located the set of Server files, use your file transfer program to upload them to your mainframe.
The mfdbdlic.obj file must be transferred as a binary file since it is an EBCDIC object code file. Be sure you do not use a file transfer setting which performs ANSI-EBCDIC conversion. Also, do not use an upload setting which causes carriage-return or line-feed (CR or LF) characters to be removed. This file should be uploaded to a PDS on your mainframe that is suitable for object modules. That is, the PDS should have a RECFM of "FB" and an LRECL of 80.
Upload the mfdbsrvr.cbl program to a PDS for COBOL source. When transferring this file you must use a file transfer setting to convert the file to EBCDIC and to remove CR/LF characters. That is, transfer this file in the same way as you transfer all other source files.
The names of these programs are not particularly important. You may change the names if they are not acceptable for your company's naming standards. If you change the name of the MFDBDLIC called module, ensure you change the source code for MFDBSRVR to call this new name.
If you change the name of the MFDBSRVR program, make sure that it matches the APPC/MVS TP profile you setup.
See the chapter Configure the Mainframe for more details. The examples throughout this chapter assume the default name of MFDBSRVR. For simplicity, we recommend using the names as supplied unless they violate your standards.
The procedure to compile and link the Server programs varies depending on whether you use dynamic or static calls:
For all Server load modules, APPC/MVS requires 31-bit addressing mode so the MFDBSRVR and MFDBDLIC modules must be linked using the linkage editor "AMODE(31)" option. Failure to use this option results in the Server program failing with a S0C1 abend. Also, when linking the MFDBSRVR main program do not use the "ENTRY DLITCBL" control statement. Explicit mode transactions, such as the Remote IMS Server, do not use this IMS/ESA entry technique.
When compiling and linking MFDBSRVR you need the APPC/MVS and IMS/ESA system libraries to resolve the CPI-C and IMS called modules. For example, SYS1.CSSLIB and IMSVS.RESLIB PDS libraries. Note, these names may be different for your mainframe installation.
These PDSs should be listed in the SYSLIB DD statement in your link edit step. Consult your systems support staff for the names of these libraries if they are not included as part of your standard JCL.
There are several ways to include the MFDBDLIC object module you uploaded into the MFDBSRVR load module. One is to have the PDS which contains MFDBDLIC to be listed in the SYSLIB DD statement for the link edit step. If the PDS you uploaded MFDBDLIC to is not in the SYSLIB list, consider copying MFDBDLIC to a PDS which is in the SYSLIB list. In either case, as long as MFDBDLIC can be found in the SYSLIB list it automatically links in because of the static call used in MFDBSRVR.
An alternative technique for linking in the MFDBDLIC object module is to use the linkage editor "INCLUDE" control statement. The INCLUDE statement causes a specific module to be linked in from any PDS. Consult with your system programming staff for assistance with the required JCL, DD-names or PDSs. An example of the INCLUDE statement is:
//MFOBJ DD DSN=UPLOAD.OBJ.PDS,DISP=SHR
//SYSIN DD * INCLUDE MFOBJ(MFDBDLIC) /*
In this example, the MFOBJ DD card names the PDS into which you uploaded the mfdbdlic.obj file. The SYSIN DD card is shown as an example only. You place the INCLUDE statement for the DD-name your JCL or PROC specifies for linkage editor control statements (such as ENTRY DLITCBL).
Compile and link the MFDBSRVR program. Use your standard JCL and/or PROCs for compiling COBOL programs.
The MFDBDLIC object module must be linked to create a load module. This load module must be present when executing MFDBSRVR. Use your standard JCL and/or PROCs for linking object modules.
Copyright © 2001 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.