If you have any questions about the content of this page, please contact CICS Request for clarification

We are intensely aware of the interest in bringing CICS and the World Wide Web together. The world's premier transaction server platform of all time (CICS) is ideally suited to provide data to the world's newest and arguably the most flexible display platform, WWW. While I believe that to be true, sadly, some of our own coding techniques have prevented the widespread access to CICS business logic from web based applications, see Monolithic vs. Presentation/Business Logic below.

• CICS Web Services
• Socket Tasks
• EXCI (ECI) Tasks
• DPL Command Subset
• Challenges For CICS Web Applications
  • Monolithic vs. Presentation/Business Logic
  • Data Editing
  • Pseudo-Conversational COMMAREA
  • Terminal ID and TSQ Names
  • Debugging

Web applications access CICS at the NWRDC in several major ways:

• Via CICS Web Services (CWS)
• Via the TCP/IP Sockets facility (network programs).
• Via the EXCI (ECI) interface (JAVA, SHADOW WEB and SHADOW DIRECT, and batch jobs).

CWS (CICS Web Services)

The NWRDC is just beginning to deploy our first applications based on CICS Web Services. Such an application is a web aware COBOL program that processes web input and produces web output. The input and output can be HTML, XHTML or XML. There will be more information on this exciting new service in the near future. CWS applications are invoked by access a dedicated port off of the web address of NWRDC and utilize the new EXEC CICS WEB and EXEC CICS DOCUMENT commands.

Socket Tasks
This TCP/IP feature allows network programs, access to CICS programs. Network programs can be UNIX- or NT-based C-something routines (for example) written to the socket implementation that is native to TCP/IP itself. These programs can pass data to and from very special CICS programs. These special CICS sockets programs can invoke any other CICS program via a standard LINK command, but the special sockets program must invoke the socket API to actually transfer data to and from the network program. Socket tasks are invoked by accessing the appropriate port (one per CICS region) off the web address of NWRDC.

When the Socket connection is first made, the Sockets facility must be told several things: user ID, password, and transaction. The user ID and its password are verified and, if successful, the transaction is started.

EXCI (ECI) Tasks

EXCI (External Command Interface) tasks are started by external programs like Batch jobs or Shadow Web. ECI tasks are exactly the same thing but invoked by the JAVA Transaction gateway.  EXCI is a facility where a program  that is external to CICS can perform an "EXEC CICS LINK" to a CICS program. That link is a little different than one between two CICS programs. The external program must supply several extra parameters:

• CICS application ID
• User ID
• Password
• Transaction ID
• Program ID
• COMMAREA length (into CICS)
• COMMAREA return length (back from CICS)
• COMMAREA itself

Note the presence of both transaction code and program ID. Normally the transaction and its initial program are inexorably linked together. Not so when EXCI is involved. In this case, the transition must point to the CICS mirror program (DFHMIR). The mirror program is passed the name of the program you want to invoke and the commarea you said to give it. The mirror program LINKs to your program and gets the returned commarea back to the invoking external program.

The transaction in an EXCI application dictates security, accounting and DB2 attributes, and that is about all. What this means is that you may have as many or as few EXCI transactions as you desire. You could get away with only one transaction that you use to invoke many different CICS programs, or you could have one transaction  per program. It's your choice. The amount of "after the fact" granularity that you desire, will dictate your choice. If many applications are lumped under one transaction, it can be difficult to identify the source of a problem (cost, speed, errors, etc.) down the road.

DPL Command Subset
Any CICS program invoked by either Sockets or EXCI(ECI) must be limited to the Distributed Program Link (DPL) command subset. See the CICS  Application Programming Guide for the complete list. It boils down to no terminal-oriented commands: no RECEIVE or SEND commands, etc.

Challenges for CICS Web Applications

Monolithic vs. Presentation/Business Logic
Historically, many of us have written monolithic applications. The same COBOL program that mapped the screen, processed the data, read and updated the files in response to users typing things into their 3270 terminal. It was efficient, clean and "the way we did things". We have to change all that. We have to learn how to separate an application's "presentation logic" from its "business logic". Presentation handles everything about how to display the data, how it looks, how the user interacts with it. The business logic, on the other hand, contains all the code to manipulate the data gathered by the presentation code. All file reads and writes, data base updates, all the guts of the application are there. Once the business logic has been written and debugged, it can be invoked from a variety of sources. Traditional 3270 terminals, Shadow Web REXX apps, JAVA applets under WebSphere and whatever is next month's latest and greatest killer presentations' scheme.

Data Editing
We have found another difficult aspect of this separation is in the editing of the data. Many web applications like to edit the data with code contained in the HTML presentation text. If the business logic must tell the presentation logic everything about each data item, we start to see some breakdown of this new separation.

Pseudo-Conversational COMMAREA
There is no pseudo-conversational COMMAREA, like we are used to in the 3270 world. Each leg of the conversation from a particular web user has no CICS-based tie to the previous leg of that conversation. Some "token" based scheme must be implemented to maintain unique data for a particular web user. Temporary storage queues and user-maintained data tables are often used for this purpose. My preference is UMDTs, as they are much more flexible.

Terminal ID and TSQ Names
There is no meaningful "terminal ID". Care must be exercised in the use of temporary storage queues. Traditional TSQ names (8 characters) have been composed based on the transaction and the terminal ID. New TSQ names (16 characters) must nave a new standard. I have used a combination of time, task number (EIBTASKN) and an application-specific literal to generate a unique name. Of course, such a name must be passed back to the presentation layer so it can be returned on the next leg of the conversation.

Debugging
Debugging web applications can be difficult. IBM has introduced CEDX to aid in this endeavor. Intertest can also monitor non-traditional tasks. (See the section on "INTERTEST" for details.) My trick is to always write a 3270 presentation, so debugging the business logic is more straightforward. Remember, if the 3270 presentation is only for testing, it does not need to be pretty.