| View previous topic :: View next topic |
| Author |
Message |
jim haire
Beginner
Joined: 30 Dec 2002
Posts: 140
Topics: 40
|
 Posted: Thu Aug 27, 2020 9:03 am Post subject: Ability to copy a dataset from DASD to VTS |
 |
|
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. |
|
| Back to top |
|
 |
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Thu Aug 27, 2020 12:17 pm Post subject: |
|
|
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.
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
jim haire
Beginner
Joined: 30 Dec 2002
Posts: 140
Topics: 40
|
| Posted: Thu Aug 27, 2020 12:45 pm Post subject: |
|
|
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! |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Thu Aug 27, 2020 12:51 pm Post subject: |
|
|
| 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?
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Thu Aug 27, 2020 12:57 pm Post subject: |
|
|
| 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.
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
jim haire
Beginner
Joined: 30 Dec 2002
Posts: 140
Topics: 40
|
| Posted: Thu Aug 27, 2020 1:42 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Thu Aug 27, 2020 1:47 pm Post subject: |
|
|
| 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
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
