Re: Source Change Tracking/Dependencies -- MIDRANGE-L

My 2 cnts

We use (for 15 years I believe) a combination of :

a. nightly run of DSPPGMREF of all PGMs in a predefined list of Libraries
to create a table with PGM <-> Files dependencies and a table of inter
PGMs calls
(list of PGMs that call other PGMs and name of those called ,plus Menu
items as well)
b. FILESCAN CMD (invoked by programmers as needed) that takes a FILE (with
wildcard)
name and creates a list of PGMs/Modules/QRYs that use it.
c. COMPILE CMD that sequentially reads the PGMs/Modules list of step b,
displays it and lets the programmer compile it by hitting Enter.

This is an adaptation of an old freeware I have forgotten by whom.

d. homegrown "Pre/Post Compiler" that executes scripts embedded in the
source MBR
to perform pre-compile tasks (like creating a work file in QTEMP or
doing OVRDBF etc.)
and post-compile tasks (like re-creating PGMs after compiling a module
etc.)

HTH
Gad

date: Sat, 21 Jan 2023 20:46:52 -0800
from: x y <xy6581@xxxxxxxxx>
subject: Re: Source Change Tracking/Dependencies

I developed these tools on the System/38. Try running the commands below on
a single program and display file, then look at the OUTFILE's. You'll see
how everything fits together. With multiplier libraries, you'll have to
run these commands multiple times, once for each library. Your apps to
process these files must use qualified object names when linking DSPPGMREF
and DSPFD files.

It's very easy to build a tool that looks for level checks--use DSPFD to
get the PF/LF/DSPF file information and DSPPGMREF for the program
references. Then you read through the DSPPGMREF file, find the associated
file in the DSPFD file, and check the hash. If equal, you're good; if not,
you'll get a level check. FYI, my standard is simple: LVLCHK(*NO) =
today's your last day.
DSPPGMREF PGM(%SST(&PGMLIB 11 10)/%SST(&PGMLIB 1 10)) +

OUTPUT(*OUTFILE) OBJTYPE(*PGM *MODULE *SQLPKG +

*SRVPGM) OUTFILE(XXP727)

DSPFD FILE(%SST(&PGMLIB 11 10)/%SST(&PGMLIB 1 10)) +

TYPE(*RCDFMT) OUTPUT(*OUTFILE) OUTFILE(XXP728) +

OUTMBR(*FIRST *REPLACE)

Finding source and object out-of-sync is something you can do easily in
V4R5 (IIRC). The source library/file/member is stored in each OPM program
object and it's merely a matter of comparing the compile information to
what's in DSPFD *MBRLIST. If the source last changed date is greater than
the source reference timestamp in the object, the source has been changed
but not (successfully) recompiled. The ILE environment creates modules
first and link-edits them into programs, so accomplishing this result today
is more complex because (1) you could have multiple modules in a program
and (2) using API's a better way of doing this. In the contemporary
environment, I think you can do all of this through SQL's system files.

DSPOBJD +
OBJ(&OBJLIB/*ALL) OBJTYPE(*FILE *PGM *MODULE +
*SRVPGM *CMD) DETAIL(*SERVICE) +
OUTPUT(*OUTFILE) OUTFILE(XXP729) +
OUTMBR(*FIRST *ADD)
DSPFD +
FILE(&SRCLIB/&SRCFILE) TYPE(*MBR) +
OUTPUT(*OUTFILE) FILEATR(*PF) +
OUTFILE(XXP730) OUTMBR(*FIRST *ADD)

For both of these tools, I added features to recompile missing or
out-of-date objects. In the Dark Ages of pre-RISC, when compiles were
slow, I'd fire these off, go have a burger, and come back to fresh
compiles. The level-check code still works today and I still use it.

HTH.

On Sat, Jan 21, 2023 at 4:10 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello,

my projects slowly become more complex and I start to face "dependency
hell". This includes PFs in a library being referenced by *PGM and DSPF
objects in other libraries. When I change a field

I'm wondering which easy ways of source tracking are available directly

in

(older) versions of OS/400 (here: V4R5), *without* using MS Windows

based,

or other "external" development tools. I want to solely rely on OS

provided

facilities.

Note: I'm exclusively using DDS for creating PFs/LFs, no SQL. I don't see
benefits in doing so on V4R5.

I have noticed the "extended" PDM project management, but so far I failed
to find the nerves to look into what seems a highly complex mechanism.

I'm

also not sure if I can "import" already existing "projects" (aka:

libraries

with one SOURCES for all source members) into it. Also, this facility is

no

longer available in 7.2, as I've seen. (Some of my projects I'm using on
and developing on a 8203-E4A.)

I have read about TMAKE from QUSRTOOLS but so far no first-hand

experience

with it. I'm rather fluent with UNIX make and Makefiles, though.

Other thoughts from the group?

Thanks!

:wq! PoC

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

------------------------------

Subject: Digest Footer

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

------------------------------

End of MIDRANGE-L Digest, Vol 22, Issue 44
******************************************