Hello,
thank you for your extensive description!
Am 22.01.2023 um 05:46 schrieb x y <xy6581@xxxxxxxxx>:
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.
Thanks! As I've mentioned to Roger, this is more or less what RBLDBF does. Something I'll keep in mind.
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.
Level Checks are only part of the challenge. There are also code source members, (probably modules,) and (service) programs to be considered.
Finding source and object out-of-sync is something you can do easily in V4R5 (IIRC).
Indeed, but your suggestions more or less boil down to "roll your own". While I've not ruled that solution out, I'm reluctant to add yet another project to my seemingly endless chain of dependencies to eventually reach an initial goal. :-) Maybe you know this kind of grinding.
For both of these tools, I added features to recompile missing or out-of-date objects.
A must, for program 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.
:-)
Meanwhile, I had a closer look at TMKMAKE from QUSRTOOL. I've created my first OS/400 Makefile for a simple project and learned some things along the way.
The documentation section of QATTINFO/TMKINFO showing examples how to refer to objects is partly incorrect. The only working example was LIBRARY/MEMBER.FILE. Contrary to what I'm used from FTP, btw. The more "mainframe" like LIBRARY/FILE(MBR) didn't work for me. I probably should compare the source code of the V4R5 and 7.2 provided parts if this was fixed meanwhile.
The expansion variable $@ doesn't work as I'd expect. It seems to be expanded to '$@) TYPE(*' which is an error for the target string in CRTxx commands. Sadly I thus need to reference each and every target in the command line again.
@ was shown as § on my terminal for QATTINFO MBRs. I checked and saw that the PF has been created with CCSID 273, the default for my German language system. Apparently the *content* is in US encoding (037). Apparently an installation routine bug. Running
CHGSRCPF FILE(QUSRTOOL/QATTINFO) CCSID(037)
fixed that.
For increased comfiness, I issued
CHGCMDDFT CMD(TMKMAKE) NEWDFT('SRCFILE(*CURLIB/SOURCES) SRCMBR(MAKEFILE)')
I'm *always* using "SOURCES" for containing all source MBRs in my projects, and — like it is on Linux — a make "script" is most often named Makefile. So, I just need to chgcurlib to the project library and issue a "tmkmake". Very nice!
For the interested, here is my "simple" Makefile:
https://github.com/PoC-dev/asterisk-translate-clid/blob/main/Makefile
A trick I have come up with is dependency tracking of data files (PFs, LFs). Problem is that according to the documentation, TMKMAKE tracks the modification date of objects. If you insert a record in a PF, the modification date of the PF itself is changed. I've not checked but assigned LFs should also be changed, because to my understanding, they contain "data being copied in part from the PF" — to build an index or a view or whatever.
For this dependency tracking I assume a SRC PF named BLDTMSTMPS. If the dependecy checking of TMKMAKE decides that a MBR of BLDTMSTMPS isn't there or older than the accompanying source member, the PF is updated, LFs are recreated and the tracking member is removed and re-added to obtain a new modification timestamp. Crude, but it works well. (The - in front of the RMVM makes TMKMAKE ignore errors, e. g. if the member has not yet been added on a first run.)
Is there a CL equivalent to the Linux "touch" command, to update a file( MBR)'s timestamp? I don't want to call QSH for doing this, it adds considerable processing overhead on my 150. :-)
So far, TMKMAKE seems to be a good match for my workflow. I'm used to it from Linux and the inconveniences described above are minor. Thus: Thanks to everyone for their input!
:wq! PoC
midrange.com
