Sitting Right There in Front of Us the Whole Time
This is one of those articles that I'm sure will (in all humility)
end up being paraphrased and plagiarized by other IBM i and RPG article
writers out there over the next few years. Have written about everything
imaginable on IBM i for 30 years, it is difficult not to see your own
work, re-worked and presented as if it were "new" by someone else. But
it happens, and today's RPG Report is no different.
I've authored a new software package called COZTOOLS ("Cozzi Tools")
that can be downloaded for free at
www.cozTools.com although it is in BETA until August, but its
already pretty solid and we've hit 2000 downloads so far. In building
this new licensed program, I needed a way to send source code between
multiple systems in order to test on v5.4, v6.1 and v7.2 release levels.
In fact, once we "discovered" the technique that is the focus of this
week's article, we were even able to test and build the package on our
old "just sitting there" v5.2 system.
Background
The primary need is moving source between systems. Of course FTP was
our first choice. We have that really cool FTPFILE command that I
published a few years back and have now included in COZTOOLS. This makes
it incredibly easy (almost too easy) to FTP source code or any file or
save file between IBM i systems. Therefore this was our first choice for
source deployment. But as you all probably know, using FTP on IBM i for
source code means you loose the source statement change dates. We really
needed to be able to preserve those change dates so we decided it was
time to write yet another tool.
The tool we initially wrote does the following, under the covers:
- Save the source file member to a save file
- FTP the save file using FTPFILE to the remote location
- Restore the save file to a new source file in the QTEMP library.
- Issue the CPYSRCF CL command to copy the source from QTEMP to
the target source file.
A pretty obviously, albeit tedious routine just to move source
to another system. The nice part is it works between any IBM i systems,
not just those "on your network". So (for example) I could send you 3
source members in QRPGLESRC in your library and those members would be
added/replaced and would include the source statement change dates.
You might ask "Why not just save the source file and members to a
save file, FTP the save file, and then do a direct restore?" While this
abbreviated process is substantially similar to the one above, it has its drawbacks. For example in one situation you could end up with
source file members renamed to XXX0000001 and in another situation, if
you have (for example) 789 source members in a source file and you
restore 2 source file members only, you could end up with the entire
file being replaced and end up with just the two source file members and
787 lost source members; yes it has happened to me. Therefore I did not
want to rely on effectively a save/restore of just a few source file
members.
A Better Solution: "Watson! Come here! I want you!"
Invention is a subjective term in the software industry and software
patents, to me, are unjust at best; to me it is like applying for a
Patent on something you've made out of plastic Legos® . So you know where
I'm coming from when I say "invent" I really mean discovery.
While testing the above mentioned COZTOOLS CL Command to transfer
source code, I needed to basically parallel routine using a different
methodology. As many of you know, I've been only recently using DDM
files in my work, and decided to use them to test our CPYSRCRMT
(COZTOOLS Copy Source File to Remote) CL Command. Meaning I would use
DDM to copy the source to another system and then use the CPYSRCRMT CL
command to see the results matched, and they did.
Then it occurred to me ("palm hits forehead") why not simply use DDM
and forget all that save/restore nonsense?
I did a test. running on our v5.4 system, I created a DDM file in
QTEMP (so it would vanish when I signed off) that pointed at the
QRPGLESRC source file in COZTOOLS on our main system. The command looked
like this:
CRTDDMF FILE(QTEMP/QRPGLESRC) RMTFILE(COZTOOLS/QRPGLESRC) RMTLOCNAME(cozzi720 *IP)
This created a DDM file that points at our system whose IP is in the
HOST table as COZZI720 (it is a model 720 running IBM i v7.1).
Next I issued the CPYSRCF command, copying the COZTOOLS DSPOBJLVL RPG
IV source member to the local v5.4 system for testing purposes:
CPYSRCF FROMFILE(QTEMP/QRPGLESRC) TOFILE(COZTOOLS/QRPGLESRC) FROMMBR(DSPOBJLVL)
The member is copied perfectly, all source statement change-dates and
sequence numbers are identical to the original source member. Everything
that CPYSRCF would normally do with a local-to-local source member copy,
it did with the DDM version of the copy. This is a crazy good
capability.
DDM Caveats
When using DDM between IBM i systems, the DDM TCP/IP Server Security
Settings have to match. I use Validate-Only, but there are others
depending on which version of IBM i you are running.
If you get an error, such as the following:
Authorization failure on DRDA/DDM TCP/IP connection attempt.
Cannot assign or release DDM file(s).
File QRPGLESRC in QTEMP not available.
This usually means that (A) your user profile does NOT exist on the
remote system, or (B) the DDM Security Settings are not compatible.
Assuming you have a remote user ID, check the DDM security settings
by running the CHGDDMTCPA (Change DDM TCP/IP Attributes) command. The
parameter in question is usually PWDRQD (password requirement) and needs
to be a compatible setting on all the systems involved in your DDM file
usage. This isn't
new or exclusive to using CPYSRCF but if this is the first/only time
you're using DDM, it may be something was overlooked. I tend to use
PWDRQD(*VLDONLY) on all my systems. This seems to work well, but your
own security needs/issues apply when making the right choice for
your location.
Also, make sure the DDM server is started automatically when the
system is started, by specifying AUTOSTART(*YES) on the CHGDDMTCPA
command. If it isn't already started now, you can issue the STRTCPSVR
SERVER(*DDM) command to start it and then use CHGDDMTCPA
AUTOSTART(*YES) so it starts automatically in the future.
Lastly, remember that the DSPDDMF (Display DDM File) CL command shows
you what remote file is being accessed when using the local DDM file.
This will tell you, in the context of CPYSRCF, where the remote source
file is located.
Cozzi Tools 2012 - Beta 2
Cozzi Tools 2012 is available now on
www.cozTools.com Watch midrangeNews.com for
updates and documentation on COZTOOLS. Visit the
COZTOOLS website for the latest
information; and remember to tell your friends about this free tools
library.
Call Me
Bob Cozzi is a technical advisor to IBM i clients around the world.
His specialty is solving difficult problems for his clients, training their
programming staffs, and performing system migration/upgrades for small shops. His
consulting rates are available
online. To contact Bob,
send an email to: bob at rpgworld.com
You can subscribe to RPG Report (we call it "follow") by
visiting the RPG Report
page
on midrangeNews.com and then click the FOLLOW link in the table of contents
for that
page. To unsubscribe, simply click that same link. You must be
signed up and signed
in to midrangeNews.com to start following RPG Report.
Follow Bob Cozzi on Twitter
