CICS Considerations

The C Socket programming interface supports writing applications for either a CICS® or batch execution environment. This is also true for the EZASMI macro and the EZASOKET call interface.

However, while the Assembler SOCKET macro and the TCP/IP for z/VSE HLL preprocessor (resolving EXEC TCP calls) allow to explicitly specify the execution environments, this is not possible with the BSD-C socket interfaces.

A programmer can write bimodal modules or applications, being called from either a CICS or batch program. The TCP/IP runtime services act according to the execution environment's requirements. That is, they eventually use CICS services (for example EXEC CICS WAIT) where appropriate.

To force an application to dynamically determine the environment it is running in, you need to include the following 2 OBJ files in the application's link-edit step:
  • IPCICSRQ (TCP/IP for z/VSE only)
  • DFHECI

Omitting those two files cause the application to act CICS unfriendly even if running under CICS' control. For example by issuing VSE GETVIS requests instead of CICS GETMAIN.

Note: This is true for non-LE socket applications using the BSD-C interface of TCP/IP for z/VSE. The C socket interfaces provided by the VSE Language Environment® 1.4 C runtime do not require these modules to be linked for the purpose described above. This is already covered by the TCP/IP for z/VSE support for the LE/VSE 1.4 C socket interfaces, transparently to the application. This support is described in TCP/IP Support for the LE/VSE C Socket Interface.