Wie kann man Software auf einem Mainframe debuggen?

Knowing your environment is a crucial step in debugging the software for errors. For example, if you are using IBM's DFSORT utility and if there are any issues with the SORT statements that you've written, you should know where you can access information about the issue in order to resolve it. It is important that you provide the SYSOUT DD statement in the JCL you write for DFSORT to be able to write messages about the error. DFSORT issues messages with an ICE code in the format ICExxxx. The last character of the ICE code will be E error messages and it'll be I for Informational messages. The SYSOUT DD can be accessed from SDSF. It is recommended that you take a look at the utility's user guide before using it.

When debugging a mainframe program, knowing your environment is vital. Picture the mainframe as a vast city—neighborhoods represent aspects like storage, communication, processing, and the programming language. Understanding involves knowing each neighborhood's layout: building types (software components), communication methods (network protocols), organizational systems (operating system), and the language spoken (programming language). Debugging without this knowledge is like fixing a city issue without a map. A deep understanding enables efficient navigation, swift issue identification, and use of suitable tools for effective resolution. Think of it as a detective using city layout and language knowledge for expedited problem-solving.

Debugging software on a mainframe involves using specialized tools and techniques tailored to the mainframe environment. Here are some common methods for debugging software on a mainframe: 1. Interactive Debugging Tools 2. Dump Analysis 3. Logging and Tracing 4. Performance Monitoring Tools 5. Cross-Reference Tools 6. Code Profiling 7. Static Analysis 8. Collaboration and Documentation 9. Vendor Support and Documentation

Knowing your environment and the system/application you are debugging is crucial. Being able to quickly find error and reason codes is also crucial. Utilizing debugging facilities, such as Xpediter, makes debugging very easy. Adding the ability to turn on verbose logging is also a good practice during those times you need details that you wouldn't normally get out of a production log.

There are lot of debugger tools available in market, IBM debugger comes with the installation and Xpeditor is a 3rd party one. Nowadays IDE like iDz and platforms like Zowe are having very good debugger capabilities with great gui also. Debugger is very essential not only to trace faulty code in a program but also several times , it helps the programmer to understand existing code or some particular functionality. It is imperative to teach juniors about usage of debugger and encourage all to use them instead of relying on ancient and outdated methods like usage of DISPLAYS

This is by far the most underrated thing when juniors are trained in mainframes. It reflects a lot about the type of coder or learner. I usually ask about this in interviews and any person who has paid attention to what kind of information is coming in logs and SYSOUT messages, is definitely a great candidate with a keen eye. The problem also lies with trainers and mentors because they do not encourage this practice of going through abend logs and SYSOUT messages, and to come up with questions regarding them.

Applications written in Language Environment (LE) conforming High Level Languages (HLLs) can be compiled with the TEST option which will, at abend time, generate a human-readable formatted dump with a map of variables and their values at abend time and a message indicating the source code line on which the abend occurred.

My process with COBOL was for my early code to have DISPLAY statements in every paragraph to verify that I was going through that paragraph. Once I verified I was going through the paragraphs, I could start adding displays telling what was going on at that point in time. For example, one time I had to perform a byte-by-byte comparison, but instead of moving the receiving byte I was incrementing the sending byte. This caused the counter to exceed the record limits. I wound up having to display the counters to figure out what was going on. Sometimes it is the simple errors that trip you up.