Hi there,

in the last few years we have more and more application programmers that come from the Java world. In this world they are accustomed to put a lot of logging information in their programs. Now we had the situation, that they begun to add these information also to CICS programs using the COBOL DISPLAY command. Bad idea.

Question: is there a better, more efficient way in CICS to do an application logging? 

We thought of 2 kinds of log:

• event logging that corresponds the classic log4j framework
• alert logging that contains all the information in case of warnings/errors

Thanks for your opinion!

Best regards,

Wolfgang

------------------------------
Wolfgang Beikircher
------------------------------

In CICS COBOL programs, the old standard was to write to a CICS TD Queue.
The following are often defined in CICS but you can add a special DD to your CICS to separate the logging.

you may also use the CICS Journals to write log information to the z/OS system Logger. 
This is often used for Recovery logs, but we also use it to write Application Dump information.

Best Regards,
              Graham

------------------------------
Graham Franklin
------------------------------

Wolfgang,

Using DISPLAY commands in COBOL are not as bad as they used to be.  They are converted to WRITEQ TD and written out the the CEEMSG queue.  The problem is that LE writes dumps and messages to that queue as well so you might have to scan through a bunch of other messages to find what you are looking for.

I worked with a customer in the past where we wrote a general purpose module to handle logging.  We allowed different applications groups to own their own Extra Partition Queue, and created a program that had a standard message header that indicated the program that wrote the message.  We used a message indicator to identify informational messages versus error messages.

We found that it ended up being over used in some environments, so we added logic so the messages could be turned off in a Production environment and would require system programmer manual intervention to allow messages to appear for short periods of time in Production.

We also found that collecting trace when issues occur was helpful in find the problems.  Hope that helps!

Regards,

Ezriel

------------------------------
Ezriel Gross
Rocket Software
Waltham NJ
17816842672
------------------------------

Hi Wolfgang,

I fully agree with you that you need 2 types of logging.

Alert logging must be found easily and without a lot of tools. As Graham mentioned, a TD queue is an option for that. This can be directed to SYSOUT or a dataset. At a former customer of mine they created an application for that, which reads the data and displays it from a whole CICSPlex. It had an option of highlighting certain messages and a function for searching. It was really helpful, but needs some work.

Logging for documentation purposes can be done via CICS journalling, Kafka or other tools, where the CICS journals require least effort. Important from my point of view is that the level of information can be controlled. 

Kind Regards

Helmut

------------------------------
Helmut Roese
COM Software GmbH
Eschborn
------------------------------

I know, I'm rather late with my answer but I want to thank you all for your contributions. 

Now we had some time to look more into the subject. The CICS Journals sound very interesting. Especially because they use the same infrastructure from z/OS as the SMF records do (namely the system logger services). So this systems has to be fast in writing log records. Now it comes to my mind that we could maybe use the same services also for the business application logging in our batch jobs. But it seems there are only Assembler interfaces to use it. Is that correct? In this case it is somehow bad because we don't have Assembler knowhow in our shop.

So maybe the best way to go would be to use dedicated TD queues in CICS and for the batch part have one module that writes a log files dynamically? I would try to avoid to write the log in Db2 because otherwise every batch program would be a Db2 program. 

The last technology that comes to my mind (as @Helmut Roese already somehow suggested) is an event handler. We don't have Kafka running for mainframe stuff but we have the MQ. Would that be a viable alternativ to explore? Obviously in first place in the performance perspective.

------------------------------
Wolfgang Beikircher
------------------------------