Scribd
Upload
48 views

TechTip - Analyze Your Programs and Applications, Part II - System Administration - IT Infrastructure

This document discusses analyzing programs and applications on IBM i systems. It provides examples of SQL queries that can be run to gather various types of useful information from the system, such as counting objects by type, year, compiler, library, and owner. This information can help ensure applications can run on different system versions and that source code and object dates are consistent. The document emphasizes using multiple system commands like DSPOBJD and DSPFD together with SQL for a comprehensive analysis.

Uploaded by

Johnny SaysBlowme
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
48 views

TechTip - Analyze Your Programs and Applications, Part II - System Administration - IT Infrastructure

This document discusses analyzing programs and applications on IBM i systems. It provides examples of SQL queries that can be run to gather various types of useful information from the system, such as counting objects by type, year, compiler, library, and owner. This information can help ensure applications can run on different system versions and that source code and object dates are consistent. The document emphasizes using multiple system commands like DSPOBJD and DSPFD together with SQL for a comprehensive analysis.

Uploaded by

Johnny SaysBlowme
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

YOU ARE HERE:  

HOME IT INFRASTRUCTURE SYSTEM ADMINISTRATION TECHTIP: ANALYZE YOUR PROGRAMS AND APPLICATIONS, PART II

TechTip: Analyze Your Programs and


Applications, Part II
JEAN-PAUL LAMONTRE / 02 FEBRUARY 2012

TOOLS

  PRINT   EMAIL

The rst part of this article series showed how DSPOBJD can easily provide statistics to
manage a general recompilation project. But it only touched the surface of all the things you
get with the DSPxxx commands.

Let's start with a review of the information we gathered in Part I by just using DSPOBJD.

Objects by Type and Year


This data is concerned with counting objects by type and by year of source update (for those that
have a source, of course).

If we had used ODCCEN plus ODCDAT (i.e., the object creation date) instead of ODSRCC plus
ODSRCD, we'd have gotten a report on recompilation instead of a report on source update.

with stat as (SELECT ODOBTP "Type" , odobat "Attribut", trim(char(


ODSRCC+ 19)) concat substr(ODSRCD , 1 , 2) "Year" FROM jpltools.objs
where odsrcc <> '') select "Year" ,"Type" , "Attribut", count(*)
Number from stat group by "Type" , "Attribut", "Year" order by
"Year","Type" , "Attribut" 

 
Figure 1: Here's the list of objects by type and year.

The code below counts programs (in fact, programs and modules, to also take care of ILE
objects) by compiler. Note that objects without source are eliminated by the WHERE clause.

SELECT odobat "Attribut" , count(*) Number FROM jpltools.objs where


odsrcc <> '' and ODOBTP in('*PGM', '*MODULE') group by odobat order
by odobat

Figure 2: The programs are counted by compiler type.

There are two OPM programs in the libraries analyzed: one CLP and one RPG. But this analysis
doesn't show whether the ILE programs use the ILE default activation group or a speci c
activation group. This information is provided by DSPPGM, which does not offer an output le. In
the third part of this series, we will use the program description APIs for this information.  

Sources in Library
The following SQL will reveal the number of instances of source code per library.

select count(*) number, ODSRCL srclib FROM jpltools.objs group by


ODSRCL

 
 

Figure 3: JPLTOOLS has 70 source les.

Old applications may have had their libraries of code renamed many times and can show traces
of these old libraries' names, so this list can be overwhelming. There are often names of libraries
that no longer exist. This does not mean that the source code is lost, but it would be wise to
check that the available source code has the same date indicated in the object.

Sources (aka File Members) per File


The following code will show you the number of instances of source code per le. Note that the
objects without source are eliminated by the WHERE clause.

select count(*) number, ODSRCF srcpf FROM jpltools.objs where ODSRCF


<> '' group by ODSRCF order by number desc

Figure 4: Here's the number of instances of source code per le.

Much less often than in the list per library, this list can show source le names that have
disappeared ... or should have disappeared.

Objects by Version
In a complex environment, it is common to have multiple machines with different version levels.
This analysis ensures that the application can be used on a machine that is not yet at the latest
version level.

SELECT count(*)number , ODcpvr i5os FROM jpltools.objs where odobtp in


('*PGM','*SRVPGM') group by odcpvr order by i5os
 

Figure 5: Objects are shown by version.

              

Here, the objects are all compiled for V7.1. Installation on a machine running an older version will
require a recompilation. Sometimes, problems can appear if one or more programs use speci c
features of V7.1.

Note: In the case of JPLTOOLS, the question does not arise since I offer only the source code. And
the JPLTOOLS code is backward-compatible until V5.4.

Objects by Owner
Is management of the owners being done correctly? DSPOBJD gives no information on adoption
of rights. We will use the program description APIs for this information.

SELECT count(*)number , ODobow owner FROM jpltools.objs group by


odobow

Figure 6: Objects are shown by owner.

Ha! I have to make corrections.

All the above information was obtained only by using the result of DSPOBJD. Now we will extend
our investigations to other commands.  We'll use SQL to mix the results provided.

Check the Date of the Source Code


The target of this analysis is to check that the source has not changed since last compilation.

Obviously, this runs only for programs built with a module of same name. By doing this, I'll
arti cially create a link between the source member and the program. In fact, when context is
more complex than a source producing a module producing a program, I will need a true link
between these three elements. APIs provide this information . I will return to that point later.

How do I do it? Run a DSPFD MBRLIST and join!

DSPFD FILE(JPLTOOLS/*ALL)
TYPE(*MBRLIST) OUTPUT(*OUTFILE) FILEATR(*PF)

OUTFILE(JPLTOOLS/MBRLIST)

OK, but this list contains members of all les: PF-DTA and PF-SRC.

To keep only the membership list of source les, retrieve the attributes of all les: 

DSPFD FILE(JPLTOOLS/*ALL) TYPE(*ATR) OUTPUT(*OUTFILE) FILEATR(*PF)

OUTFILE(JPLTOOLS/FD_ATR)

Then, isolate the source lenames:

SELECT PHFILE FROM JPLTOOLS.FD_ATR WHERE PHDTAT='S'

Keep only the members of the source les:

DELETE FROM JPLTOOLS.MBRLIST WHERE MLFILE NOT IN (SELECT PHFILE FROM


JPLTOOLS.FD_ATR WHERE PHDTAT='S')

Reminder: DSPOBJD gives us the exact date of the source code when compiling the module.
DSPFD MBRLIST gives us the exact date of last modi cation of the source code.

The next step is to simplify reading of DSPFD-MBRLIST. For the modi cation date of the source
code, use this code:

SELECT MLNAME, case when MLCHGc = '' then ' ' else trim(char( MLCHGC+
19)) concat MLCHGD concat '-' concat MLCHGt end Upddate,MLMTXT FROM
jpltools.mbrlist WHERE MLCHGc <> ''              

Figure 7: Simplify the reading of DSPFD-MBRLIST. (Click images to enlarge.)

You might also like