MVSFORUMS.com :: View topic - Ability to copy a dataset from DASD to VTS

Ability to copy a dataset from DASD to VTS

through

[^/[Print]\]

MVSFORUMS.com -> TSO and ISPF

#1: Ability to copy a dataset from DASD to VTS Author: jim haire,

Posted: Thu Aug 27, 2020 9:03 am
—
Is it possible to copy a file from DASD to a virtual tape without having to specify the volume?

We don't know the format of the file on disk being read, but we would use the LISTDSI command to get that information about the file and then allocate the tape file using this information.

#2: Author: kolusu, Location: San Jose

Posted: Thu Aug 27, 2020 12:17 pm
—
jim haire,

Are you planning to use REXX or interactively to COPY? If you can run a batch job it is quite easy to copy without specifying the VOLUME. If you want efficiently use tapes, then may be you need to look into stacking.

#3: Author: jim haire,

Posted: Thu Aug 27, 2020 12:45 pm
—
Yes, they are trying to use REXX. These are rather large files, so in order to save disk space they decided to write to VTS.

They are using a batch REXX step because they don't know the name of the file coming in or the format. They are getting the file name from a dataset. The REXX program copies the data from disk to VTS using EXECIO DISKR and DISKW.

The allocation of the VTS as an output file is causing an issue. It sends an error which says that the VOLUME needs to be supplied. However, the volume of the VTS being written to is not known at that time. Is there a way to code the allocate to get around this issue?

Thanks Kolusu!

#4: Author: kolusu, Location: San Jose

Posted: Thu Aug 27, 2020 12:51 pm
—

jim haire wrote:

They are using a batch REXX step because they don't know the name of the file coming in or the format. They are getting the file name from a dataset. The REXX program copies the data from disk to VTS using EXECIO DISKR and DISKW.

Jim Haire,

That is one of the slowest way to copy a dataset. Since your goal is to eliminate DASD usage, I am guessing that these are huge files and using EXECIO DISKR and DISKW will take a long time.

You can generate the JCL in REXX and dynamically submit it. In that way you don't have to worry about VOLUMES.

Do you have an ACS routine which would do the allocation based on the UNIT parm in the JCL?

#5: Author: kolusu, Location: San Jose

Posted: Thu Aug 27, 2020 12:57 pm
—

jim haire wrote:

The allocation of the VTS as an output file is causing an issue. It sends an error which says that the VOLUME needs to be supplied. However, the volume of the VTS being written to is not known at that time. Is there a way to code the allocate to get around this issue?

Thanks Kolusu!

Jim Haire,

The error is due to the user NOT having MOUNT authority. So you probably need to have your sysadm to grant the authority to the TSO ID that is doing the COPY.

#6: Author: jim haire,

Posted: Thu Aug 27, 2020 1:42 pm
—
Thanks for the answers Kolusu.

I am helping someone resolve a problem with this issue. I will let them chase down whether they are allowed to generate dynamic JCL and submit it. I think this may be frowned upon in this shop because the scheduler will not have control of the job. I think there was discussion of writing jobs to the Internal Reader at one time and they didn't want to do that either, for the same reason.

I will make them aware of the mount authority and see if there is some way that could be given to the USER in the JCL.

#7: Author: kolusu, Location: San Jose

Posted: Thu Aug 27, 2020 1:47 pm
—

jim haire wrote:

I will make them aware of the mount authority and see if there is some way that could be given to the USER in the JCL.

Jim Haire,

The MOUNT authority needs to be grated to TSO Session and not JCL as REXX runs in the foreground and it is TSO who is making the call to allocate the dataset

MVSFORUMS.com -> TSO and ISPF

output generated using printer-friendly topic mod. All times are GMT - 5 Hours

Page 1 of 1