Re: Identifying where *modules are used

I am a one-person shop with approx 30 users, and maybe 40% of my time satisfying the needs of 2 managers in particular.

Many years ago, long before me on 400, I had extensive programming standards, that evolved over time & as I learned more. Today I have some SEU/PDM "documents" with various directories of programming techniques, that point at various programs & query definitions.

If you have forgotten how to do string searching ... here's programs that do that, and queries (LIKE operation).
If you have forgotten how to sort output by absolute value ... here's how.
If it has been a while since you used RPG matching ... here's programs that do that.
The IBM manual has 3 ways to link files in query/400 ... here's a query definition that has figured out a 4th way.
If date-math bombs due to invalid date, reminder how to locate the responsible record.

The "doc" has both a brief explanation of the technique, and pointer to some software that is using that technique. The programming goals sorted by name of goal.

I came to AS/400 (I am on model 170 because of extortionist policies of SSA/Infor) via S/36 & AS/36. I can't remember name of company now (ASNA?) which provided a version of RPG to run on AS/36 that supplied many OS/400 techniques. The accompanying documentation was GREAT!, explaining many 400 programming techniques that were alien to people not yet on the 400, such as the advantages of external definition of files. If you did not have that on S/38 either, maybe some kind of documentation aimed at people in the transition from 38/36 to 400/i, might be worth getting.

We have many programs that started their life on S/36 & went thru a semi-automated program to be converted to run on AS/400.

The *OUTFILE from GO CMDREF includes lots of useful metrics, such as how heavily various programs are being used. If I want to improve the performance of some program, I would rather do it with programs used almost every day, than one used only once a month (except I have to do the end fiscal stuff, which in aggregate is like 15 hours if nothing goes wrong).

We have programs that take over 1 hour to run, that get run several times a day by different people. In the short term, I have put those tasks on GO CMDSCDE to run at 3 am, so that various users have the latest edition in their OUTQ when they show up for work in the morning. There has also been intermittent interest in having them arrive at printers, released to print, since some run to hundreds of pages.

In the longer term, there's discussion with users ... are you really using all 300 pages of this report? We have now coded customers etc. with the planner or customer service rep in charge of that stuff, then used that coding in reports to list only the activity of relevance to that planner.

About a year ago we got a new customer, which if all goes well will become our biggest customer. They have special needs, and people with an intense need to follow details on that customer much more intensely than we have with any others in the past.

So when I created versions of our standard reports to only show the stuff on that one customer, I also structured them, so that with minimal effort, we could also get the same stuff on some other customer, if that ever is called for.

I have had mixed success re-writing programs to go faster.

In the most spectacular case, the complaint was that every time a person presses enter key, they have to wait several minutes for the software to execute to the next screen. I fixed that to subsecond response time, by changing the file access methodology.

Thanks Scott and Al for your responses.

Before I came to my current shop, ILE was implemented half-heartedly - and
as a result we have a few monolithic ILE programs because those who
preceded me didn't do their homework. Some of the staff continue to think
they can write RPG as if it were RPG on a S38, and the maintenance of
these programs is (as you'd expect) quite challenging.

I'm trying to get the staff to recognize that just because we use CALLB,
CALLP, functions and CALLPRC we aren't truly utilizing ILE as intended if
we aren't being as modular/granular as possible (and other things). As a
result I'm in the process of establishing some best practices, standards,
new design testing and cleaning up and making our code base more
manageable and efficient.

So for analytical reasons I want to be able to look at a *MODULE object
and see where it is being used so I can see what objects are candidates
for re-engineering. The PDM option 25 is very cumbersome and that's why
I'm looking for a more efficient method of identification. My mantra to
my staff is that we don't need to get there tomorrow, but we do need to
get there eventually.

"However, I would recommend that you never bind the same module to more
than one program -- which makes this type of thing a non-issue."

I am curious as to why you say that Scott? In our case though this is
exactly what was done - rpg modules were created to perform edits, and/or
display panels for data entry and/or return values via export/import parms
and we have extensive use of prompt windows and processing panels that are
executed via callb - and it seems to have worked pretty well. Wouldn't
this (reuse of modules) be similar to say a service program being accessed
by more than one program?

The only problem (and I know this is why you and your peers recommend
avoiding this) is that when a modification is required to the module then
all the programs using it need to be recompiled (and I know that these
should be in a service program and accessed via prototyped calls). But we
can't just convert everything to service programs overnight for practical
reasons, so I'm left with trying to deal with the existing code.

"Even if you searched for all CALLB and all prototypes, you'd only have
found the RPG code. Now you'd have to also search for CALLPRC in CL, as
well as C/C++ prototypes, Cobol calls (sorry, I don't know the Cobol
syntax). "

Exactly - additional PDM option 25 runs. Hence my request for a better
method of finding what objects are used where.

Again, thanks for the replies!

Regards, Jerry

Gerald Kern - MIS Project Leader
Lotus Notes/Domino Administrator
IBM Certified RPG IV Developer
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623-4299
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx


This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please inform the
sender by reply e-mail and destroy this and all copies of this message.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.