Midrange News for the IBM i Community


Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Chicagoland
FTP Source Statement Change Dates Lost?
has no ratings.
Published: 24 Jan 2012
Revised: 23 Jan 2013 - 1523 days ago
Last viewed on: 25 Mar 2017 (3096 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.

FTP Source Statement Change Dates Lost? Published by: Bob Cozzi on 24 Jan 2012 view comments(9)

I'm FTP'ing a ton of source members, and loosing the source statement change dates.

I thought (hoped?) that using MODE = EBCDIC instead of BINARY would do the trick. Nope. Still Zeros-Out the SRCDAT field on the target.

Is there a work around that anyone knows of?

I've already thought of doing a DDM file transfer instead--build the DDM file on the fly and do a CPYSRCPF to the DDM file. I suppose I may have to live with FTP not transferring everything as it should.

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

COMMENTS

(Sign in to Post a Comment)
Posted by: Paulster
Premium member *
Sweden and The Netherlands
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 2 days 8 hours 3 minutes ago

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

Posted by: DaleB
Premium member *
Reading, PA
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 2 days 6 minutes ago

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.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 1 days 23 hours ago

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.

Posted by: DaleB
Premium member *
Reading, PA
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 1 days 21 hours 31 minutes ago

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.

 

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 1 days 21 hours 25 minutes ago

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.

Posted by: BrianR
Premium member *
Green Bay, WI
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 1 days 20 hours 30 minutes ago
Edited: Wed, 25 Jan, 2012 at 11:35:48 (1887 days ago)

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.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 1 days 19 hours 14 minutes ago

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

Posted by: neilrh
Premium member *
Jackson, MI
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 1 days 17 hours 52 minutes ago

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.

Posted by: BrianR
Premium member *
Green Bay, WI
Comment on: FTP Source Statement Change Dates Lost?
Posted: 5 years 2 months 1 days 17 hours 18 minutes ago

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.