Nowadays most CICS programming has turned into coding of services working as a back-end for a web interface. There are though still many systems around that is using traditional CICS screens. Developing a CICS program that communicates with a CICS screen may be a little hard. If you do not have any requirements regarding colours or fields you can create a very simple screen dialogue.

The central CICS commands for screen communication are SEND and RECEIVE. These two commands are available in many different flavours depending on your needs. I will now show you a piece of code that allows you to read everything that has been entered on a blank CICS screen (the one where you enter a transaction id in the upper left corner):

01  screenArea.
  03  screenLine          pic x(80) occurs 24.
01  screenAreaLength      pic s9(4) binary.
01  maxAreaLength         pic s9(4) binary.
...
move length of screenArea to maxAreaLength
exec cics
  receive into(screenArea)
  length(screenAreaLength)
  maxlength(maxAreaLength)
  notruncate
  nohandle
end-exec
perform processScreenArea
if screenAreaLength < maxAreaLength
  move spaces to screenArea(screenAreaLength + 1:)
end-if
exec cics
  send text noedit from(screenArea)
  erase
  nohandle
end-exec
goback.

If your CICS session is working in 24 lines mode then the variable screenArea will contain every single character entered on the screen when the transaction was invoked. In the procedure (or paragraph/section) processScreenArea you can then manipulate the contents of screenArea. The following SEND will then write screenArea to the CICS screen including the changes made by processScreenArea. The NOEDIT option will make CICS process the next hit of Enter or a function key as if you had entered the data directly on a blank CICS screen. There is no need for a EXEC CICS RETURN TRANSID if you just fill in the first four bytes of screenArea with the transaction id you want executed as the next transaction. It will of course only work properly as long as the end user does not alter the first four characters on the screen.

As you might imagine the above trick should not be used for end user CICS dialogues. I use the trick as an easy way to read data into my own CICS programs (for my own internal use). The program then displays an answer where I can just alter a little in the previous input to make the program do something else. Many installations maintain some DB2 tables using dynamic SQL statements usually executed by SPUFI or a similar tool. This way of maintaining DB2 tables are typically a result of not having time enough to develop a CICS application to do the job. Using the above trick it should be fairly easy to create such a CICS application.