This section describes various language and environment considerations that you should keep in mind when writing a CICSPlex® SM API program. Note that all of the usual language considerations that apply to the various environments (CICS®, MVS™ batch, TSO, and NetView®) also apply to CICSPlex SM programs written to run in those environments.
For Assembler programs that run in an MVS batch, TSO, or NetView environment, you need to be aware of the following special considerations:
For PL/I programs, you need to be aware of the following special considerations:
DCL EYUPTPTR POINTER;
If you plan to run C programs under NetView, you need to be aware of the following special considerations:
#define COMMAND "COMMAND "
Some of the CICSPlex SM resource tables use COMMAND as an attribute name. If you use #include "dsic.h" as supplied by NetView, the resource table attribute names are converted and cannot be processed by CICSPlex SM.
One way of handling any potential conflicts is to undefine the COMMAND value, like this:
#include "dsic.h"
#undef COMMAND
#include "feedback.h"
.
.
.
If you want to, you can also redefine the COMMAND value using a new name that does not conflict with any resource table attribute name, like this:
#include "dsic.h"
#undef COMMAND
#define XCOMMAND "COMMAND "
#include "feedback.h"
.
.
.
The CICSPlex SM API cannot be used from within the user-replaceable programs EYU9XESV and EYU9WRAM.
The CICSPlex SM API may be used from within the CICS XICEREQ Global User Exit program. You must avoid recursion within the CICSPlex SM API program and the exit should not delay any requests issued by CPSM related tasks.
The use of the CICSPlex SM API from within other CICS Global User Exit points is not recommended as the results are unpredictable.
The CICSPlex SM API cannot be used from within a program that is invoked through the STATDEF view. Where access to the API is required, you must start another task and invoke the API from the new task.
[[ Contents Previous Page | Next Page Index ]]