Now we issue the console message in Figure 6, using CICS services just for execution flow tracing purposes. Since we have an EIB, we can see if we have a valid COMMAREA available. We do this by checking the COMMAREA length field contained within the EIB. If this is greater than zero, then a COMMAREA exists. When we have determined if a COMMAREA is available, we then set the relevant 88-level flag to indicate this.
Next, we attempt to determine how our sample program was called in the CICS environment. We do this by using the EXEC CICS INVOKINGPROG API and comparing the results with a field of eight blanks. If blanks are returned, then we’ve been invoked by a CICS transaction starting. If not, then we were called by another CICS program using CICS services, such as EXEC CICS LINK, etc.
Our next CICS environment step is to make a static call to another program (see Figure 7). In this simple example, we call the LE z/VSE delay callable service to perform a temporary “wait.” In this invocation, we delay for approximately 2 seconds.
We review the returned feedback code so we know if the delay actually occurred. In a real production situation where the delay may be important, this would allow the program to know if whatever we were waiting for had actually experienced a 2-second interval.
Again, as a demonstration using the code in Figure 8, we perform a dynamic call in the CICS environment. This is to the same random number generator callable service that we used earlier in the batch execution flow example.
Due to the OPEN/READ/WRITE/CLOSE, etc. verbs being restricted in a CICS environment, we demonstrate a VSAM file read in the CICS environment using CICS services. To perform the same processing from this case study module in the batch section would require all I/O processing to be performed in another module that needs to be dynamically called.
Expected Case Study Output
Figure 9 shows some samples of the output from the program run in both environments.