P Tracker is a z/OS system enhancement program that records program calls systemwide. Each invocation of a program will be recognized. The module name along with the name of the load-library from which the module was loaded from is recorded. P Tracker is, due to its low system load (overhead), very well suited to gather information for z/OS asset management, program inventory and license management.

With its ability to record module-name and load-library of the calling program as well as the module-name and load-library of the called program P Tracker discloses also chains of program and sub-program calls, referred to as “call sequences”. This is of particular value to programmers who have to maintain foreign applications that are insufficiently documented.

P Tracker consists of several components:

• The efficient P Tracker monitor called Collector that steadily gathers program usage data.
• The fast and efficient batch component P Tracker Inventory that is used to scan the z/OS volumes and to detect libraries and to determine vendor information from module text.
• Then there is the Reporter component that will generate summary and detailed information in various formats and reports to your requirements.
• The Export function forwards the Collector data to DB2 or to another relational DBMS to allow for user controlled analysis and reporting.
• Then there is the “Itinerary” component which uses the LIAM (License & Inhouse applications Asset Management) table to determine which Products and Applications are installed and used (or not).

Unlike other products P Tracker not only monitors batch program calls, it optionally monitors program invocations under CICS or other z/OS subsystems. Every dynamic program call is monitored.
When needed P Tracker’s monitor data can be supplemented with output of load module analyzers to detect even calls to subroutines in statically linked modules. This can be of help during conversion projects.

P Tracker can use different sources to collect the data that is necessary to provide the required usage information. Its major source is the SAF interface ICHRTX0n. P Tracker processes only the calls for the class PROGRAM. In addition, P Tracker can optionally intercept the program management SVCs to obtain metadata from invocations of LINK, LOAD, ATTACH, XCTL or STOW. These SVC interceptions are normally not necessary, the SAF exit delivers already the desired usage information including called and calling program and the libraries they came from.

The obtained invocation data is immediately transfered into P Tracker’s dataspaces. As a dataspace fills up P Tracker switches to an alternate dataspace and unloads the full one to DASD. P Tracker’s Collector is highly efficient, hence P Tracker can be smoothly deployed on all production and test LPARs as its system overhead is very low (normally not measurable).

The output datasets of the P Tracker Collector of a given time frame, for example a day, are called “chunks”. All chunks have the same format: FB, LRCL 220, BLKS 6480. The fields are System ID, Job Select Time, Job Step Number, Called Program, (Language), Source, Jobtype, Timestamp, Jobname, Stepname, Proc Step Name, Transaction, Job ID, User ID, Job Step Pgm, CICS Transaction, CICS Terminal, Job step PGM, Name of the (Calling program), Called Library, (Caller’s library). The fields in brackets are sometimes not filled, for example if Ptracker was started after the respective job was submitted or if the library is excluded by the filter.

The number of occurring program invocations is immense. It is therefore possible to limit the tracking of program calls in a meaningful way. P Tracker deploys generic exclude/include lists to decide which programs, jobs and libraries are to be tracked and which subsystems or components are to be entirely excluded from the monitoring process. This avoids collection of non-essential data.

P Tracker’s Inventory
P Tracker’s Inventory generates a comprehensive overview on partitioned datasets containing load modules for the entire z/OS system. The report contains information about the library names, the member names, and the copyright information found in the module text.

The inventory runs as a batch job and processes all online volumes, subsets of volumes may be selected via SYSIN, the process works as follows:

The VTOC is read for every volume, datasets are selected according to load module criterias, all extents of the selected datasets are scanned for copyright text, the text is saved. The member names are extracted from the directory and saved. The copyright text is sorted, eliminating duplicates. The copyright text is associated with the library name(s). The member names are associated with the library name(s). All DASD processing is done using Track oriented I/O, providing for excellent processing speed.

• Output is provided in three sequential datasets with
• Unique ID / Library Name,
• Unique ID / Copyright Text,
• Library Name / Member list

Chunk Management
The output datasets of the Inventory are usefully loaded into DBMS tables, enabling all kinds of queries. Together with the output from the P Tracker Program Usage Collector questions can be answered like: What program, application or module was never used within the observed time frame.

