Hi Bob,

A CPY* by means of a DDM will work fine and keep your date. You can also do a SAV* on the source member and FTP the *SAVF. That would also do the trick and you still get to FTP stuff!  :o)

Good luck,

Paulster

Found that out years ago. Never did much with DDM, so my solution was save and restore. OK, so you're thinking SAVOBJ to *SAVF, FTP (or whatever) the save file, then RSTOBJ, that's a lot of manual work.

If you install ObjectConnect (which is a free feature of OS, just not installed by default), you can use SAVRSTOBJ. The SAVRST* commands do all the grunt work under the covers, using SAVF in QTEMP. The gotcha is it's SNA; however, you can use HPR/IP (or older AnyNet), to take care of that. Still, would be nice if IBM came out with a version of ObjectConnect that worked over TCP/IP.

I know/knew about the Sav/Rst option of course via SAVF... that was my methodology for years. Sadly this shop is in rapid development, test, deploy everywhere, then "oh we also want this" mode.

Bruce Hoffman said ObjectConnect could work over IP, but maybe I misunderstood his suggestion, but yes, savrstobj would be my preferred technique. But I'm also looking for something we could use "today" until all systems are on compatible releases. We do have v5.2, v5.4 and v7.1 to deal with, and soon, some boxes will be on v6.1 so.... FTP is really the only good choice--either that or develop on the old v5r2 box and pump things upstream.

CPYF "knows" that PF-SRC it different from PF-DTA, so it only ever gives you the SRCDTA column. FTP does the same thing. Maybe a little programming that would "CPYF" to a flat file that includes all three PF-SRC columns? Then you could FTP the flat file and reverse it on the other end. But that's programming...

ObjectConnect works over IP if you configure using *HPRIP, which replaces AnyNet. But you can't SAVRST* between 7.1 and 5.2 any more than you can SAV* then RST*, so the question is moot.

Dale, right, that's why I suggested FTP is the only practical choice between these vast OS levels.

As for CPYF... There is the CPYSRCF command which I use instead of the CPYF command when copying source members. It is smarter and easier to use than CPYF in this context. Not sure if it would work over DDM because I often get messages when things need the file definitions, which (apparently) DDM doesn't provide.

CPYSRCF will work with a DDM file.  The command treats the DDM file as a local file, so whatever you can do between two local files, you can do between a local and a DDM file.

I'm not sure what you mean about things needing file definitions.

SQL and RUNQRY won't work with DDM files, as far as I can tell... at least not on v5.2

SQL is not designed to work with DDM - SQL lets you connect to the schema.  I've just not been inclined to look for a method to connect to 2 schema's so I can copy from one place to another place.

I thought QRY/400 worked with DDM - but maybe I was mistaken.

It looks like SQL will work with DDM files at v7.1 (at least it worked in STRSQL).  However, both boxes are at v7.1, so I'm not sure how it will react on different OS releases.

RUNQRY still does not work though.