Skip to Main Content
IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Categories Runtime
Created by Guest
Created on May 4, 2023

Allow DFHJVM* logs to roll based on file size

We recently upgraded to CICS 6.1 and encountered an unexpected log message from a Liberty JVM. It wasn't frequent enough to trigger alarms in test, but did once it went to production, filling our logging partition. We attempted to delete the massive files, but the JVM held on to them somehow and they kept increasing in size (despite not being visible to the OS).

We have an open support case for this, but a root cause is that the DFHJVM* log files only roll on CICS or JVM restarts. I suggest rolling log files based on a maximum file size configuration would greatly help. E.g. MAX_LOG_SIZE=100MB and then make a new log file once the old one hits 100MB+. Viewing a massive log file is almost impossible anyway.

Idea priority Urgent
  • Guest
    Reply
    |
    May 25, 2023
    CICS Development: The particular error that was causing the logs to fill was cause by a failure in the container iterator, which is a regression and APAR PH54360 has been raised to fix this.

    As for rolling logs, although nice to have, they would only mask a fundamental problem. CICS offers alternative approaches to managing these files.

    The development effort to implement dynamic output file switching - and then to coordinate such updates between our internal logging components (Assembler, C, Java, OSGi and Liberty) - is currently very large compared to the modest functional gain. We currently have higher priority items taking our focus, so the idea is being declined.

    CICS offers alternative approaches to managing these files (see below).

    Supporting information:

    dfhjvmout is the standard output stream, it's content is written by customer applications, not CICS
    dfhjvmerr reports errors and exceptions, if the file size grows it is an indication that immediate application fixes are required, or there is a internal error that requires attention from IBM service
    dfhjvmlog contains essential events and messages which should be finite except where repeated errors are occurring, guidance is as above. However, you can also control the granularity of the messages that go to this file with the LOG_LEVEL= INFO | WARNING | ERROR | NONE parameter in the JVM profile.
    dfhjvmtrc is only produced when SJ and AP domain trace levels are set greater than 2, this should not be used in production and is an IBM service diagnostic.
  • Guest
    Reply
    |
    May 11, 2023
    The particular error that was causing the logs to fill was cause by a failure in the container iterator, which is a regression and APAR PH54360 has been raised to fix this.

    As for rolling logs, although nice to have, they would only mask a fundamental problem. CICS offers alternative approaches to managing these files.

    dfhjvmout is the standard output stream, it's content is written by customer applications, not CICS
    dfhjvmerr reports errors and exceptions, if the file size grows it is an indication that immediate application fixes are required, or there is a internal error that requires attention from IBM service
    dfhjvmlog contains essential events and messages which should be finite except where repeated errors are occurring, guidance is as above. However, you can also control the granularity of the messages that go to this file with the LOG_LEVEL= INFO | WARNING | ERROR | NONE parameter in the JVM profile.
    dfhjvmtrc is only produced when SJ and AP domain trace levels are set greater than 2, this should not be used in production and is an IBM service diagnostic.

    The development effort to implement dynamic output file switching - and then to coordinate such updates between our internal logging components (Assembler, C, Java, OSGi and Liberty) - is currently very large compared to the modest functional gain. We currently have higher priority items taking our focus.