P Tracker allows to keep separate daily, weekly, monthly or yearly Collector data portions the so called chunks. P Tracker chunks can be further consolidated through selection of specific columns or accumulated by users, groups, departments. Pre-defined reports are available. It is also possible to directly load the collected data for further analysis and processing into tables of a relational DBMS, for example DB2.

License & Internal Software Asset Management (LIAM)
The usage frequency of applications is fundamental to License & Software Asset Management (LIAM). P Tracker’s monitor output contains all the modules called within a defined monitoring interval.

Other products try to match all the modules they find on your system to the names of modules in their knowledge-base. This approach rarely matches the correct release/version with your already identified software and certainly does not automatically match the modules to your vendor licenses or development or maintenance teams.
P Tracker does not deliver a knowledge-base or protected algorithms to determine which software you might have installed. It is our experience that licensed software or internal developments, often contain certain “notable modules” that are:

• unique to a product,
• to be present during a product’s ‘execution’,
• resident in test, QA and/or Production libraries

When talking about LIAM, most companies care little for reports on module usage. Instead, they prefer to focus on the frequency of usage of an application as a whole. This is where P Tracker’s design allows you to easily ascertain these critical LIAM objectives quickly and accurately.

Since software will, as a rule, consist of several hundred modules, which call one another, it will be necessary to define specific notable module(s) as the start or entry point to a product/application. A notable module will have to be registered as the one which, when it is called, will determine that the user has formally used the product/application. Sometimes there may be several such notable modules assigned to a product/application, namely when a product or application has several entry points.

Another important aspect in determining the usage level of a product will be the release and/or version. Often several versions of a product are in use in parallel, for any number of reasons:

• there are users who have chosen to use an older (free or a limited) version
• there are special versions for different user groups
• there are new version under test prior to promoting to production
• backups for special job runs, etc.

It is beneficial (financial implications) to take account of the different versions when determining the frequency of usage of a product within a articular license. To differentiate between the various versions it is necessary to note the library name as well as the name of the notable module when assigning it to a license.

Library naming conventions often lead us to determine easily the version & release of vendor and internal products whereby a VTOC listing will often quickly point out the installed product base.

Benefits & Savings
You can use the P Tracker reporter for selected summary and detail reports or use your own report generator program to extract the relevant information from P Tracker files. Immediate savings can be achieved through:

• Avoiding fees on unused or redundant products
• Redirecting manpower in maintaining in-house and external programs which are not used
• Analyzing product usage/redundancy prior to renewal/upgrade negotiations

Most program monitors are not suited for an ongoing deployment in a production environment, simply because of the unacceptable overhead they produce. Quite different with P Tracker, benchmarks show its efficiency, the burden is negligible as long as the tool is appropriately implemented.

Collection Control
After a predefinable interval, the collected program usage data (datasets containing raw collector data of a given time frame, for example a day, are called “chunks” ) are processed together by a post processing job. This job is submitted automatically by the P Tracker started task. It can be used as configured during the installation process or may be adapted to the different standards and conditions of the respective LPAR. Because the amount of collected data may be huge, P Tracker has a fast and powerful filter mechanism. This mechanism is executed before the data is written into P Trackers dataspaces. Using generic exclude/include lists the user can define which program names, libraries and jobnames are to be included and collected or which are to be excluded from the P Tracker process. The contents of these lists are saved with the P Tracker system log as they are initialized and should be retained for further reference.
In a post-processing control panel the user defines which data portions or “chunks” of the monitor raw data is to be held, i.e. daily, weekly, monthly and/or yearly. P Tracker’s reporter produces generic reports based on the selected chunks. The user chooses the desired fields, which are to appear as columns on a report from all those fields collected by P Tracker. Any sort sequence is user-defined as is the name of the report.

Storing the collected Data
The collected data can be stored in two ways. The data is by default kept in sequential datasets. Thus it is easy to migrate them using HSM. For users that are willing to do their own reports, the data may also be kept under DB2 or any other relational DBMS. Load/append of the sequential datasets to tables is simpe. This enables the user to easily setup and execute specific queries that best meet the individual needs.

Simulation Mode
To ease storage estimation for the chunk files, P Tracker may be executed in simulation mode. If P Tracker is running in simulation mode only the numbers of observed program calls are cumulated rather than the actual data is written out to P Tracker’s dataspaces.