Midrange News for the IBM i Community

Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
RPG Report 2012
has no ratings.
Published: 15 May 2012
Revised: 30 Sep 2014 - 2920 days ago
Last viewed on: 28 Sep 2022 (3056 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

RPG Report - 15 MAY 2012 Published by: Bob Cozzi on 15 May 2012 view comments

© Robert Cozzi, Jr. All rights reserved. Reproduction/Redistribution prohibited.
A midrangeNews.com Publication

Copying Source Between Systems without FTP

 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.


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:

  1. Save the source file member to a save file
  2. FTP the save file using FTPFILE to the remote location
  3. Restore the save file to a new source file in the QTEMP library.
  4. 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:


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:


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

Return to midrangenews.com home page.
Sort Ascend | Descend