II13292: JAVA FOR Z/OS:FAQ FOR JVM USE OF TRANSACTION DUMP (TDUMP)

APAR status

• Closed as documentation error.

Error description

• After SR14 the default dumping action for the JVM changes to
  Transaction Dump, in addition to the data currently requested
  at GA or in earlier service refreshes.
  This FAQ exists to answer some common queries.
  Q1. My users are writing JNI code in the shell, we don't want
  TDUMPs everytime a program check occurs, how can I turn this off
  ?
  A1. By coding envvar
  IBM_JAVA_ZOS_TDUMP=NO
  the behaviour reverts to the behaviour at GA thru SR13. No TDUMP
  will be taken.
  A confirmatory message
  JVMHP003: No transaction dump requested
  will be written to stderr
  Q2. My TDUMP was created with a HLQ I didn't expect, where did
  it come from ?
  A2. The HLQ used for the TDUMP data/set comes from the USS call
  pwd = getpwuid(getuid());
  pwd->pw_name;
  Depending on the uid for the thread on which the program check
  is handled you might see data/sets created with different HLQs.
  Q3. The default pattern name / hlq conflicts with standards
  at our installation, can I change it ?
  A3. By coding envvar
  IBM_JAVA_ZOS_TDUMP_PATTERN=string
  (*** SDK 1.4 users: please see the Note at the end of this APAR)
  you can specify a pattern name of your choice.
  For example
  IBM_JAVA_ZOS_TDUMP_PATTERN="DUMP.MVJ1.&JOBNAME..T&HHMMSS."
  The pattern string is passed unchanged through to the IEATDUMP
  service, so anything that's valid for IEATDUMP will work.
  A confirmatory message
  JVMHP011: User specified dump data/set name pattern for IEATDUMP
   was DUMP.MVJ1.&JOBNAME..T&HHMMSS.
  will be written to stderr
  Q4. I passed a valid pattern name, but I still didn't get a
  TDUMP ?
  A4. When the TDUMP fails, you'll see both a message on the
  console (msgIEA820I) and the return code and reason code
  frkm IEATDUMP are externalized by the JVM in message
  JVMHP004.
  For example
  (in syslog)
  IEA820I TRANSACTION DUMP REQUESTED BUT NOT TAKEN
    DUMP DATA SET NAME NOT VALID
  (in stderr)
  JVMHP004: Transaction Dump service IEATDUMP failed with
            rc=0x8 (8), reason code=0x21 (33)
  Be aware that not all manuals have the latest return and reason
  codes. Try looking them up in DOC APAR OW47548.
  The message JVMHP011 prints the exact name of the pattern
  as passed, so check that closely. Common problems include
  - not getting the right coding for the system symbol names
    e.g.
    IBM_JAVA_ZOS_TDUMP_PATTERN="DUMP.MVJ1.&JOBNAME..T&HHMMSS.."
    IBM_JAVA_ZOS_TDUMP_PATTERN="DUMP.MVJ1.&JOBNAME..T&HHMMSS"
    are both invalid
  - and coding the envvar with quotes in a WebSphere
    environment.
    e.g.
    IBM_JAVA_ZOS_TDUMP_PATTERN="DUMP.MVJ1.&JOBNAME..T&HHMMSS."
    is coded in a Websphere env file and msgJVMHP011 reports
  JVMHP011: User specified dump data/set name pattern for IEATDUMP
   was "DUMP.MVJ1.&JOBNAME..T&HHMMSS."
    since the double quotes are being passed, the allocation fails
    the env file should have
    IBM_JAVA_ZOS_TDUMP_PATTERN=DUMP.MVJ1.&JOBNAME..T&HHMMSS.
  Q5. More that one TDUMP was requested, can I limit it to one ?
  A5. This can happen if a program check occurs whilst getting
  diagnostic data following the initial program check.
  For example, if a program check occurs in CEEDUMP processing or
  whilst the JAVADUMP is being created.
  Envvar IBM_JAVA_ZOS_TDUMP_COUNT=n where n is an integer
  can be set to the limit the maximim number of TDUMPs to request.
  For example,
  export IBM_JAVA_ZOS_TDUMP_COUNT=1
  will restrict the number to taken to 1.
  During processing of any subsequent program checks message
  JVMHP010: No TDUMP requested, request threshold of n reached
  where n is the specified count.
  The default is 2, to allow for the diagnosis of those cases
  where a problem occurs in CEEDUMP or JAVADUMP processing.
  Q6. Can I change the storage ranges that are being requested ?
  A6. Not at this time. The storage ranges requested are
  SDATA=(GRSQ,LSQA,RGN,SUM,SWA,TRT,LPA,NUC,SQA)
  Note that the actual storage dumped depends on whether the
  JVM is running unauthorized or not. In most cases the JVM is
  running unauthorized in key 8.
  Q7. When I analyze the TDUMP using IPCS I'm unable to format out
  the system trace using command "ip systrace", any ideas ?
  A7. This is a bug in the dumping code, see OW54876. Please
  install the PTFs for this APAR to resolve the problem.
  The fixing PTFs are as follows
  UW89731 - R608 (OS/390 2.8.0)
  UW89732 - R703 (z/OS 1.1)
  UW89733 - R705 (z/OS 1.2)
  UW89734 - R706 (z/OS 1.3)
  UW89735 - R707 (z/OS 1.4)
  ** Note to Java 1.4 users **
  The IBM_JAVA_ZOS_TDUMP_PATTERN variable is only valid for
  SDK 1.3. SDK 1.4 users will need to set
  JAVA_DUMP_TDUMP_PATTERN=
  as documented in the 1.4 Diagnostics Guide and PQ83714.
  
  For other information regarding TDUMPs under 1.4 see APAR
  PK11506 with specifics on how to limit or stop dumps.
  
  *****
  IEATDUMP reason codes are documented in OW47548:
  

Local fix

Problem summary

• The Topics discussed in this APAR are no longer relevant at
  currently supported versions of the Java Virtual Machine on
  z/OS.
  
  Transaction dumps on z/OS are still used by the JVM in failure
  conditions, but the means of controlling them has changed.
  

Problem conclusion

• Almost all configuration of Java dump options should be
  performed by the Environment Variable:
  JAVA_DUMP_OPTS
  or by the commandline option (at Java 5.0 and above):
  -Xdump
  
  The Environment variable:
  JAVA_DUMP_TDUMP_PATTERN
  Has been retained to allow users to specify their own Dataset
  Names for saved Java TDUMPs. The desired name can also be set on
  the command line with the -Xdump suboption system:dsn=<label>
  
  More information about all of these settings can be found in the
  official z/OS Java Diagnostics Guide for the relevant version
  of the JVM in use.
  
  The Diagnostics Guides can be found on the web at:
  http://www.ibm.com/developerworks/java/jdk/diagnosis/
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels