FTP VSAM Datasets and later retrieve them

dick scherrer · Posted: Fri Aug 30, 2013 9:56 pm

Hello,

A bit of history.

We are in the process of reducing our data center dasd charge. We have several thousand datasets that do not need to be online 24x7 (some are not needed at all and will be deleted). One way of reducing our dasd usage is to migrate things away from the mainframe. We are currently testing with a SAN. Amont other things, we want to be able to offload VSAM file and recall them - without doing anything but restore them.

Has anyone FTPed a vsam file to a Win-based server and successfully rerieved it? What i'm about to try is to simply FTP some VSAM and see if i can recall it successfully. If that can't be done, i'll try to back up the VSAM with DFDSS and see if this will go out & back.

Thoughts anyone?

Thanks

d

Robert Sample · Posted: Fri Aug 30, 2013 10:59 pm

dick scherrer · Posted: Sat Aug 31, 2013 12:07 am

Thanks Robert,

agkshirsagar · Posted: Sat Aug 31, 2013 12:51 am

Have you tried sending the dumped file in line mode using XMIT command?
I have done it for PDSs and not for VSAM but I think it is worth a try..

dick scherrer · Posted: Sat Aug 31, 2013 1:15 am

Have you sent your dumped file to a SAN usiong XMIT and successfully brought it back (and used it)?

I am in the process of automating this and i wonder how similar the processes will be. Our Operations are to run these batch retrievals "on request" and i want to be sure it is straight forward. The retrievals will be run off-shift when there are less people in the building and i surely do not want calls when there is confusion . . .

Thanks for the suggestion!

d

agkshirsagar · Posted: Tue Sep 03, 2013 7:21 pm

Hi Dick,
What I meant is use XMIT to convert the file to line mode and then FTP to SAN.

For PDSs, I do the XMIT to same node just to create one file out of multiple PDSs. Then FTP it to SAN/Windows shared drive and upload to the new environment. When I receive the file on new environment, all PDS definitions are created automatically. Much easier than dealing with individual members and PDSs. Picked up this trick from cbttape.

I guess it will not benefit you much for moving VSAMs.

expat · Posted: Wed Sep 04, 2013 12:41 pm

Dick, what about using HSM or the likes to migrate and recall as required.

dick scherrer · Posted: Wed Sep 04, 2013 7:08 pm

Hi Expat,

Thanks for the input

Their (our) current idea is to take these larger, seldom used files completely off the mainframe and bring them back when (if) needed. Lots of these files are written and then used once or twice immediately after creation. Then, never referenced again.

Even in HSM they take considerable space and the desire is to avoid as much ongoing mainframe DASD expense as possible.

There is a multi-terabyte SAN available that is basically "free" (less than $100 per terabyte) so it looks rather attractive . . .

expat · Posted: Wed Sep 04, 2013 7:42 pm

Dick, I was thinking of immediate ML2 migration to tape which is easily achieved with SMS and HSM

Also, with HSM the OS will know what's happening when the file is being restored and shouldn't have any adverse effect on the processing.

Do you envisage the "RECALL" process to be automated or manual ?

dick scherrer · Posted: Thu Sep 05, 2013 12:19 am

Hi Expat,

As much as possible, this will be automated. The way i'm implementing so far is that the IT person needing the offline data queues the dsn(s) of dataset(s) to be recalled from the SAN. This is a ROSCOE shop, so the processes are being written using RPFs rather than REXX.

Off-shift, the recall process will FTP the file back to the mainframe. If more than an FTP is needed, it will done after the FTP. For something urgent (not so likely as the offline data will be more than 1.5 years old (most more than 2 years).

If you think of some way i might step on my foot, please do advise