Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Producing error documentation

This section lists which diagnostic documentation a user should create when he/she wishes to report a system error to the software support.

  • A detailed description of the error situation and an indication as to whether and how the error can be reproduced.

  • The BS2000 operating system version number with correction level.

  • openUTM-specific documentation:

    • UTM dumps; you must take care to ensure that all dumps from all tasks which were active at the time the error occurred are supplied

    • all available traces. When reproducing errors, TESTMODE=ON should be activated, where KDCDEF parameter MAX TRACEREC should be set to at least 3000 (when openUTM-D is used: at least 10000).

    • in the case of warm start errors, errors in the KDCUPD and if the application aborts with PMIO22, the file(s) of the KDCFILE are required

    • openUTM version number with correction status

    • the log file of KDCDEF

    • linkage editor listing for the application program

    • the SYSLOG file(s)

    • user dumps for errors such as XT48, XT58..., for example

    • SYSLST and SYSOUT logs

  • In the case of errors in UTM applications which are configured with BCAMAPPL T-PROT=(SOCKET,...,SECURE) additonal documentation is required:
    • User-Dumps of the SSL-proxy processes for errors such as XT48, XT58, in this task.

    • SYSLST- und SYSOUT logs of the SSL-proxy process.

  • Plus, for errors associated with FHS:

    • specification of the FHS version used, with correction status

    • IFG format definition (LMS element of type F)
    • ready-to-use format module  (LMS element of type R)

    • user dumps and UTM dump, if available

  • For errors associated with databases: Please refer to the release notices for the database systems in question.