Browse Prior Art Database

Mandatory method for inclusion of module name, level and timestamp in program code.

IP.com Disclosure Number: IPCOM000132020D
Original Publication Date: 2005-Nov-29
Included in the Prior Art Database: 2005-Nov-29
Document File: 3 page(s) / 68K

Publishing Venue

IBM

Abstract

We propose that we use a combination of available compiler options and newly created classes, header files, routines, compiler options and libraries to ensure that each load module (lmod) can be easily identified when a storage (memory) dump is being looked at. This will contribute to faster PD/PSI (problem determination/program source identification) downstream for the support organizations. Currently, it is not mandatory that development include the load module name, release and timestamp information for every module that is part of a program. This causes a problem when time is wasted trying to ascertain module specifics during problem debug and resolution. Implementing this new approach will cause a standardized way of providing this information when a storage (memory) dump is being looked at.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Mandatory method for inclusion of module name, level and timestamp in program code .

Main Idea

Software is developed and shipped inconsistently, which subsequently increases the resources spent on supporting it downstream. This disclosure deals specifically with the inconsistent identification of the various program parts, i.e. modules, lmods or object binary files and how to standardize it.

We propose that we use a combination of available compiler options and newly created classes, header files, routines, compiler options and libraries to ensure that each load module (lmod) can be easily identified when a storage (memory) dump is being looked at. This will contribute to faster PD/PSI (problem determination/program source identification) downstream for the support organizations. Currently, it is not mandatory that development include the load module name, release and timestamp information for every module that is part of a program. This causes a problem when time is wasted trying to ascertain module specifics during problem debug and resolution. Implementing this new approach will cause a standardized way of providing this information when a storage (memory) dump is being looked at.

We currently use several programming languages on different platforms when developing programs that we either use internally or package for external sale. That current list includes, but is not limited to, the following: s390 Assembler, C, C++, Java, PL/X, REXX, SQL, RPG, Cobol and Visual Basic. Some of these languages were designed to pick up the module name, level and timestamp and place it into an area known as the 'eyecatcher' section when storage is being viewed for debug purposes. However, this is not a standard requirement and thus is not adhered to for every language on every platform. In some cases the needed means to do this are nonexistent.

     S390 Assembler and PL/X are examples of languages that currently do this. The illustration below depicts what occurs for these 2 languages on the OS390 (host) platform:

1

Page 2 of 3

Source

Code Inputted...