We have a need to determine, at run-time, the invoking program of every EXEC CICS call and of every External Resource Manager call.
.
Our application programs are mostly Cobol programs.These Cobol programs often use a Cobol dynamic call to invoke other Cobol programs. So the invoking program of an EXEC CICS call or of an External Resource Manager call is sometimes a dynamically called Cobol program. Other times, the invoking program of an EXEC CICS call or of an External Resource Manager call is an application program that was invoked via EXEC CICS LINK or EXEC CICS XCTL or was the initial program of a transaction. No matter how the invoking program was itself invoked, we need to know the invoking program of every EXEC CICS call and of every External Resource Manager call.
.
Consider this scenario:
1) ProgramA is the initial program of a transaction.
2)ProgramA does a dynamic Cobol call to ProgramB.
3)ProgramB does an External Resource manager call.
.
In that scenario, the invoking program of the External Resource manager call is ProgramB. There is an XPI call that seems like it would give us exactly what we want. It is DFHPGISX Function(Inquire_Current_Program) Invoking_Program_Name(). But in this scenario, that XPI call done from an XRMIOUT exit program returns ProgramA as the Invoking_Program_Name even though ProgramA is not the program that issued the External Resource Manager call.
.
We currently successfully use an XEIOUT program to determine the invoking program of all EXEC CICS calls. The XEIOUT program is passed the address of the application RSA (UEPRSA). We can use the saved R14 in that RSA and figure out the invoking program from that.
.
Similarly, we currently successfully use an XRMIOUT program to determine the invoking program of most External Resource Manager calls. The XRMIOUT program is passed the address of the TRUEs parameter list. And then UEPHMSA in that parameter list is the address of the calling module's register save area. The R14 saved in there is usually a pointer into the application at the point where it made the External Resource Manager call. With that R14, we can figure out the program that made the External Resource Manager call.
.
But when the invoking application uses the DLI Call level interface (e.g Call CBLTDLI), the XRMIOUT method described above does not work. The RSA addressed by UEPHMSA from the TRUE's parameter list does not contain the registers of the invoking program. And there is no obvious way to chain from the RSA to the RSA of the invoking program.
.
There needs to be a supported method to determine the invoking program of a DL/I Call Level interface call when the invoking program might have been invoked via a dynamic Cobol Call.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server
We have no plans to upgrade XRMIOUT. As previously mentioned a DFHAPIQX INQ_APPLICATION_DATA XPI call can be madeXDLOPOST which will provide the required information.
Adding dummy comment as last update did not get mirrored to RFE
Adding dummy comment as last update did not get mirrored to RFE
We've discussed using XDLIPOST with Dan. We are already using XEIIN, XEIOUT, and XRMIOUT. We would like to keep the number of system exits to a minimum.
Has the user considered using the XDLIPOST Exit ? A DFHAPIQX INQ_APPLICATION_DATA XPI call can be made specifying RSA which will return the applications's RSA. I have tried this with an assembler program issuing a Call level DLI request and it works ok. Using the XRMIOUT will not work because the environment is stacked, we have an RMI call made as part of processing a calldli statement and such an invocation at XRMIOUT will not return information about the original CALLDLI statement from the application.