Re: DFDSS RFE - Please read / vote

[Seymour J Metz]

You didn't write that thy have unique names.






-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Monday, October 16, 2023 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS RFE - Please read / vote

On Sun, 15 Oct 2023 13:47:39 +, Seymour J Metz  wrote:

>You might consider an alternate deployment strategy
>
>* A target and dlib zone for each IPL volume.
>* Secondary res volsers based on IPL volser
>* Symbols based on IPL volser
>* File system names based on  IPL volser
>* Data set names on other than target or dlib based on IPL volser
>* Indirect cataloging.
>* LOADxx and IEASYMxx for above
>
>Having unique names for the data sets off the res volumes should resolve your 
>ENQ issue.
>

Re-read what I wrote.   These are sysres datasets, indirectly catalogged.  No 
different
than SYS1.LINKLIB except they are not part of the OS.

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: 
http://secure-web.cisco.com/19zitwfINAm6vRlxP67zogOmf2dWvKOmWpXPKyjxpJJEdXNQF2bbNrhsrFANQKV4YnHgdwMh7Q_0dhAV-W81EmJAzDHgK1GjSkpOefK7VB77dG8oFB2TUq9kvS6eRMbm-sDk_EYMcO8GxmxBaSbpkcfKoqkU8qT9eYHVgsEf50_VV5Uvg8Z8A9eO_lUhNkUuDmT0cQ0ZGW4iRPafCV4ZuYnqfp13PD8RmOq72brRSuaX-mGCbvTb-waRltiBmkJj6fxIr-De021iVECgZfH2602Ut13mh8mPxqLmpkK37s32l9-iv53ka0ysaZkVhVhE1HnqYEyOjbqx4CFEmaISlUjObiBpo5mLwHVDM6ZmT4UJ5vfeu-6gHgnky2TDMiSoyBz9K1D5u9X3wD8iBOen3qRPlAP0vJnhPLOv0Bd3WIlA/http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Mark Zelden]

On Mon, 16 Oct 2023 17:38:09 +, Art Zeigler  wrote:

>ISPF 3.4 lets you work with a dataset if is on a volume where it is NOT 
>allocated, and you allow the override to let you process with the action you 
>want to take. Of course, you need the right RACF security.  I think this is 
>what is needed in DF/DSS as well.  If you want to dump a dataset with an ENQ, 
>but the dataset is not on the volume where the ENQ originates from, then dump 
>the file.  This should not cause any problems.
>

I already mentioned this in the first post and that's what's being done now.  
This is a large environment... many sysplexes and lots of very junior people 
supporting it.  I'm concerned about someone making a mistake and forgetting to 
put the volser on ISPF 3.4 and deleting a live dataset in the LNKST, in use by 
TSO/ISPF or an STC.

BTW, I don't think people can see all the text in the RFE (even though I put in 
my first post).  You can also read my comments though.

https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Art Zeigler]

ISPF 3.4 lets you work with a dataset if is on a volume where it is NOT 
allocated, and you allow the override to let you process with the action you 
want to take. Of course, you need the right RACF security.  I think this is 
what is needed in DF/DSS as well.  If you want to dump a dataset with an ENQ, 
but the dataset is not on the volume where the ENQ originates from, then dump 
the file.  This should not cause any problems.

Art Zeigler



From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Monday, October 16, 2023 1:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: DFDSS RFE - Please read / vote

On Sun, 15 Oct 2023 12:24:35 +, Peter Relson  wrote:

>
>If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to 
>being in the LNKLST on the driving system), you get this error:
>
>ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
>DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON
>CODE IS FP-007
>
>
>
>I will leave the substantive issues to those who know DFDSS, but I trust that 
>it is understood that if this is related to the ENQ obtained by allocation 
>(the SYSDSN ENQ, obtained shared for DISP=SHR, exclusive for DISP=OLD (in this 
>case DFDSS might want DISP=OLD), this is the way z/OS works. Whether you like 
>it or not, the SYSDSN ENQ RNAME does not include the volume ID; in general, 
>that could not be changed compatibly.
>
>And that is why, for example, dynamic LNKLST provides its LNKLST 
>UNALLOCATE/ALLOCATE functions (intended to be used only for this sort of 
>situation) to un-do (and later re-do) the allocations it has put in place to 
>protect you from deleting the data sets in the LNKLST. Once those allocations 
>are undone, you can deal with an uncataloged data set of the same name as a 
>data set in the LNKLST.
>Peter Relson
>z/OS Core Technology Design
>

Yes, that could be done. I also mentioned that work around to some people at the
shop.But taking the entire LNKLST ENQ away from 9 systems in the
sysplex just to copy the product to the "ISV sysres", even for a few minutes, 
is worse than
letting it fail and renaming the lib / deleting it with ISPF (at least in my 
view).   Of course
we can plan and re-name / delete ahead of time or use other tools I have to do 
that
all in batch before the copy.   I've just never needed to do this with FDR for 
over 30 years
of having ISV datasets (or IBM program products) as an extension of the sysres 
set.
Hence the RFE.  I don't know what FDR does behind the scenes to accomplish this,
but it does without any issue.

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Jousma, David]

I did read that Mark, but didn’t provide enough detail., or skimmed over it.   
So, for my ISV extension volume a few things occur at the beginning of 
maintenance rollout time:


  1.  All ISV products get maintained via vendor provided processes with 
datasets that contain a ver/release qualifier
  2.  Clone old master volume to new master volume as new baseline
  3.  When cloning updated ISV libraries to master, the datasets get scratched 
via IEHPROGM on the new master volume, and then updated libraries are copied 
with RENAMEU to remove the ver/release info.
  4.  FDREPORT job is run to generate/re-generate indirect catalog entries (to 
pickup any possibly new datasets that were added), and IDCAMS step to create.

TOL(ENQF) is honored for both source and target datasets with a few exceptions 
(mostly for the things you mentioned already, reallocating, etc).

COPY DS(INC(SYSV.IDP.FDREPORT.V5490SP2.CLIST)) -
 RENUNC((SYSV.IDP.FDREPORT.V5490SP2.CLIST, -
 SYSV.IDP.FDREPORT.CLIST)) -
 LIDY(VND005) ODY(VSM02A) BYPASSACS(**) NSC REPLACEU -
 ALLDATA(*) TOL(ENQF) SPHERE ALLX SHARE

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Date: Monday, October 16, 2023 at 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: DFDSS RFE - Please read / vote
On Sun, 15 Oct 2023 00: 31: 20 +, Jousma, David  
wrote: >Mark, > >I have the same cloning process as you logically. I know 
exactly the problem you face. Your rfe makes sense. > >I get around it by


On Sun, 15 Oct 2023 00:31:20 +, Jousma, David  wrote:



>Mark,

>

>I have the same cloning process as you logically.   I know exactly the problem 
>you face.   Your rfe makes sense.

>

>I get around it by cloning at the volume level, but there is always the 
>outlier that needs to be cloned by itself, or the once in awhile fix that 
>needs to be made.When I run into that I either rename then delete the 
>enqueued dataset via ispf, and then reload, or if the dataset is actually in 
>use validly, I use idcams to delete all members, compress, then reload via 
>iebcopy.

>



Re-read what I wrote though.  I have no problem cloning the sysres set since 
that is also done on the volume level.  The problem is ISV or IBM program 
products that get "added" to the maintenance sysres in preparation for cloning. 
 Around 40 different products that get copied to the volume at any given time 
after maintenance to one of those products.  Then I clone the IBM sysres 
volumes and the program product volumes as one set using full volume copies 
(except for zFS files that are logically copied and have the sysres name as 
part of the dataset name).





Best Regards,



Mark

--

Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS

ITIL v3 Foundation Certified

mailto:m...@mzelden.com

Mark's MVS Utilities: 
https://urldefense.com/v3/__http://www.mzelden.com/mvsutil.html__;!!MwwqYLOC6b6whF7V!l5PVMhb0Ho14o2qfG-4mGoh8trURMMwWV_3J4TJPFXbbuOn6CL5M0mzwZaqcjU4LMJ1WEu-fzBOtjPk$<https://urldefense.com/v3/__http:/www.mzelden.com/mvsutil.html__;!!MwwqYLOC6b6whF7V!l5PVMhb0Ho14o2qfG-4mGoh8trURMMwWV_3J4TJPFXbbuOn6CL5M0mzwZaqcjU4LMJ1WEu-fzBOtjPk$>



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Mark Zelden]

On Sun, 15 Oct 2023 12:24:35 +, Peter Relson  wrote:

>
>If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to 
>being in the LNKLST on the driving system), you get this error:
>
>ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
>DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON
>CODE IS FP-007
>
>
>
>I will leave the substantive issues to those who know DFDSS, but I trust that 
>it is understood that if this is related to the ENQ obtained by allocation 
>(the SYSDSN ENQ, obtained shared for DISP=SHR, exclusive for DISP=OLD (in this 
>case DFDSS might want DISP=OLD), this is the way z/OS works. Whether you like 
>it or not, the SYSDSN ENQ RNAME does not include the volume ID; in general, 
>that could not be changed compatibly.
>
>And that is why, for example, dynamic LNKLST provides its LNKLST 
>UNALLOCATE/ALLOCATE functions (intended to be used only for this sort of 
>situation) to un-do (and later re-do) the allocations it has put in place to 
>protect you from deleting the data sets in the LNKLST. Once those allocations 
>are undone, you can deal with an uncataloged data set of the same name as a 
>data set in the LNKLST.
>Peter Relson
>z/OS Core Technology Design
>

Yes, that could be done. I also mentioned that work around to some people at the
shop.But taking the entire LNKLST ENQ away from 9 systems in the
sysplex just to copy the product to the "ISV sysres", even for a few minutes, 
is worse than
letting it fail and renaming the lib / deleting it with ISPF (at least in my 
view).   Of course
we can plan and re-name / delete ahead of time or use other tools I have to do 
that
all in batch before the copy.   I've just never needed to do this with FDR for 
over 30 years
of having ISV datasets (or IBM program products) as an extension of the sysres 
set. 
Hence the RFE.  I don't know what FDR does behind the scenes to accomplish this,
but it does without any issue.   

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Mark Zelden]

On Sun, 15 Oct 2023 13:47:39 +, Seymour J Metz  wrote:

>You might consider an alternate deployment strategy
>
>* A target and dlib zone for each IPL volume.
>* Secondary res volsers based on IPL volser
>* Symbols based on IPL volser
>* File system names based on  IPL volser
>* Data set names on other than target or dlib based on IPL volser
>* Indirect cataloging.
>* LOADxx and IEASYMxx for above
>
>Having unique names for the data sets off the res volumes should resolve your 
>ENQ issue.
>

Re-read what I wrote.   These are sysres datasets, indirectly catalogged.  No 
different
than SYS1.LINKLIB except they are not part of the OS.

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Mark Zelden]

On Sun, 15 Oct 2023 00:31:20 +, Jousma, David  wrote:

>Mark,
>
>I have the same cloning process as you logically.   I know exactly the problem 
>you face.   Your rfe makes sense.
>
>I get around it by cloning at the volume level, but there is always the 
>outlier that needs to be cloned by itself, or the once in awhile fix that 
>needs to be made.When I run into that I either rename then delete the 
>enqueued dataset via ispf, and then reload, or if the dataset is actually in 
>use validly, I use idcams to delete all members, compress, then reload via 
>iebcopy.
>

Re-read what I wrote though.  I have no problem cloning the sysres set since 
that is also done on the volume level.  The problem is ISV or IBM program 
products that get "added" to the maintenance sysres in preparation for cloning. 
 Around 40 different products that get copied to the volume at any given time 
after maintenance to one of those products.  Then I clone the IBM sysres 
volumes and the program product volumes as one set using full volume copies 
(except for zFS files that are logically copied and have the sysres name as 
part of the dataset name).  


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Seymour J Metz]

You might consider an alternate deployment strategy

* A target and dlib zone for each IPL volume.
* Secondary res volsers based on IPL volser
* Symbols based on IPL volser
* File system names based on  IPL volser
* Data set names on other than target or dlib based on IPL volser
* Indirect cataloging.
* LOADxx and IEASYMxx for above

Having unique names for the data sets off the res volumes should resolve your 
ENQ issue.





--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Friday, October 13, 2023 10:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS RFE - Please read / vote

On Fri, 13 Oct 2023 15:31:42 -0500, Mark Zelden  wrote:

I've had some offline responses also. Including the suggestion to use 
TOLERATE(ENQFAILURE)
 which only applies to the input dataset.  Let me explain again and show all 
the DFDSS control cards.

I have an "program products" sysres that is an extension of IBM OS sysres. 
There is a maintenance
version of that sysres, just like you have a maintenance IBM sysres that you 
apply SMP/E maintenance
to.  The PP sysres gets cloned along with the IBM sysres via full volume disk 
to disk copies. That is not
a problem.

That program products sysres (really 2 3390-27 volumes) has perhaps 40 IBM / 
ISV products.
All the datasets are indirectly catalogued via   Program product SMP/E 
target libs are copied
(and renamed during the copy) to the PP maintenance sysres at various time.  
When maintenance
for any give product is applied (or an upgrade) and is ready to roll out the 
sysprog copies
the SMP/E targets to this maintenance sysres.  So think of it as a volume were 
changes are staged for
production.  Then after cloning, the changes are rolled out as a package, be it 
with IBM OS maintenance,
one product, several products, or any combination like that.   This is done via 
rolling IPLs in
a sysplex environment so as not to cause any application outages (usually half 
the LPARs one
month, the other half the next month).   Almost every product's main loadlib is 
in the LNKLST - at
least anything that has associated production JCL, TSO CLISTs / EXECs, ISPxLIBs 
etc.  If something is only
used by an STC, it may not be in the LNKLST. This is to shield anyone from 
having to make
JCL changes etc. (pretty standard stuff, right?).

So many of these datasets being "staged" prior to cloning are ENQed.  If the 
input library
in the copy is larger than the one on the maintenance sysres volume, that is 
when DFDSS
fails.  If it doesn't have to scratch / reallocate the dataset that already 
exists to make it
larger to accommodate the input data set size,  it works fine.

Here is a sample of the copy process with DFDSS, only there would be many more
libraries copied / renamed than just a single one for almost all products.  
(another shortcoming
of DFDSS compared to FDRCOPY where only the HLQ can be renamed and FDRCOPY can
rename the hlq plus add / remove nodes for multiple datasets - dozens if I 
needed,  in a single
control statement, but I digress...)

//SYSINDD  *
 COPY DS( -
   INCLUDE( -
smphlq.product.V6R3.LINKLIB -
   )  -
)  -
  RENAMEU( -
   (smphlq.product.V6R3.LINKLIB -
  prodhlq.product.LINKLIB)-
 ) -
  SHARE TOL(ENQF)   PROCESS(SYS1) -
  BYPASSACS(**)   -
  NULLSTORCLAS-
  LIDY(inpvol)-
  OUTDYNAM(outvol,SYSALLDA)   -
  REPLACEUNCONDITIONAL -
  WAIT(2,2)  ALLDATA(*)  ALLEXCP
/*

If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to 
being in the LNKLST on the driving system), you get this error:

ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON
CODE IS FP-007

ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET


** VOTE here by clicking the vote icon at the top left!
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862

Regards,  Mark

>Sorry for top posting...
>
>Let's address your comments one keyword at a time:
>
>DELETE - deletes the source (input) dataset.  Ouch!  Lets not delete my SMP/E 
>target libs during copy to my sysres set please!
>
>PURGE -  overlays an output dataset that has an expiration date not yet 
>reached.  Not applicable.
>
>UNCOND -  no such parm or abbreviation.  I assume you mean 
>replaceunconditional, and that is already being done and doesn't matter.
>
>The deficiency is DADSM.  This is how DFSMSdss is handling this scenaro (it 
>attempts to scratch the DSN to reallocate a bigger dsn on copy if required).  
>DADSM can't scratch the DSN because the DSN is ENQ'd.
>
>ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
>DATA SET SYNCSORT.SYNCLINK. RETURN CODE IS 102, REASON
>CODE IS FP-

Re: DFDSS RFE - Please read / vote

[Peter Relson]

If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to 
being in the LNKLST on the driving system), you get this error:

ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON
CODE IS FP-007



I will leave the substantive issues to those who know DFDSS, but I trust that 
it is understood that if this is related to the ENQ obtained by allocation (the 
SYSDSN ENQ, obtained shared for DISP=SHR, exclusive for DISP=OLD (in this case 
DFDSS might want DISP=OLD), this is the way z/OS works. Whether you like it or 
not, the SYSDSN ENQ RNAME does not include the volume ID; in general, that 
could not be changed compatibly.

And that is why, for example, dynamic LNKLST provides its LNKLST 
UNALLOCATE/ALLOCATE functions (intended to be used only for this sort of 
situation) to un-do (and later re-do) the allocations it has put in place to 
protect you from deleting the data sets in the LNKLST. Once those allocations 
are undone, you can deal with an uncataloged data set of the same name as a 
data set in the LNKLST.
Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS RFE - Please read / vote

[Jousma, David]

Mark,

I have the same cloning process as you logically.   I know exactly the problem 
you face.   Your rfe makes sense.

I get around it by cloning at the volume level, but there is always the outlier 
that needs to be cloned by itself, or the once in awhile fix that needs to be 
made.When I run into that I either rename then delete the enqueued dataset 
via ispf, and then reload, or if the dataset is actually in use validly, I use 
idcams to delete all members, compress, then reload via iebcopy.

There is a restore with tol(enqf) I believe too.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Friday, October 13, 2023 10:55:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: DFDSS RFE - Please read / vote

On Fri, 13 Oct 2023 15: 31: 42 -0500, Mark Zelden  wrote: 
I've had some offline responses also. Including the suggestion to use 
TOLERATE(ENQFAILURE) which only applies to the input dataset. Let me explain 
again and show


On Fri, 13 Oct 2023 15:31:42 -0500, Mark Zelden  wrote:

I've had some offline responses also. Including the suggestion to use 
TOLERATE(ENQFAILURE)
 which only applies to the input dataset.  Let me explain again and show all 
the DFDSS control cards.

I have an "program products" sysres that is an extension of IBM OS sysres. 
There is a maintenance
version of that sysres, just like you have a maintenance IBM sysres that you 
apply SMP/E maintenance
to.  The PP sysres gets cloned along with the IBM sysres via full volume disk 
to disk copies. That is not
a problem.

That program products sysres (really 2 3390-27 volumes) has perhaps 40 IBM / 
ISV products.
All the datasets are indirectly catalogued via   Program product SMP/E 
target libs are copied
(and renamed during the copy) to the PP maintenance sysres at various time.  
When maintenance
for any give product is applied (or an upgrade) and is ready to roll out the 
sysprog copies
the SMP/E targets to this maintenance sysres.  So think of it as a volume were 
changes are staged for
production.  Then after cloning, the changes are rolled out as a package, be it 
with IBM OS maintenance,
one product, several products, or any combination like that.   This is done via 
rolling IPLs in
a sysplex environment so as not to cause any application outages (usually half 
the LPARs one
month, the other half the next month).   Almost every product's main loadlib is 
in the LNKLST - at
least anything that has associated production JCL, TSO CLISTs / EXECs, ISPxLIBs 
etc.  If something is only
used by an STC, it may not be in the LNKLST. This is to shield anyone from 
having to make
JCL changes etc. (pretty standard stuff, right?).

So many of these datasets being "staged" prior to cloning are ENQed.  If the 
input library
in the copy is larger than the one on the maintenance sysres volume, that is 
when DFDSS
fails.  If it doesn't have to scratch / reallocate the dataset that already 
exists to make it
larger to accommodate the input data set size,  it works fine.

Here is a sample of the copy process with DFDSS, only there would be many more
libraries copied / renamed than just a single one for almost all products.  
(another shortcoming
of DFDSS compared to FDRCOPY where only the HLQ can be renamed and FDRCOPY can
rename the hlq plus add / remove nodes for multiple datasets - dozens if I 
needed,  in a single
control statement, but I digress...)

//SYSINDD  *
 COPY DS( -
   INCLUDE( -
smphlq.product.V6R3.LINKLIB -
   )  -
)  -
  RENAMEU( -
   (smphlq.product.V6R3.LINKLIB -
  prodhlq.product.LINKLIB)-
 ) -
  SHARE TOL(ENQF)   PROCESS(SYS1) -
  BYPASSACS(**)   -
  NULLSTORCLAS-
  LIDY(inpvol)-
  OUTDYNAM(outvol,SYSALLDA)   -
  REPLACEUNCONDITIONAL -
  WAIT(2,2)  ALLDATA(*)  ALLEXCP
/*

If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to 
being in the LNKLST on the driving system), you get this error:

ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON
CODE IS FP-007

ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET


** VOTE here by clicking the vote icon at the top left!
https://urldefense.com/v3/__https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862__;!!MwwqYLOC6b6whF7V!l88xZXKbWy57EEOicntO2a0U2-ASRLcj7Ya5t5ggE89_A6unfsAePPoZPdaeGWNpUinbleEiMkvaePQ$

Regards,  Mark

>Sorry for top posting...
>
>Let's address your comments one keyword at a time:
>
>DELETE - deletes the source (input) dataset.  Ouch!  Lets not delete my SMP/E 
>target libs during copy to my sysres set please!
>
>PURGE -  overlays an output dataset that has an expiration date not yet 
>reac

Re: DFDSS RFE - Please read / vote

[Mark Zelden]

On Fri, 13 Oct 2023 15:31:42 -0500, Mark Zelden  wrote:

I've had some offline responses also. Including the suggestion to use 
TOLERATE(ENQFAILURE)
 which only applies to the input dataset.  Let me explain again and show all 
the DFDSS control cards.

I have an "program products" sysres that is an extension of IBM OS sysres. 
There is a maintenance
version of that sysres, just like you have a maintenance IBM sysres that you 
apply SMP/E maintenance
to.  The PP sysres gets cloned along with the IBM sysres via full volume disk 
to disk copies. That is not
a problem.  

That program products sysres (really 2 3390-27 volumes) has perhaps 40 IBM / 
ISV products.
All the datasets are indirectly catalogued via   Program product SMP/E 
target libs are copied
(and renamed during the copy) to the PP maintenance sysres at various time.  
When maintenance 
for any give product is applied (or an upgrade) and is ready to roll out the 
sysprog copies
the SMP/E targets to this maintenance sysres.  So think of it as a volume were 
changes are staged for
production.  Then after cloning, the changes are rolled out as a package, be it 
with IBM OS maintenance,
one product, several products, or any combination like that.   This is done via 
rolling IPLs in
a sysplex environment so as not to cause any application outages (usually half 
the LPARs one
month, the other half the next month).   Almost every product's main loadlib is 
in the LNKLST - at
least anything that has associated production JCL, TSO CLISTs / EXECs, ISPxLIBs 
etc.  If something is only
used by an STC, it may not be in the LNKLST. This is to shield anyone from 
having to make 
JCL changes etc. (pretty standard stuff, right?).

So many of these datasets being "staged" prior to cloning are ENQed.  If the 
input library
in the copy is larger than the one on the maintenance sysres volume, that is 
when DFDSS
fails.  If it doesn't have to scratch / reallocate the dataset that already 
exists to make it
larger to accommodate the input data set size,  it works fine.

Here is a sample of the copy process with DFDSS, only there would be many more
libraries copied / renamed than just a single one for almost all products.  
(another shortcoming
of DFDSS compared to FDRCOPY where only the HLQ can be renamed and FDRCOPY can
rename the hlq plus add / remove nodes for multiple datasets - dozens if I 
needed,  in a single 
control statement, but I digress...) 

//SYSINDD  *
 COPY DS( - 
   INCLUDE( -   
smphlq.product.V6R3.LINKLIB -   
   )  - 
)  -
  RENAMEU( -
   (smphlq.product.V6R3.LINKLIB -   
  prodhlq.product.LINKLIB)- 
 ) -
  SHARE TOL(ENQF)   PROCESS(SYS1) - 
  BYPASSACS(**)   - 
  NULLSTORCLAS- 
  LIDY(inpvol)- 
  OUTDYNAM(outvol,SYSALLDA)   - 
  REPLACEUNCONDITIONAL -
  WAIT(2,2)  ALLDATA(*)  ALLEXCP
/*  

If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to 
being in the LNKLST on the driving system), you get this error:

ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON
CODE IS FP-007

ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET


** VOTE here by clicking the vote icon at the top left! 
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862

Regards,  Mark

>Sorry for top posting...
>
>Let's address your comments one keyword at a time:
>
>DELETE - deletes the source (input) dataset.  Ouch!  Lets not delete my SMP/E 
>target libs during copy to my sysres set please! 
>
>PURGE -  overlays an output dataset that has an expiration date not yet 
>reached.  Not applicable. 
>
>UNCOND -  no such parm or abbreviation.  I assume you mean 
>replaceunconditional, and that is already being done and doesn't matter.
>
>The deficiency is DADSM.  This is how DFSMSdss is handling this scenaro (it 
>attempts to scratch the DSN to reallocate a bigger dsn on copy if required).  
>DADSM can't scratch the DSN because the DSN is ENQ'd.
>
>ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
>DATA SET SYNCSORT.SYNCLINK. RETURN CODE IS 102, REASON
>CODE IS FP-007
>
>You also will see:  
>
>"ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET"
>
>Ironic since the CATALOG keyword is not used while copying over the indirectly 
>catalogged dataset on the maintenance sysres set.
>
>Not sure what FDRCOPY does under the covers... no access right now try try and 
>determine that.  Perhaps it renames it first and deletes 

Re: DFDSS RFE - Please read / vote

[Mark Zelden]

Sorry for top posting...

Let's address your comments one keyword at a time:

DELETE - deletes the source (input) dataset.  Ouch!  Lets not delete my SMP/E 
target libs during copy to my sysres set please! 

PURGE -  overlays an output dataset that has an expiration date not yet 
reached.  Not applicable. 

UNCOND -  no such parm or abbreviation.  I assume you mean 
replaceunconditional, and that is already being done and doesn't matter.

The deficiency is DADSM.  This is how DFSMSdss is handling this scenaro (it 
attempts to scratch the DSN to reallocate a bigger dsn on copy if required).  
DADSM can't scratch the DSN because the DSN is ENQ'd.

ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED 
DATA SET SYNCSORT.SYNCLINK. RETURN CODE IS 102, REASON
CODE IS FP-007

You also will see:  

"ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET"

Ironic since the CATALOG keyword is not used while copying over the indirectly 
catalogged dataset on the maintenance sysres set.

Not sure what FDRCOPY does under the covers... no access right now try try and 
determine that.  Perhaps it renames it first and deletes it with DADSM.   But I 
know one does not need access to STGADMIN.DPDSRN.dsn_to_rename in order for it 
to work with FDRCOPY.  

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/



On Thu, 12 Oct 2023 22:44:29 +, willie bunter  
wrote:

> I thought the UNCOND DELETE PURGE parms could be used along with the COPY 
> command
>
>On Wednesday, October 11, 2023 at 05:00:17 p.m. EDT, Mark Zelden 
>  wrote:  
> 
> Hi all,
>
>Please read / vote for this RFE.
>
>
>"Provide abilty for DSS to be able to scratch and reallocate an in use data 
>set name that is not the actual dataset in use during a logical copy operation"
>
>https://ideas.ibm.com/ideas/ZOS-I-3862
>
>I think you vote here:
>https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862
>
>I was honestly shocked this is not supported in DFDSS.  I've been using FDR 
>for over 30 years for this.
>
>I don't know if you can see the entire text, so I will copy it below to 
>explain the issue, but in summary:
>
>If you are copying a dataset to a maintenance sysres (target sysres that will 
>be cloned) and that DSN 
>is ENQd, the copy will work - unless the dataset needs to be scratched / 
>reallocated because the
>input dataset is larger than the output one that already exists.  I've been 
>supporting clients for
>30 years that keep ISV (and IBM non-OS) products as an extension of the sysres 
>and recently
>ran into this at a client that dumped FDR since they had DFDSS and ran into 
>this problem.
>
>If you know a way around the issue - shoot!  IBM says it is not supported.  
>You can delete the
>not in use dataset after rename (if allowed) but that is error prone since you 
>have to point to 
>the maintenance volume and I don't want JR. people doing this.  One other work 
>around is
>after the logical copy fails, you can run it again as physical since the 
>dataset is enlarged
>on the first try, but just fails in scratch.  BTW, "CATALOG" is never used in 
>this copy since
>the datasets are indirectly catalogged.  
>
>Now for the RFE main part of the RFE text:
>
>---
>
>Putting maintenance onto a "target" / maintenance sysres volume or set has 
>been an MVS concept  and cloning an IPLable sysres set (or swapping IPL sets) 
>"forever" . Many shops also put other IBM products or ISV products on a 
>secondary / tertiary sysres and indirectly catalog them so they are on the 
>sysres set.  This is the only way to support rolling IPLs in a sysplex so 
>there are not application outages (another MVS concept).  Since those 
>secondary / tertiary  volumes are a combination of products, adding new 
>datasets is done via logical copy of a product's target libraries to the 
>target / maintenance sysres and those datasets are indirectly catalogged using 
>a system symbol like , , etc.  The copy to the "target" system 
>(maintenance sysres) works fine even if the same named dataset is in use on 
>the live sysres set (be it in the LNKLST, TSO PROC, STC STEPLIB etc.).  
>EXCEPT... when the dataset needs to be enlarged as part of the copy process.  
>In that case you get message ADR497E RC 102 Reason code FP-007 and "ERROR 
>OCCURRED WHILE DELETING UNCATALOGED DATA SET" and the copy for that dataset 
>fails.  However, the dataset to be "overlaid" (if you will), is not the 
>dataset in use so DFDSS should have the ability to enlarge it and do the copy. 
> The only solution is to use the DFSMS special SAF authority to rename a 
>dataset in use (STGADMIN.DPDSRN.dsn_to_rename) to rename the "target" dataset 
>on the maintenance volume, then 

Re: DFDSS RFE - Please read / vote

[willie bunter]

 I thought the UNCOND DELETE PURGE parms could be used along with the COPY 
command

On Wednesday, October 11, 2023 at 05:00:17 p.m. EDT, Mark Zelden 
 wrote:  
 
 Hi all,

Please read / vote for this RFE.


"Provide abilty for DSS to be able to scratch and reallocate an in use data set 
name that is not the actual dataset in use during a logical copy operation"

https://ideas.ibm.com/ideas/ZOS-I-3862

I think you vote here:
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862

I was honestly shocked this is not supported in DFDSS.  I've been using FDR for 
over 30 years for this.

I don't know if you can see the entire text, so I will copy it below to explain 
the issue, but in summary:

If you are copying a dataset to a maintenance sysres (target sysres that will 
be cloned) and that DSN 
is ENQd, the copy will work - unless the dataset needs to be scratched / 
reallocated because the
input dataset is larger than the output one that already exists.  I've been 
supporting clients for
30 years that keep ISV (and IBM non-OS) products as an extension of the sysres 
and recently
ran into this at a client that dumped FDR since they had DFDSS and ran into 
this problem.

If you know a way around the issue - shoot!  IBM says it is not supported.  You 
can delete the
not in use dataset after rename (if allowed) but that is error prone since you 
have to point to 
the maintenance volume and I don't want JR. people doing this.  One other work 
around is
after the logical copy fails, you can run it again as physical since the 
dataset is enlarged
on the first try, but just fails in scratch.  BTW, "CATALOG" is never used in 
this copy since
the datasets are indirectly catalogged.  

Now for the RFE main part of the RFE text:

---

Putting maintenance onto a "target" / maintenance sysres volume or set has been 
an MVS concept  and cloning an IPLable sysres set (or swapping IPL sets) 
"forever" . Many shops also put other IBM products or ISV products on a 
secondary / tertiary sysres and indirectly catalog them so they are on the 
sysres set.  This is the only way to support rolling IPLs in a sysplex so there 
are not application outages (another MVS concept).  Since those secondary / 
tertiary  volumes are a combination of products, adding new datasets is done 
via logical copy of a product's target libraries to the target / maintenance 
sysres and those datasets are indirectly catalogged using a system symbol like 
, , etc.  The copy to the "target" system (maintenance sysres) 
works fine even if the same named dataset is in use on the live sysres set (be 
it in the LNKLST, TSO PROC, STC STEPLIB etc.).  EXCEPT... when the dataset 
needs to be enlarged as part of the copy process.  In that case you get message 
ADR497E RC 102 Reason code FP-007 and "ERROR OCCURRED WHILE DELETING 
UNCATALOGED DATA SET" and the copy for that dataset fails.  However, the 
dataset to be "overlaid" (if you will), is not the dataset in use so DFDSS 
should have the ability to enlarge it and do the copy.  The only solution is to 
use the DFSMS special SAF authority to rename a dataset in use 
(STGADMIN.DPDSRN.dsn_to_rename) to rename the "target" dataset on the 
maintenance volume, then delete it, then rerun the copy job.  This could be 
very error prone if someone doesn't put in the correct volser on ISPF  and they 
could rename the "real" in use dataset or perhaps one on a different sysres 
set.  

---

Please vote this one up!  

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS, SMS and VIO.

[Colin Paice]

Thank you.. found it here


On Thu, 26 May 2022 at 10:50, Nigel Morton  wrote:

> Colin, this is controlled by the storage group construct, not the storage
> class.
>
> On Thu, 26 May 2022 at 10:16, Colin Paice  wrote:
>
> > I found a problem where I had a job with two steps.
> > step 1 unterse a file to a temporary file
> > step 2 use DFDSS to "restore" from the untersed file.
> >
> > When the temporary file is in VIO, I get a message from DFDSS
> >
> > *ADR025E (001)-DEVSU(03), INPUT DEVICE TYPE IS INVALID FOR TASK*
> >
> > If I use a non VIO dataset it works.   (I guess ADRDSSU is not smart
> enough
> > to handle VIO)
> >
> > When I add STORCLAS=SCNOVIO to my temporary file it does not use VIO.
> >
> > Looking in the SMS books, I cannot see where the  STORCLAS says use VIO
> or
> > not.
> >
> > Does anyone know where the use of VIO or not is defined in SMS?
> >
> > Colin
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS, SMS and VIO.

[Nigel Morton]

Colin, this is controlled by the storage group construct, not the storage
class.

On Thu, 26 May 2022 at 10:16, Colin Paice  wrote:

> I found a problem where I had a job with two steps.
> step 1 unterse a file to a temporary file
> step 2 use DFDSS to "restore" from the untersed file.
>
> When the temporary file is in VIO, I get a message from DFDSS
>
> *ADR025E (001)-DEVSU(03), INPUT DEVICE TYPE IS INVALID FOR TASK*
>
> If I use a non VIO dataset it works.   (I guess ADRDSSU is not smart enough
> to handle VIO)
>
> When I add STORCLAS=SCNOVIO to my temporary file it does not use VIO.
>
> Looking in the SMS books, I cannot see where the  STORCLAS says use VIO or
> not.
>
> Does anyone know where the use of VIO or not is defined in SMS?
>
> Colin
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS Restore IGD306I problem

[(K.K.Paradox)T.Kobayashi]

Furuya-san,

I will check the SG settings. Thank you for your advice.

Best regards,
Toyokazu Kobayashi

- Original Message - 
From: "Nobuhiko Furuya" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, October 07, 2021 1:29 PM
Subject: Re: DFDSS Restore IGD306I problem



Hi -san,

You can find the reason code 1013 in DFSMSdfp Diagnosis as follows.

1013 (X'03F5') No storage group was assigned by the storage group routine.

IGD306I message manual directs you to check the above manual.

Also you can find the following messages in your joblog.

0ADR709E (001)-VDSS (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT
SUBSYSTEM WHILE ALLOCATING DATA SET SAMPLE.WORK1. SMS
 MESSAGES FOLLOW.
 IGD01013I DATA SET ALLOCATION REQUEST FAILED -
 THE ACS STORAGE GROUP ROUTINE DID NOT ASSIGN A STORAGE GROUP
 IGD17354I UNEXPECTED RETURN CODE FROM AUTOMATIC CLASS SELECTION SERVICES
 RETURN CODE IS 8 REASON CODE IS 1013 DATA SET BEING PROCESSED IS
 SAMPLE.WORK1

It clearly states that your SG acs routine in the restoring environment
doesn't assign a storage group to the data set.

Best regards,

Nobuhiko Furuya(古谷信彦)
V-SOL Inc.
e-mail:furu...@v-sol.co.jp
Mobile:+81-90-4096-7700
2-14-5-1001, Ohkubo, Narashino, Chiba, Japan 275-0011

On 2021/10/07 12:58, (K.K.Paradox)T.Kobayashi wrote:

Hello,

I was restoring multiple dumps but ran into an issue where only one dump
could not be restored due to IGD306I error.
The dumped and restored environments are different.
I could not find any details of the REASON CODE 1013 and issued messages
(IGD1 and IGD2).
Is there a cause and solution for this problem?

Issued Messages:
14.02.45 JOB00887 IGD306I UNEXPECTED ERROR DURING IGDACS00 PROCESSING 061
061 RETURN CODE 8 REASON CODE 1013
061 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCM
061 SMS MODULE TRACE BACK - VTSCM VTSCR SSIRT
061 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD1
14.02.48 JOB00887 IGD306I UNEXPECTED ERROR DURING IGDACS00 PROCESSING 062
062 RETURN CODE 8 REASON CODE 1013
062 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCM
062 SMS MODULE TRACE BACK - VTSCM VTSCR SSIRT
062 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD2

Detail:
1PAGE 0001 5695-DF175 DFSMSDSS V2R01.0 DATA SET SERVICES 2021.279
14:01
- RESTORE -
DATASET( -
INCLUDE( ** -
)) -
BYPASSACS( ** -
)) -
INDD(INTAPE1) -
OUTDD(DO1) CAT REP
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE
'
ADR109I (R/I)-RI01 (01), 2021.279 14:01:38 INITIAL SCAN OF USER CONTROL
STATEMENTS COMPLETED
ADR106W (001)-RI01 (01), TOO MANY RIGHT PARENTHESES FOUND. EXCESS IGNORED
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
0ADR006I (001)-STEND(01), 2021.279 14:01:38 EXECUTION BEGINS
0ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN
LOGICAL DATA SET FORMAT AND WAS CREATED BY Z/OS DFSMSDSS
VERSION 1 RELEASE 13 MODIFICATION LEVEL 0 ON
2015.323 06:30:28
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SYSPUNCH ALLOCATED, ON
VOLUME(S):
AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SYSPUNCH HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SYSPUNCH CONSISTS OF 0001
TARGET TRACKS AND 0001 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SYSPUNCH WAS RESTORED
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SYSREC00 ALLOCATED, ON
VOLUME(S):
AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SYSREC00 HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SYSREC00 CONSISTS OF 3972
TARGET TRACKS AND 3972 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SYSREC00 WAS RESTORED
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SORTOUT ALLOCATED, ON
VOLUME(S):
AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SORTOUT HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SORTOUT CONSISTS OF 3972
TARGET TRACKS AND 3972 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SORTOUT WAS RESTORED
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SYSPUNCH ALLOCATED, ON
VOLUME(S):
AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SYSPUNCH HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SYSPUNCH CONSISTS OF 0001
TARGET TRACKS AND 0001 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SYSPUNCH WAS RESTORED
0ADR709E (001)-VDSS (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT
SUBSYSTEM WHILE ALLOCATING DATA SET SAMPLE.WORK1. SMS
MESSAGES FOLLOW.
IGD01013I DATA SET ALLOCATION REQUEST FAILED -
THE ACS STORAGE GROUP ROUTINE DID NOT ASSIGN A STORAGE GROUP
IGD17354I UNEXPECTED RETURN CODE FROM AUTOMATIC CLASS SELECTION SERVICES
RETURN CODE IS 8 REASON CODE IS 1013 DATA SET BEING PROCESSED IS
SAMPLE.WORK1
1PAGE 0002 5695-DF175 DFSMSDSS V2R01.0 DATA SET SERVICES 2021.279
14:01
- IGD306I UNEXPECTED ERROR DURING IGDACS00 PROCESSING
RETURN CODE 8 REASON CODE 1013
THE MODULE THAT DETECTED THE ERROR IS IGDVTSCM
SMS MODULE TRACE BACK - VTSCM VTSCR SSIRT
SYMPTOM RECORD CREATED, PROBLEM ID I

Re: DFDSS Restore IGD306I problem

[Nobuhiko Furuya]

Hi -san,

You can find the reason code 1013 in DFSMSdfp Diagnosis as follows.

1013 (X'03F5') No storage group was assigned by the storage group routine.

IGD306I message manual directs you to check the above manual.

Also you can find the following messages in your joblog.

0ADR709E (001)-VDSS (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT
SUBSYSTEM WHILE ALLOCATING DATA SET SAMPLE.WORK1. SMS
 MESSAGES FOLLOW.
 IGD01013I DATA SET ALLOCATION REQUEST FAILED -
 THE ACS STORAGE GROUP ROUTINE DID NOT ASSIGN A STORAGE GROUP
 IGD17354I UNEXPECTED RETURN CODE FROM AUTOMATIC CLASS SELECTION SERVICES
 RETURN CODE IS 8 REASON CODE IS 1013 DATA SET BEING PROCESSED IS
 SAMPLE.WORK1

It clearly states that your SG acs routine in the restoring environment 
doesn't assign a storage group to the data set.


Best regards,

Nobuhiko Furuya(古谷信彦)
V-SOL Inc.
e-mail:furu...@v-sol.co.jp
Mobile:+81-90-4096-7700
2-14-5-1001, Ohkubo, Narashino, Chiba, Japan 275-0011

On 2021/10/07 12:58, (K.K.Paradox)T.Kobayashi wrote:

Hello,

I was restoring multiple dumps but ran into an issue where only one dump
could not be restored due to IGD306I error.
The dumped and restored environments are different.
I could not find any details of the REASON CODE 1013 and issued messages
(IGD1 and IGD2).
Is there a cause and solution for this problem?

Issued Messages:
14.02.45 JOB00887  IGD306I UNEXPECTED ERROR DURING IGDACS00 
PROCESSING  061

   061 RETURN CODE 8 REASON CODE 1013
   061 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCM
   061 SMS MODULE TRACE BACK - VTSCM VTSCR SSIRT
   061 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD1
14.02.48 JOB00887  IGD306I UNEXPECTED ERROR DURING IGDACS00 
PROCESSING  062

   062 RETURN CODE 8 REASON CODE 1013
   062 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCM
   062 SMS MODULE TRACE BACK - VTSCM VTSCR SSIRT
   062 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD2

Detail:
1PAGE 0001 5695-DF175  DFSMSDSS V2R01.0 DATA SET SERVICES 2021.279
14:01
-  RESTORE -
    DATASET(  -
  INCLUDE( ** -
   )) -
  BYPASSACS( **   -
   )) -
    INDD(INTAPE1) -
    OUTDD(DO1) CAT  REP
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 
'RESTORE '

ADR109I (R/I)-RI01 (01), 2021.279 14:01:38 INITIAL SCAN OF USER CONTROL
STATEMENTS COMPLETED
ADR106W (001)-RI01 (01), TOO MANY RIGHT PARENTHESES FOUND. EXCESS IGNORED
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
0ADR006I (001)-STEND(01), 2021.279 14:01:38 EXECUTION BEGINS
0ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN
LOGICAL DATA SET FORMAT AND WAS CREATED BY Z/OS DFSMSDSS
 VERSION 1 RELEASE 13 MODIFICATION LEVEL 0 ON
2015.323 06:30:28
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SYSPUNCH ALLOCATED, ON 
VOLUME(S):

AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SYSPUNCH HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SYSPUNCH CONSISTS OF 0001
TARGET TRACKS AND 0001 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SYSPUNCH WAS RESTORED
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SYSREC00 ALLOCATED, ON 
VOLUME(S):

AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SYSREC00 HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SYSREC00 CONSISTS OF 3972
TARGET TRACKS AND 3972 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SYSREC00 WAS RESTORED
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SORTOUT ALLOCATED, ON 
VOLUME(S):

AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SORTOUT HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SORTOUT CONSISTS OF 3972
TARGET TRACKS AND 3972 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SORTOUT WAS RESTORED
0ADR396I (001)-NEWDS(01), DATA SET SAMPLE.SYSPUNCH ALLOCATED, ON 
VOLUME(S):

AD3710
0ADR465I (001)-DALOC(01), DATA SET SAMPLE.SYSPUNCH HAS BEEN CATALOGED IN
CATALOG MCAT.ZOSV2
0ADR474I (001)-TDNVS(01), DATA SET SAMPLE.SYSPUNCH CONSISTS OF 0001
TARGET TRACKS AND 0001 SOURCE TRACKS
0ADR489I (001)-TDLOG(01), DATA SET SAMPLE.SYSPUNCH WAS RESTORED
0ADR709E (001)-VDSS (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT
SUBSYSTEM WHILE ALLOCATING DATA SET SAMPLE.WORK1. SMS
 MESSAGES FOLLOW.
 IGD01013I DATA SET ALLOCATION REQUEST FAILED -
 THE ACS STORAGE GROUP ROUTINE DID NOT ASSIGN A STORAGE GROUP
 IGD17354I UNEXPECTED RETURN CODE FROM AUTOMATIC CLASS SELECTION SERVICES
 RETURN CODE IS 8 REASON CODE IS 1013 DATA SET BEING PROCESSED IS
 SAMPLE.WORK1
1PAGE 0002 5695-DF175  DFSMSDSS V2R01.0 DATA SET SERVICES 2021.279
14:01
- IGD306I UNEXPECTED ERROR DURING IGDACS00 PROCESSING
 RETURN CODE 8 REASON CODE 1013
 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCM
 SMS MODULE TRACE BACK - VTSCM VTSCR SSIRT
 SYMPTOM RECORD 

Re: DFDSS copydump

[Ken Bloom]

Thanks Mike

Kenneth A. Blood
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com<mailto:bl...@visara.com>
www.visara.com<http://www.visara.com/>


On Dec 3, 2020, at 11:24 AM, Mike Schwab  wrote:

Check a backup tape on each server?  I.E. TMS catalog or RMM equivalent.

On Thu, Dec 3, 2020 at 10:15 AM Ken Bloom  wrote:

Mike

Is there anyway to query the drive and retrieve the tape media type and block 
size?

Regards
Ken


Kenneth A. Bloom
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.visara.com=E,1,WvpUrwAPtmBzbetbYcMnCrgow28ZzfMo7AWHEiw_C4DpRJpOtGJkXqEENJER5Czj-_wmS2H3gIrr6GxhAu7G37wcy4nCV_boc-jW8dBEijmTy19Ua85ifafF=1


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of (K.K.Paradox)T.Kobayashi
Sent: Thursday, December 3, 2020 4:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copydump

Hello Mike,

Thank you for your reply, I will check the maximum block sizes of device.

Best regards,
Toyokazu Kobayashi

- Original Message -
From: "Mike Schwab" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, December 02, 2020 6:20 PM
Subject: Re: DFDSS copydump


What are the maximum block sizes of the two different device types?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2259.htm
If the source tape has actual blocks bigger than the maximum blocksize
of the destination tape, it cannot be copied.

On Wed, Dec 2, 2020 at 2:52 AM (K.K.Paradox)T.Kobayashi
 wrote:

Hello,

We are migrating data from 3592 to VTL.
The 3592 and VTL are both defined on the Mainframe as 3590 device.
The 3592 tape media has IDCAMS REPRO and DFDSS DUMP datasets.

The REPRO dataset could be copied and moved to VTL.
But, DFDSS DUMP datasets copy failed with copydump.

*IEF233A M 0A01,FISVO1,,RD0601GJ,STEP001,USBACKUP
*IEF233A M 0A13,REN801,,RD0601GJ,STEP001,USBACKUP
IEC141I 013-68,IFG0196L,RD0601GJ,STEP001,OUT1,0A13,REN801,  691
IEC149I 813-04,IFG0195H,RD0601GJ,STEP001,OUT1,0A13,REN801,  692

- COPYDUMP -
00080001
  INDD(IN1) /* DUMP TAPE TO BE COPIED */ -
00090001
  OUTDD(OUT1) /* NEW DUMP TAPE */
00091001
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND
'COPYDUMP
'
ADR109I (R/I)-RI01 (01), 2020.293 09:46:53 INITIAL SCAN OF USER CONTROL
STATEMENTS COMPLETED
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
0ADR006I (001)-STEND(01), 2020.293 09:46:53 EXECUTION BEGINS
0ADR049E (001)-STEND(01), 2020.293 10:01:04 DFSMSDSS FUNCTION TASK ABEND
RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0013 REASON
 CODE=0068
0ADR006I (001)-STEND(02), 2020.293 10:01:04 EXECUTION ENDS
0ADR013I (001)-CLTSK(01), 2020.293 10:01:04 TASK COMPLETED WITH RETURN
CODE
0008
0ADR012I (SCH)-DSSU (01), 2020.293 10:01:04 DFSMSDSS PROCESSING COMPLETE.
HIGHEST RETURN CODE IS 0008 FROM:
 TASK001

The 3592 is Medea Type 7 and the VTL is Media Type 3.
It seems that this error is occurring so as not to allow copying to
smaller
capacity media.
However, VTL is a virtual tape with unlimited media size capacity.
Restore from 3592 and re-dump to VTL is a lot of work, so we want to
avoid
this.

Is there a way around this error?

Best regards,
Toyokazu Kobayashi

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copydump

[Mike Schwab]

Check a backup tape on each server?  I.E. TMS catalog or RMM equivalent.

On Thu, Dec 3, 2020 at 10:15 AM Ken Bloom  wrote:
>
> Mike
>
> Is there anyway to query the drive and retrieve the tape media type and block 
> size?
>
> Regards
> Ken
>
>
> Kenneth A. Bloom
> Avenir Technologies Inc
> /d/b/a Visara International
> 203-984-2235
> bl...@visara.com
> www.visara.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of (K.K.Paradox)T.Kobayashi
> Sent: Thursday, December 3, 2020 4:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFDSS copydump
>
> Hello Mike,
>
> Thank you for your reply, I will check the maximum block sizes of device.
>
> Best regards,
> Toyokazu Kobayashi
>
> - Original Message -
> From: "Mike Schwab" 
> Newsgroups: bit.listserv.ibm-main
> To: 
> Sent: Wednesday, December 02, 2020 6:20 PM
> Subject: Re: DFDSS copydump
>
>
> > What are the maximum block sizes of the two different device types?
> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2259.htm
> > If the source tape has actual blocks bigger than the maximum blocksize
> > of the destination tape, it cannot be copied.
> >
> > On Wed, Dec 2, 2020 at 2:52 AM (K.K.Paradox)T.Kobayashi
> >  wrote:
> >>
> >> Hello,
> >>
> >> We are migrating data from 3592 to VTL.
> >> The 3592 and VTL are both defined on the Mainframe as 3590 device.
> >> The 3592 tape media has IDCAMS REPRO and DFDSS DUMP datasets.
> >>
> >> The REPRO dataset could be copied and moved to VTL.
> >> But, DFDSS DUMP datasets copy failed with copydump.
> >>
> >> *IEF233A M 0A01,FISVO1,,RD0601GJ,STEP001,USBACKUP
> >> *IEF233A M 0A13,REN801,,RD0601GJ,STEP001,USBACKUP
> >>  IEC141I 013-68,IFG0196L,RD0601GJ,STEP001,OUT1,0A13,REN801,  691
> >>  IEC149I 813-04,IFG0195H,RD0601GJ,STEP001,OUT1,0A13,REN801,  692
> >>
> >> - COPYDUMP -
> >> 00080001
> >>INDD(IN1) /* DUMP TAPE TO BE COPIED */ -
> >> 00090001
> >>OUTDD(OUT1) /* NEW DUMP TAPE */
> >> 00091001
> >>  ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND
> >> 'COPYDUMP
> >> '
> >>  ADR109I (R/I)-RI01 (01), 2020.293 09:46:53 INITIAL SCAN OF USER CONTROL
> >> STATEMENTS COMPLETED
> >>  ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
> >> 0ADR006I (001)-STEND(01), 2020.293 09:46:53 EXECUTION BEGINS
> >> 0ADR049E (001)-STEND(01), 2020.293 10:01:04 DFSMSDSS FUNCTION TASK ABEND
> >> RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0013 REASON
> >>   CODE=0068
> >> 0ADR006I (001)-STEND(02), 2020.293 10:01:04 EXECUTION ENDS
> >> 0ADR013I (001)-CLTSK(01), 2020.293 10:01:04 TASK COMPLETED WITH RETURN
> >> CODE
> >> 0008
> >> 0ADR012I (SCH)-DSSU (01), 2020.293 10:01:04 DFSMSDSS PROCESSING COMPLETE.
> >> HIGHEST RETURN CODE IS 0008 FROM:
> >>   TASK001
> >>
> >> The 3592 is Medea Type 7 and the VTL is Media Type 3.
> >> It seems that this error is occurring so as not to allow copying to
> >> smaller
> >> capacity media.
> >> However, VTL is a virtual tape with unlimited media size capacity.
> >> Restore from 3592 and re-dump to VTL is a lot of work, so we want to
> >> avoid
> >> this.
> >>
> >> Is there a way around this error?
> >>
> >> Best regards,
> >> Toyokazu Kobayashi
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> > --
> > Mike A Schwab, Springfield IL USA
> > Where do Forest Rangers go to get away from it all?
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copydump

[Ken Bloom]

Mike

Is there anyway to query the drive and retrieve the tape media type and block 
size?

Regards
Ken


Kenneth A. Bloom
Avenir Technologies Inc 
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of (K.K.Paradox)T.Kobayashi
Sent: Thursday, December 3, 2020 4:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copydump

Hello Mike,

Thank you for your reply, I will check the maximum block sizes of device.

Best regards,
Toyokazu Kobayashi

- Original Message - 
From: "Mike Schwab" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, December 02, 2020 6:20 PM
Subject: Re: DFDSS copydump


> What are the maximum block sizes of the two different device types?
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2259.htm
> If the source tape has actual blocks bigger than the maximum blocksize
> of the destination tape, it cannot be copied.
>
> On Wed, Dec 2, 2020 at 2:52 AM (K.K.Paradox)T.Kobayashi
>  wrote:
>>
>> Hello,
>>
>> We are migrating data from 3592 to VTL.
>> The 3592 and VTL are both defined on the Mainframe as 3590 device.
>> The 3592 tape media has IDCAMS REPRO and DFDSS DUMP datasets.
>>
>> The REPRO dataset could be copied and moved to VTL.
>> But, DFDSS DUMP datasets copy failed with copydump.
>>
>> *IEF233A M 0A01,FISVO1,,RD0601GJ,STEP001,USBACKUP
>> *IEF233A M 0A13,REN801,,RD0601GJ,STEP001,USBACKUP
>>  IEC141I 013-68,IFG0196L,RD0601GJ,STEP001,OUT1,0A13,REN801,  691
>>  IEC149I 813-04,IFG0195H,RD0601GJ,STEP001,OUT1,0A13,REN801,  692
>>
>> - COPYDUMP -
>> 00080001
>>INDD(IN1) /* DUMP TAPE TO BE COPIED */ -
>> 00090001
>>OUTDD(OUT1) /* NEW DUMP TAPE */
>> 00091001
>>  ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 
>> 'COPYDUMP
>> '
>>  ADR109I (R/I)-RI01 (01), 2020.293 09:46:53 INITIAL SCAN OF USER CONTROL
>> STATEMENTS COMPLETED
>>  ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
>> 0ADR006I (001)-STEND(01), 2020.293 09:46:53 EXECUTION BEGINS
>> 0ADR049E (001)-STEND(01), 2020.293 10:01:04 DFSMSDSS FUNCTION TASK ABEND
>> RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0013 REASON
>>   CODE=0068
>> 0ADR006I (001)-STEND(02), 2020.293 10:01:04 EXECUTION ENDS
>> 0ADR013I (001)-CLTSK(01), 2020.293 10:01:04 TASK COMPLETED WITH RETURN 
>> CODE
>> 0008
>> 0ADR012I (SCH)-DSSU (01), 2020.293 10:01:04 DFSMSDSS PROCESSING COMPLETE.
>> HIGHEST RETURN CODE IS 0008 FROM:
>>   TASK001
>>
>> The 3592 is Medea Type 7 and the VTL is Media Type 3.
>> It seems that this error is occurring so as not to allow copying to 
>> smaller
>> capacity media.
>> However, VTL is a virtual tape with unlimited media size capacity.
>> Restore from 3592 and re-dump to VTL is a lot of work, so we want to 
>> avoid
>> this.
>>
>> Is there a way around this error?
>>
>> Best regards,
>> Toyokazu Kobayashi
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> -- 
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copydump

[(K.K.Paradox)T.Kobayashi]

Hello Mike,

Thank you for your reply, I will check the maximum block sizes of device.

Best regards,
Toyokazu Kobayashi

- Original Message - 
From: "Mike Schwab" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, December 02, 2020 6:20 PM
Subject: Re: DFDSS copydump



What are the maximum block sizes of the two different device types?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2259.htm
If the source tape has actual blocks bigger than the maximum blocksize
of the destination tape, it cannot be copied.

On Wed, Dec 2, 2020 at 2:52 AM (K.K.Paradox)T.Kobayashi
 wrote:


Hello,

We are migrating data from 3592 to VTL.
The 3592 and VTL are both defined on the Mainframe as 3590 device.
The 3592 tape media has IDCAMS REPRO and DFDSS DUMP datasets.

The REPRO dataset could be copied and moved to VTL.
But, DFDSS DUMP datasets copy failed with copydump.

*IEF233A M 0A01,FISVO1,,RD0601GJ,STEP001,USBACKUP
*IEF233A M 0A13,REN801,,RD0601GJ,STEP001,USBACKUP
 IEC141I 013-68,IFG0196L,RD0601GJ,STEP001,OUT1,0A13,REN801,  691
 IEC149I 813-04,IFG0195H,RD0601GJ,STEP001,OUT1,0A13,REN801,  692

- COPYDUMP -
00080001
   INDD(IN1) /* DUMP TAPE TO BE COPIED */ -
00090001
   OUTDD(OUT1) /* NEW DUMP TAPE */
00091001
 ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 
'COPYDUMP

'
 ADR109I (R/I)-RI01 (01), 2020.293 09:46:53 INITIAL SCAN OF USER CONTROL
STATEMENTS COMPLETED
 ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
0ADR006I (001)-STEND(01), 2020.293 09:46:53 EXECUTION BEGINS
0ADR049E (001)-STEND(01), 2020.293 10:01:04 DFSMSDSS FUNCTION TASK ABEND
RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0013 REASON
  CODE=0068
0ADR006I (001)-STEND(02), 2020.293 10:01:04 EXECUTION ENDS
0ADR013I (001)-CLTSK(01), 2020.293 10:01:04 TASK COMPLETED WITH RETURN 
CODE

0008
0ADR012I (SCH)-DSSU (01), 2020.293 10:01:04 DFSMSDSS PROCESSING COMPLETE.
HIGHEST RETURN CODE IS 0008 FROM:
  TASK001

The 3592 is Medea Type 7 and the VTL is Media Type 3.
It seems that this error is occurring so as not to allow copying to 
smaller

capacity media.
However, VTL is a virtual tape with unlimited media size capacity.
Restore from 3592 and re-dump to VTL is a lot of work, so we want to 
avoid

this.

Is there a way around this error?

Best regards,
Toyokazu Kobayashi

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copydump

[Mike Schwab]

What are the maximum block sizes of the two different device types?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2259.htm
If the source tape has actual blocks bigger than the maximum blocksize
of the destination tape, it cannot be copied.

On Wed, Dec 2, 2020 at 2:52 AM (K.K.Paradox)T.Kobayashi
 wrote:
>
> Hello,
>
> We are migrating data from 3592 to VTL.
> The 3592 and VTL are both defined on the Mainframe as 3590 device.
> The 3592 tape media has IDCAMS REPRO and DFDSS DUMP datasets.
>
> The REPRO dataset could be copied and moved to VTL.
> But, DFDSS DUMP datasets copy failed with copydump.
>
> *IEF233A M 0A01,FISVO1,,RD0601GJ,STEP001,USBACKUP
> *IEF233A M 0A13,REN801,,RD0601GJ,STEP001,USBACKUP
>  IEC141I 013-68,IFG0196L,RD0601GJ,STEP001,OUT1,0A13,REN801,  691
>  IEC149I 813-04,IFG0195H,RD0601GJ,STEP001,OUT1,0A13,REN801,  692
>
> - COPYDUMP -
> 00080001
>INDD(IN1) /* DUMP TAPE TO BE COPIED */ -
> 00090001
>OUTDD(OUT1) /* NEW DUMP TAPE */
> 00091001
>  ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPYDUMP
> '
>  ADR109I (R/I)-RI01 (01), 2020.293 09:46:53 INITIAL SCAN OF USER CONTROL
> STATEMENTS COMPLETED
>  ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
> 0ADR006I (001)-STEND(01), 2020.293 09:46:53 EXECUTION BEGINS
> 0ADR049E (001)-STEND(01), 2020.293 10:01:04 DFSMSDSS FUNCTION TASK ABEND
> RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0013 REASON
>   CODE=0068
> 0ADR006I (001)-STEND(02), 2020.293 10:01:04 EXECUTION ENDS
> 0ADR013I (001)-CLTSK(01), 2020.293 10:01:04 TASK COMPLETED WITH RETURN CODE
> 0008
> 0ADR012I (SCH)-DSSU (01), 2020.293 10:01:04 DFSMSDSS PROCESSING COMPLETE.
> HIGHEST RETURN CODE IS 0008 FROM:
>   TASK001
>
> The 3592 is Medea Type 7 and the VTL is Media Type 3.
> It seems that this error is occurring so as not to allow copying to smaller
> capacity media.
> However, VTL is a virtual tape with unlimited media size capacity.
> Restore from 3592 and re-dump to VTL is a lot of work, so we want to avoid
> this.
>
> Is there a way around this error?
>
> Best regards,
> Toyokazu Kobayashi
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Lennie Dymoke-Bradshaw]

If you fork pax then I think this would mean DSS would be invoking access 
methods to perform the backup. DSS has used lower level processes to perform 
backups up to now. 

I mention this because it has a big impact on the way that data is processed 
when the data is encrypted. Currently DSS backs up encrypted data without 
invoking the access methods, thus never needing access to encryption keys. By 
working at block level, data sets can be moved, backed up, migrated, recalled 
without ever accessing the true data.

Lennie Dymoke-Bradshaw
Consultant working on contract for BMC mainframe Services by RSM Partners
‘Dance like no one is watching. Encrypt like everyone is.’


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 01 October 2020 14:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS support for ZFS files query

On Wed, 30 Sep 2020 09:44:52 -0500, Ernesto Figueroa wrote:

>You are correct. For now, you must specify all the path names, but we 
>understand this is a capability that ought to be provided in DFSMSdss.  As 
>others have mentioned, you may be able to use other tools to craft a list of 
>path names and use that to generate DFSMSdss SYSIN statements.  There is an 
>existing RFE to provide the capability to dump an entire directory including 
>all the files and sub-directories, if you feel this is an important feature to 
>be included in the product please cast your vote here:
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=14
>0801
> 
Is it proposed to support patterns in the fashion of "pax"?  The best way to do 
this may be to fork pax itself and keep the dump in pax format.

Don't reinvent the wheel.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Glenn Wilcock]

For those following this thread who have a DFSMShsm license, HSM does support 
this.  It can backup all files, files based on wildcards and exclude specific 
files as directed by an EXCLUDE. A UNIX shell command is also available, to 
perform the HSM backups/recoveries directly from UNIX.
Glenn

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Paul Gilmartin]

On Wed, 30 Sep 2020 09:44:52 -0500, Ernesto Figueroa wrote:

>You are correct. For now, you must specify all the path names, but we 
>understand this is a capability that ought to be provided in DFSMSdss.  As 
>others have mentioned, you may be able to use other tools to craft a list of 
>path names and use that to generate DFSMSdss SYSIN statements.  There is an 
>existing RFE to provide the capability to dump an entire directory including 
>all the files and sub-directories, if you feel this is an important feature to 
>be included in the product please cast your vote here:
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=140801
> 
Is it proposed to support patterns in the fashion of "pax"?  The best way to do
this may be to fork pax itself and keep the dump in pax format.

Don't reinvent the wheel.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Sean Gleann]

Thank you, Ernesto - much appreciated
Vote added.

Regards
Sean


On Wed, 30 Sep 2020 at 15:55, Ernesto Figueroa  wrote:

> You are correct. For now, you must specify all the path names, but we
> understand this is a capability that ought to be provided in DFSMSdss.  As
> others have mentioned, you may be able to use other tools to craft a list
> of path names and use that to generate DFSMSdss SYSIN statements.  There is
> an existing RFE to provide the capability to dump an entire directory
> including all the files and sub-directories, if you feel this is an
> important feature to be included in the product please cast your vote here:
> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=140801
>
> Ernesto E. Figueroa
> DFSMSdss Development Lead
> erfig...@us.ibm.com
> IBM SystemsGroup
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Ernesto Figueroa]

You are correct. For now, you must specify all the path names, but we 
understand this is a capability that ought to be provided in DFSMSdss.  As 
others have mentioned, you may be able to use other tools to craft a list of 
path names and use that to generate DFSMSdss SYSIN statements.  There is an 
existing RFE to provide the capability to dump an entire directory including 
all the files and sub-directories, if you feel this is an important feature to 
be included in the product please cast your vote here:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=140801

Ernesto E. Figueroa
DFSMSdss Development Lead
erfig...@us.ibm.com
IBM SystemsGroup

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Sean Gleann]

I'm hoping that it's still a 'work in progress' & that one day I'll be able
to say 'DUMP PATH INCLUDE('/foldera/folderb/**') or something close to that.

Sean

On Wed, 30 Sep 2020 at 11:35, Andrew Rowley 
wrote:

> On 30/09/2020 6:03 pm, Seymour J Metz wrote:
> > The DSS manual say that when you specify a directory, it does not dump
> the files under that directory. That's very different from the behavior of,
> e.g., tar.
>
> I guess I shouldn't be surprised, given how often IBM don't do things
> the way I hoped.
>
> It does seem to be less useful than it could have been. I wonder what
> the thinking was when it was being designed?
>
> Andrew Rowley
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Andrew Rowley]

On 30/09/2020 6:03 pm, Seymour J Metz wrote:

The DSS manual say that when you specify a directory, it does not dump the 
files under that directory. That's very different from the behavior of, e.g., 
tar.


I guess I shouldn't be surprised, given how often IBM don't do things 
the way I hoped.


It does seem to be less useful than it could have been. I wonder what 
the thinking was when it was being designed?


Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Seymour J Metz]

The DSS manual say that when you specify a directory, it does not dump the 
files under that directory. That's very different from the behavior of, e.g., 
tar.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Andrew Rowley 
Sent: Wednesday, September 30, 2020 3:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS support for ZFS files query

I haven't tested it myself, but what I would hope is that it works like
unix utilities, where the file you specify could actually be a directory.

It is pretty common when using tar etc. to set the working directory,
and specify e.g. "." (a dot) to select the current directory, or specify
a subdirectory name.

You can then restore to a different location by setting a different
working directory before the restore, i.e. all names are relative to the
working directory.

On 29/09/2020 5:52 pm, Sean Gleann wrote:
> As far as I can see, I have to specify the WORKINGDIRECTORY to establish
> the starting point for the DUMP operation, then use INCLUDE to _explicitly_
> specify the files I want. The available documentation states:
> "DFSMSdss does not provide wildcard support when processing UNIX files."
> which, for my purposes, is a complete show-stopper.

--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Andrew Rowley]

I haven't tested it myself, but what I would hope is that it works like 
unix utilities, where the file you specify could actually be a directory.


It is pretty common when using tar etc. to set the working directory, 
and specify e.g. "." (a dot) to select the current directory, or specify 
a subdirectory name.


You can then restore to a different location by setting a different 
working directory before the restore, i.e. all names are relative to the 
working directory.


On 29/09/2020 5:52 pm, Sean Gleann wrote:

As far as I can see, I have to specify the WORKINGDIRECTORY to establish
the starting point for the DUMP operation, then use INCLUDE to _explicitly_
specify the files I want. The available documentation states:
"DFSMSdss does not provide wildcard support when processing UNIX files."
which, for my purposes, is a complete show-stopper.


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Sean Gleann]

Wayne: Yes, it does look like each file or path has to be explicitly defined

Paul:
'...akin to asking DFMSMdss to select individual PDS members' is an analogy
I had not seen. Thank you. And of course, DFSMSdss has never been able to
do this and it's unlikely it ever will;
'...filenames containing NL...' Again, something I had not considered. I
can confidently say that in the situation that is driving my investigation
that does not happen _now_, but that's no guarantee it won't occur in the
future;
'...use 'pax'...' That's what we do now and it is precisely the thing I'm
trying to move away from. We have data files for a specific system that
consist of a 'z/OS files component' and a 'USS files component'. Both are
dumped in separate independent jobs, and we see a danger that the two
resulting 'dump' files could conceivably get out of synchronisation.

It looks like what I want is not possible at present and is unlikely to be
so in the future.

Thanks for your responses, Gentlemen. I'm going to abandon this particular
investigation for now.

On Tue, 29 Sep 2020 at 16:19, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 29 Sep 2020 08:52:38 +0100, Sean Gleann  wrote:
>
> >I'm currently investigating the use of DFDSS DUMP PATH to secure data held
> >in UNIX files and folders.
> >...
> >"DFSMSdss does not provide wildcard support when processing UNIX files."
> >...
> >I can see a possible method of including a massaged version of 'ls' output
> >in the INCLUDE parameter, but I don't see this as a particularly workable
> >solution.
> >
> The better utility for that is "find" rather than "ls".  "find" supports
> wildcards
> and boolean expressions; "ls" supports neither.  The massaging would need
> to protect special characters with a scheme supported by DFSMSdss.
> Filenames containing NL are a particular challenge.
>
> ALas, z/OS's "find" does not support the precious "-print0" extension.
>
> What you're asking is akin to asking DFSMSdss to select individual PDS
> members.
>
> >Also, with a DUMP of data comes the requirement to be able to RESTORE it
> to
> >- possibly - a different WORKINGDIRECTORY, but I haven't got that far yet.
> >
> Use 'pax".  Mr. Natural sez, Use the right tool for the job.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Paul Gilmartin]

On Tue, 29 Sep 2020 08:52:38 +0100, Sean Gleann  wrote:

>I'm currently investigating the use of DFDSS DUMP PATH to secure data held
>in UNIX files and folders.
>...
>"DFSMSdss does not provide wildcard support when processing UNIX files."
>...
>I can see a possible method of including a massaged version of 'ls' output
>in the INCLUDE parameter, but I don't see this as a particularly workable
>solution.
>
The better utility for that is "find" rather than "ls".  "find" supports 
wildcards
and boolean expressions; "ls" supports neither.  The massaging would need
to protect special characters with a scheme supported by DFSMSdss.
Filenames containing NL are a particular challenge.

ALas, z/OS's "find" does not support the precious "-print0" extension.

What you're asking is akin to asking DFSMSdss to select individual PDS members.
 
>Also, with a DUMP of data comes the requirement to be able to RESTORE it to
>- possibly - a different WORKINGDIRECTORY, but I haven't got that far yet.
>
Use 'pax".  Mr. Natural sez, Use the right tool for the job.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS support for ZFS files query

[Wayne Bickerdike]

It appears that you have to specify the paths as separate include
statements.

I would use a USS REXX script using readdir and build the include
statements.

I've done something similar to chase file names down from a starting
directory to build a second shell script for a bunch of sed commands.

On Tue, Sep 29, 2020 at 5:53 PM Sean Gleann  wrote:

> I'm currently investigating the use of DFDSS DUMP PATH to secure data held
> in UNIX files and folders.
>
> As far as I can see, I have to specify the WORKINGDIRECTORY to establish
> the starting point for the DUMP operation, then use INCLUDE to _explicitly_
> specify the files I want. The available documentation states:
> "DFSMSdss does not provide wildcard support when processing UNIX files."
> which, for my purposes, is a complete show-stopper.
>
> The subject UNIX folder contain many hundreds, perhaps thousands, of
> individual files and sub-folders (and sub-sub-folders, etc). What I want to
> do is to dump the complete contents of a UNIX folder in a way analogous to
> dumping all z/OS files with a common set of HLQs.
>
> I can see a possible method of including a massaged version of 'ls' output
> in the INCLUDE parameter, but I don't see this as a particularly workable
> solution.
>
> Am I reading things wrongly and missing a vital point here? Does anyone
> know if wildcard support is something that will be made available in the
> future?
>
> Also, with a DUMP of data comes the requirement to be able to RESTORE it to
> - possibly - a different WORKINGDIRECTORY, but I haven't got that far yet.
>
> Regards
> Sean
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Graham Harris]

If you are only interested in which datasets are on which volumes, then
DCOLLECT would surely do the job.


On Mon, 22 Jun 2020 at 15:45, Brian France  wrote:

> Many thanks to all the responses!!!
>
> David,
>
>  Thank you!!! This is exactly what we are looking for. I just
> changed a sort to be "volume,a" and pretty much have the report we use
> via fdr compaktor.
>
> Someone asked did this really matter for raid... we use it to recall
> data sets got deleted within the last month but are found to be needed
> as we back up weekly all volumes to tape and run fdr map at that time.
> We can then find the volume it's on so we know which tape to call for.
>
> On 6/18/2020 10:13 AM, David Spiegel wrote:
> > Hi Brian,
> > Please discard all of those other weak-kneed potential solutions. This
> > one is the Cadillac!
> > Here is a JCL sample that will not only map 1 volume, but, will also
> > include maps of all volumes with a common prefix (think SMS Storage
> > Group):
> > //STEP001 EXEC PGM=IKJEFT01
> > //STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
> > //SYSTSPRT DD SYSOUT=*
> > //SYSTSIN  DD *
> >   VTOC STG0 -
> >CAT -
> >LIM(CAT NE C) -
> >   PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
> >   VOLUME DSNAME))
> > //STEP002 EXEC PGM=IKJEFT01
> > //STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
> > //SYSTSPRT DD SYSOUT=*
> > //SYSTSIN  DD *
> >   VTOC STG0 -
> >CAT -
> > /* LIM(CAT NE C) */ -
> >   PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
> >   VOLUME DSNAME))
> > //STEP003 EXEC PGM=IKJEFT01
> > //STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
> > //SYSTSPRT DD SYSOUT=*
> > //SYSTSIN  DD *
> >   VTOC STG0 -
> >CAT -
> > /* LIM(CAT NE C) */ -
> > SORT(ALLOC,D) -
> >   PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
> >   VOLUME DSNAME))
> > //STEP004 EXEC PGM=IKJEFT01
> > //STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
> > //SYSTSPRT DD SYSOUT=*
> > //SYSTSIN  DD *
> >   VTOC STG0 -
> >CAT -
> > /* LIM(CAT NE C) */ -
> > SORT(UNUSED,D) -
> >   PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
> >   VOLUME DSNAME))
> >
> > STEP001 - Find all Datasets on all volumes whose VOLSER starts with
> > STG0 that are not Cataloged or are Catalog Entries with no actual Dataset
> > STEP002 - Find all Datasets on all volumes whose VOLSER starts with
> > STG0 that are Cataloged
> > STEP003 - Find all Datasets on all volumes whose VOLSER starts with
> > STG0 that are Cataloged. Print output by descending sort of Allocated
> > space
> > STEP004 - Find all Datasets on all volumes whose VOLSER starts with
> > STG0 that are Cataloged. Print output by descending sort of Unused space
> >
> > Please also note that you can search a volume (or range of volumes)
> > for partial DSNAMEs, even when the partial DSNAME does not contain an
> > HLQ. (This may take a while and should be used with caution.)
> > VTOC runs in TSO interactively or batch.
> >
> > Regards,
> > David
> >
> > On 2020-06-18 09:46, Brian France wrote:
> >> Howdy Dave,
> >>
> >>I will have a look at it. Thanks...
> >>
> >> On 6/18/2020 9:01 AM, David Spiegel wrote:
> >>> Hi Brian,
> >>> You may be interested in File 112 on the "CBT Tape" (cbttape.org) .
> >>> I've been using it for more than 35 years and it has many filtering
> >>> and print options.
> >>>
> >>> Regards,
> >>> David
> >>>
> >>> On 2020-06-18 08:53, Brian France wrote:
>   I can't find a dfdss equivalent to fdr's map. I see the print
>  command but can't seem to get a whole volume list of data sets as
>  we do with fdr's map. If it exists would someone please point me to
>  it... THANX!!!
> 
> >>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Brian W. France
> Systems Administrator (Mainframe)
> Pennsylvania State University
> Penn State IT - Infrastructure/SYSARC
> Rm 25 Shields Bldg., University Park, Pa. 16802
> 814-863-4739
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the 

Re: dfdss equivalent to fdr map

[Brian France]

Many thanks to all the responses!!!

David,

    Thank you!!! This is exactly what we are looking for. I just 
changed a sort to be "volume,a" and pretty much have the report we use 
via fdr compaktor.


   Someone asked did this really matter for raid... we use it to recall 
data sets got deleted within the last month but are found to be needed 
as we back up weekly all volumes to tape and run fdr map at that time. 
We can then find the volume it's on so we know which tape to call for.


On 6/18/2020 10:13 AM, David Spiegel wrote:

Hi Brian,
Please discard all of those other weak-kneed potential solutions. This 
one is the Cadillac!
Here is a JCL sample that will not only map 1 volume, but, will also 
include maps of all volumes with a common prefix (think SMS Storage 
Group):

//STEP001 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
   LIM(CAT NE C) -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))
//STEP002 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
    /* LIM(CAT NE C) */ -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))
//STEP003 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
    /* LIM(CAT NE C) */ -
    SORT(ALLOC,D) -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))
//STEP004 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
    /* LIM(CAT NE C) */ -
    SORT(UNUSED,D) -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))

STEP001 - Find all Datasets on all volumes whose VOLSER starts with 
STG0 that are not Cataloged or are Catalog Entries with no actual Dataset
STEP002 - Find all Datasets on all volumes whose VOLSER starts with 
STG0 that are Cataloged
STEP003 - Find all Datasets on all volumes whose VOLSER starts with 
STG0 that are Cataloged. Print output by descending sort of Allocated 
space
STEP004 - Find all Datasets on all volumes whose VOLSER starts with 
STG0 that are Cataloged. Print output by descending sort of Unused space


Please also note that you can search a volume (or range of volumes) 
for partial DSNAMEs, even when the partial DSNAME does not contain an 
HLQ. (This may take a while and should be used with caution.)

VTOC runs in TSO interactively or batch.

Regards,
David

On 2020-06-18 09:46, Brian France wrote:

Howdy Dave,

   I will have a look at it. Thanks...

On 6/18/2020 9:01 AM, David Spiegel wrote:

Hi Brian,
You may be interested in File 112 on the "CBT Tape" (cbttape.org) . 
I've been using it for more than 35 years and it has many filtering 
and print options.


Regards,
David

On 2020-06-18 08:53, Brian France wrote:
 I can't find a dfdss equivalent to fdr's map. I see the print 
command but can't seem to get a whole volume list of data sets as 
we do with fdr's map. If it exists would someone please point me to 
it... THANX!!!




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [External] Re: dfdss equivalent to fdr map

[Pommier, Rex]

Yes, because z/OS (well, the allocation routines anyway) knows nothing of the 
back-end storage.  As far as z/OS is concerned its data is still sitting on 
SLED 3390 volumes so things like free extent sizes and so on still matter.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tim 
Hare
Sent: Saturday, June 20, 2020 9:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: dfdss equivalent to fdr map

Question: does it really matter with a volume that's a virtual thing 
implemented on a RAID array? 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Clark Morris]

[Default] On 20 Jun 2020 19:33:23 -0700, in bit.listserv.ibm-main
haresystemssupp...@comcast.net (Tim Hare) wrote:

>Question: does it really matter with a volume that's a virtual thing 
>implemented on a RAID array? 

Number of extents still would matter.  Also if the data set was
allocated in tracks rather than cylinders there could bee more end of
extent checking.

Clark Morris
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Tim Hare]

Question: does it really matter with a volume that's a virtual thing 
implemented on a RAID array?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Leon Trafalski]

DFDSS defrag with NORUN will provide a map.

PAGE 0001 5695-DF175  DFSMSDSS V2R03.0 DATA SET SERVICES 
2020.171 08:45


ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN 
NORUN MODE


 DEFRAG DDNAME(DISKIN) -

FRAGI(020) -

EXCLUDE(LIST( -

   **.PROCLIB, -

   SYS1.**, -

   SYS2.**, -

   SYS3.**, -

   SYS9.**, -

   ))

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DEFRAG '

ADR109I (R/I)-RI01 (01), 2020.171 08:45:59 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED


ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK

ADR006I (001)-STEND(01), 2020.171 08:45:59 EXECUTION BEGINS

ADR208I (001)-DFRGD(01), 2020.171 08:45:59 BEGINNING STATISTICS ON WKL600:

  FREE CYLINDERS 00029603

  FREE TRACKS 0009

  FREE EXTENTS 0002

  LARGEST FREE EXTENT (CYL,TRK) 00029603,00

  FRAGMENTATION INDEX  0.000

  PERCENT FREE SPACE 98

ADR234I (001)-DFANL(01), SEQUENCE   C:H 1 -  C:H 2  EXTENT  DESCRIPTION

ADR235I (001)-DFANL(01), 0001 :0 :0      VOLUME 
LABEL


ADR235I (001)-DFANL(01), 0008 :1 :5    0001  
SYS20158.T235401.RA000.ZTOMCN.SYSIN.H01


ADR235I (001)-DFANL(01), 0024 :6 :A    0001  
SYS20158.T235403.RA000.ZTOMD5.SYSIN.H01


ADR235I (001)-DFANL(01), 0098 :B :B    0001  
SYS20166.T202409.RA000.FUWFWFR.CARDIN.H01


ADR235I (001)-DFANL(01), 0099 :C :C    0001  
SYS20166.T203538.RA000.FUWFWTR.CARDIN.H01


ADR235I (001)-DFANL(01), 0100 :D :D    0001  
SYS20166.T212104.RA000.TXCQAIR.CARDIN.H01


ADR235I (001)-DFANL(01), 0101 :E :E    0001  
SYS20159.T213138.RA000.TXCQAFR.CARDIN2.H03


ADR235I (001)-DFANL(01), 0005 0001:0 000A:E    0001  
SYS1.VTOCIX.WKL600


ADR235I (001)-DFANL(01), 0002 000B:0 003C:E      VOLUME 
TABLE OF CONTENTS


ADR235I (001)-DFANL(01), 0006 003D:0 0046:E    0001  
SYS20158.T235401.RA000.EMCCX.R0100587


ADR235I (001)-DFANL(01), 0007 0047:0 0050:E    0001  
SYS20158.T235401.RA000.EMCCX.R0100589


ADR235I (001)-DFANL(01), 0009 0051:0 0051:E    0001  
SYS20158.T235401.RA000.ZTOMOC0.TMPCMDU.H01


ADR235I (001)-DFANL(01), 0010 0052:0 0052:E    0001 
SYS20158.T235401.RA000.ZTOMDSH.TMPCMDU.H01



On 6/19/2020 6:14 AM, Steve Horein wrote:

That was my first thought as well, but didn't remember to execute samples
today.

On Thu, Jun 18, 2020 at 1:42 PM Roger Lowe  wrote:


On Thu, 18 Jun 2020 08:53:37 -0400, Brian France  wrote:


  I can't find a dfdss equivalent to fdr's map. I see the print command
but can't seem to get a whole volume list of data sets as we do with
fdr's map. If it exists would someone please point me to it... THANX!!!


Have you tried using IEHLIST?

//S001 EXEC PGM=IEHLIST
//FILE DD UNIT=DISK,VOL=SER=??,DISP=SHR
//SYSPRINT DD   SYSOUT=Z
//SYSINDD   *
   LISTVTOC VOL=3390=??


Roger

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
regards
Leon


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Steve Horein]

That was my first thought as well, but didn't remember to execute samples
today.

On Thu, Jun 18, 2020 at 1:42 PM Roger Lowe  wrote:

> On Thu, 18 Jun 2020 08:53:37 -0400, Brian France  wrote:
>
> >  I can't find a dfdss equivalent to fdr's map. I see the print command
> >but can't seem to get a whole volume list of data sets as we do with
> >fdr's map. If it exists would someone please point me to it... THANX!!!
> >
>
> Have you tried using IEHLIST?
>
> //S001 EXEC PGM=IEHLIST
> //FILE DD UNIT=DISK,VOL=SER=??,DISP=SHR
> //SYSPRINT DD   SYSOUT=Z
> //SYSINDD   *
>   LISTVTOC VOL=3390=??
>
>
> Roger
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Roger Lowe]

On Thu, 18 Jun 2020 08:53:37 -0400, Brian France  wrote:

>  I can't find a dfdss equivalent to fdr's map. I see the print command
>but can't seem to get a whole volume list of data sets as we do with
>fdr's map. If it exists would someone please point me to it... THANX!!!
>

Have you tried using IEHLIST?

//S001 EXEC PGM=IEHLIST
//FILE DD UNIT=DISK,VOL=SER=??,DISP=SHR
//SYSPRINT DD   SYSOUT=Z   
//SYSINDD   *  
  LISTVTOC VOL=3390=??


Roger

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Seymour J Metz]

The CBT tape has lots of VTOC display programs. I would use Gerhard's version 
of IEHVTOC, but I'm sure that it's not the only one that can sort extents by 
address.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Brian France [b...@psu.edu]
Sent: Thursday, June 18, 2020 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: dfdss equivalent to fdr map

  I can't find a dfdss equivalent to fdr's map. I see the print command
but can't seem to get a whole volume list of data sets as we do with
fdr's map. If it exists would someone please point me to it... THANX!!!

--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [External] Re: dfdss equivalent to fdr map

[Brian France]

No that's what I get for not being clearer in what I was looking for 
this early in the morning. :-)


On 6/18/2020 9:56 AM, Pommier, Rex wrote:

In John's defense, when I saw "volume map" and "dfdss" in the same sentence, I 
thought like John did, that you wanted a tape volume map.  That's what I get for thinking this 
early in the morning.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Thursday, June 18, 2020 8:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: dfdss equivalent to fdr map

Hi John,
I am well aware of this capability, and I really do not want to appear to be 
overly chauvinistic, BUT, VTOC (File 112 on the CBT Tape) beats the pants off 
of your solution.

Regards,
David

On 2020-06-18 09:36, John McKown wrote:

On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:


I can't find a dfdss equivalent to fdr's map. I see the print
command but can't seem to get a whole volume list of data sets as we
do with fdr's map. If it exists would someone please point me to it... THANX!!!


I don't know what an FDR MAP does. but if you need to know what
datasets are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'

Something like:

//JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
// REGION=0M
//SYSPRINT DD  SYSOUT=*
//TAPE1DD  DSN=JES2DISK.ADRDSSU,
// DISP=OLD
//SYSINDD  *
   RESTORE  -
  DATASET( -
INCL( -
 **-
  ) -
 ) -
  IDD(TAPE1) -
  ADMINISTRATOR -
  TOL(ENQF) WAIT(0,0)





--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC Rm 25 Shields Bldg., University
Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

-
- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[David Spiegel]

Hi Brian,
Please discard all of those other weak-kneed potential solutions. This 
one is the Cadillac!
Here is a JCL sample that will not only map 1 volume, but, will also 
include maps of all volumes with a common prefix (think SMS Storage Group):

//STEP001 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
   LIM(CAT NE C) -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))
//STEP002 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
    /* LIM(CAT NE C) */ -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))
//STEP003 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
    /* LIM(CAT NE C) */ -
    SORT(ALLOC,D) -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))
//STEP004 EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=FILE135.PDS
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  VTOC STG0 -
   CAT -
    /* LIM(CAT NE C) */ -
    SORT(UNUSED,D) -
  PRINT(NEW (CAT ALLOC  UNUSED PCT EX DSO RFM LRECL BLKSZ CDATE REFDT -
  VOLUME DSNAME))

STEP001 - Find all Datasets on all volumes whose VOLSER starts with STG0 
that are not Cataloged or are Catalog Entries with no actual Dataset
STEP002 - Find all Datasets on all volumes whose VOLSER starts with STG0 
that are Cataloged
STEP003 - Find all Datasets on all volumes whose VOLSER starts with STG0 
that are Cataloged. Print output by descending sort of Allocated space
STEP004 - Find all Datasets on all volumes whose VOLSER starts with STG0 
that are Cataloged. Print output by descending sort of Unused space


Please also note that you can search a volume (or range of volumes) for 
partial DSNAMEs, even when the partial DSNAME does not contain an HLQ. 
(This may take a while and should be used with caution.)

VTOC runs in TSO interactively or batch.

Regards,
David

On 2020-06-18 09:46, Brian France wrote:

Howdy Dave,

   I will have a look at it. Thanks...

On 6/18/2020 9:01 AM, David Spiegel wrote:

Hi Brian,
You may be interested in File 112 on the "CBT Tape" (cbttape.org) . 
I've been using it for more than 35 years and it has many filtering 
and print options.


Regards,
David

On 2020-06-18 08:53, Brian France wrote:
 I can't find a dfdss equivalent to fdr's map. I see the print 
command but can't seem to get a whole volume list of data sets as we 
do with fdr's map. If it exists would someone please point me to 
it... THANX!!!




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Jousma, David]

If you have File Manager, there is a VTOC utility

File Manager Display VTOC Data Set List 
   Row 00137 of 00219 
Command ===>
   Scroll CSR  
Unit*DSN   '**' 
   
DevType *VOLSTATE  ALL SMS SG * 
   
Volumes 1Data sets 105 VSAM   12  non-VSAM 93   
   
VOLSER  CAT500   Trks used 23191   Free   127064  Utilized 15%  
   
Data Set NameSeq Volume Begin CYL-HD 
End CYL-HD Tracks Dsorg Recfm Lrecl Blksize Created   
**   CAT500 **  
   * *   * 
SYS1.APPCTP.DATA   1 CAT500  1248  0  
1249  8   24 VSU 04096 2003.065  
SYS1.APPCTP.INDEX  1 CAT500  1238  1  
1238  11 VSU 04096 2003.065  
SYS1.DFSMS.ACDS.DATA   1 CAT500   321  0   
325 14   75 VSU 04096 2002.355  
SYS1.DFSMS.COMMDS.DATA 1 CAT500   326  0   
330 14   75 VSU 04096 2002.355  
SYS1.DFSMS.SCDS.DATA   1 CAT500  1129  0  
1133 14   75 VSU 04096 2002.355  
SYS1.EQQ.TWS1.CKPT 1 CAT500   131  0   
131 14   15 PSU  82008200 2003.223  
SYS1.EQQ.TWS1.EQQAUDIT.REPORT  1 CAT500   130  0   
130 14   15 PSFBA 133   13300 2003.223  
SYS1.EQQ.TWS1.TRACKLOG 1 CAT500   129  0   
129 14   15 PSVB32756   32760 2003.223  
SYS1.IPLPARM   1 CAT500   552  0   
561 14  150 POFB   806160 2004.014  
SYS1.PAGEDUMP.VCAT500  1 CAT50038  0
44  1   92 PSF  40964096 2020.022  
SYS1.PARMLIB   1 CAT500   733  2   
749  7  246 POFB   80   27920 2004.029  
SYS1.PARMLIB   2 CAT500   187  0   
188 14   30 POFB   80   27920 2004.029  
SYS1.PARMLIB   3 CAT500   189  0   
190 14   30 POFB   80   27920 2004.029  
SYS1.PARMLIB   4 CAT500   210  6   
212  5   30 POFB   80   27920 2004.029  
SYS1.PARMLIB   5 CAT500   215  0   
216 14   30 POFB   80   27920 2004.029  
SYS1.PARMLIB   6 CAT500   217  0   
218 14   30 POFB   80   27920 2004.029  
SYS1.PARMLIB   7 CAT500   119 12   
121 11   30 POFB   80   27920 2004.029  

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Thursday, June 18, 2020 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

forget the PARM=PARM 
will get you (a mess in email) but readable in your SYSOUT 



8C 
4040 4040 4040 4040 4040 4040 4040 4040 4040 4040 *SYS1.NUCLEUS * 
STH STH STH STH STH STH STH STH STH STH * * 
F1E2 E8E2 D9E2 E900 0177 0056  0001   * 1SYS* 
MVO MVCIN MVCK PKA *RSZ.* 
0087   0200 C000 7FF8   0080 8800 ** 
LARL SU SRL *.."8* 
8E00 000F E000 0A00       *...M.%-.* 
SRDA SVC ** 
* * 


8C 
4040 4040 4040 4040 4040 4040 4040 4040 4040 4040 *APK.SAPKMOD1 * 
STH STH STH STH STH STH STH STH STH STH * * 
F1E2 E8E2 D9E2 E900 0177 0056  0001   * 1SYS* 
MVO MVCIN MVCK PKA *RSZ.* 
0087   0200 C000 7FF8   0080 8000 ** 
LARL SU SSM *.."8* 
E000 0B0F E800 0400       ** 
BSM MVCIN SPM *Y...* 
* * 


Carmen Vitullo 

- Original Message -

From: &q

Re: dfdss equivalent to fdr map

[Pommier, Rex]

DITTO or FileManager will produce such a disk volume map.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Thursday, June 18, 2020 8:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: dfdss equivalent to fdr map

FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
dataset and their extents.

Kees


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: 18 June 2020 15:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:

>   I can't find a dfdss equivalent to fdr's map. I see the print 
> command but can't seem to get a whole volume list of data sets as we 
> do with fdr's map. If it exists would someone please point me to it... 
> THANX!!!
>

I don't know what an FDR MAP does. but if you need to know what datasets are on 
a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'

Something like:

//JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
// REGION=0M
//SYSPRINT DD  SYSOUT=*
//TAPE1DD  DSN=JES2DISK.ADRDSSU,
// DISP=OLD
//SYSINDD  *
 RESTORE  -
DATASET( -
  INCL( -
   **-
) -
   ) -
IDD(TAPE1) -
ADMINISTRATOR -
TOL(ENQF) WAIT(0,0)




>
> --
> Brian W. France
> Systems Administrator (Mainframe)
> Pennsylvania State University
> Penn State IT - Infrastructure/SYSARC
> Rm 25 Shields Bldg., University Park, Pa. 16802
> 814-863-4739
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Carmen Vitullo]

forget the PARM=PARM 
will get you (a mess in email) but readable in your SYSOUT 



8C 
4040 4040 4040 4040 4040 4040 4040 4040 4040 4040 *SYS1.NUCLEUS * 
STH STH STH STH STH STH STH STH STH STH * * 
F1E2 E8E2 D9E2 E900 0177 0056  0001   * 1SYS* 
MVO MVCIN MVCK PKA *RSZ.* 
0087   0200 C000 7FF8   0080 8800 ** 
LARL SU SRL *.."8* 
8E00 000F E000 0A00       *...M.%-.* 
SRDA SVC ** 
* * 


8C 
4040 4040 4040 4040 4040 4040 4040 4040 4040 4040 *APK.SAPKMOD1 * 
STH STH STH STH STH STH STH STH STH STH * * 
F1E2 E8E2 D9E2 E900 0177 0056  0001   * 1SYS* 
MVO MVCIN MVCK PKA *RSZ.* 
0087   0200 C000 7FF8   0080 8000 ** 
LARL SU SSM *.."8* 
E000 0B0F E800 0400       ** 
BSM MVCIN SPM *Y...* 
* * 


Carmen Vitullo 

- Original Message -

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 18, 2020 8:53:04 AM 
Subject: Re: dfdss equivalent to fdr map 

this may help 
quick and dirty 

JCL to dump the VTOC on a DASD volume: 

//CC10 EXEC PGM=AMASPZAP, 
// PARM=parm 
//SYSPRINT DD SYSOUT=* 
//SYSLIB DD DSN=FORMAT4.DSCB,DISP=OLD,UNIT=3390, 
// VOL=SER=mypack,DCB=KEYLEN=44 
//SYSIN DD * 
ABSDUMPT ALL 

Carmen Vitullo 

- Original Message - 

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 18, 2020 8:48:14 AM 
Subject: Re: dfdss equivalent to fdr map 

ZAP ? 
AMASPZAP I may have some jcl let me look 


Carmen Vitullo 

- Original Message - 

From: "Brian France"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 18, 2020 8:45:19 AM 
Subject: Re: dfdss equivalent to fdr map 

That's what we're looking for and DFDSS does not seem to have the 
equivalent 

On 6/18/2020 9:42 AM, Vernooij, Kees (ITOP NM) - KLM wrote: 
> FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
> dataset and their extents. 
> 
> Kees 
> 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List  On Behalf Of 
> John McKown 
> Sent: 18 June 2020 15:36 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: dfdss equivalent to fdr map 
> 
> On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote: 
> 
>> I can't find a dfdss equivalent to fdr's map. I see the print command 
>> but can't seem to get a whole volume list of data sets as we do with 
>> fdr's map. If it exists would someone please point me to it... THANX!!! 
>> 
> I don't know what an FDR MAP does. but if you need to know what datasets 
> are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN' 
> 
> Something like: 
> 
> //JS010 EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN', 
> // REGION=0M 
> //SYSPRINT DD SYSOUT=* 
> //TAPE1 DD DSN=JES2DISK.ADRDSSU, 
> // DISP=OLD 
> //SYSIN DD * 
> RESTORE - 
> DATASET( - 
> INCL( - 
> ** - 
> ) - 
> ) - 
> IDD(TAPE1) - 
> ADMINISTRATOR - 
> TOL(ENQF) WAIT(0,0) 
> 
> 
> 
> 
>> -- 
>> Brian W. France 
>> Systems Administrator (Mainframe) 
>> Pennsylvania State University 
>> Penn State IT - Infrastructure/SYSARC 
>> Rm 25 Shields Bldg., University Park, Pa. 16802 
>> 814-863-4739 
>> b...@psu.edu 
>> 
>> There's no such thing as The Cloud - it's just someone else's computer... 
>> 
>> "To make an apple pie from scratch, you must first invent the universe." 
>> 
>> Carl Sagan 
>> 
>> -- 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>> 
> 
-- 
Brian W. France 
Systems Administrator (Mainframe) 
Pennsylvania State University 
Penn State IT - Infrastructure/SYSARC 
Rm 25 Shields Bldg., University Park, Pa. 16802 
814-863-4739 
b...@psu.edu 

There's no such thing as The Cloud - it's just someone else's computer... 

"To make an apple pie from scratch, you must first invent the universe." 

Carl Sagan 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [External] Re: dfdss equivalent to fdr map

[Pommier, Rex]

In John's defense, when I saw "volume map" and "dfdss" in the same sentence, I 
thought like John did, that you wanted a tape volume map.  That's what I get 
for thinking this early in the morning.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Thursday, June 18, 2020 8:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: dfdss equivalent to fdr map

Hi John,
I am well aware of this capability, and I really do not want to appear to be 
overly chauvinistic, BUT, VTOC (File 112 on the CBT Tape) beats the pants off 
of your solution.

Regards,
David

On 2020-06-18 09:36, John McKown wrote:
> On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:
>
>>I can't find a dfdss equivalent to fdr's map. I see the print 
>> command but can't seem to get a whole volume list of data sets as we 
>> do with fdr's map. If it exists would someone please point me to it... 
>> THANX!!!
>>
> I don't know what an FDR MAP does. but if you need to know what 
> datasets are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'
>
> Something like:
>
> //JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
> // REGION=0M
> //SYSPRINT DD  SYSOUT=*
> //TAPE1DD  DSN=JES2DISK.ADRDSSU,
> // DISP=OLD
> //SYSINDD  *
>   RESTORE  -
>  DATASET( -
>INCL( -
> **-
>  ) -
> ) -
>  IDD(TAPE1) -
>  ADMINISTRATOR -
>  TOL(ENQF) WAIT(0,0)
>
>
>
>
>> --
>> Brian W. France
>> Systems Administrator (Mainframe)
>> Pennsylvania State University
>> Penn State IT - Infrastructure/SYSARC Rm 25 Shields Bldg., University 
>> Park, Pa. 16802
>> 814-863-4739
>> b...@psu.edu
>>
>> There's no such thing as The Cloud - it's just someone else's computer...
>>
>> "To make an apple pie from scratch, you must first invent the universe."
>>
>> Carl Sagan
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO 
>> IBM-MAIN
>>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Vernooij, Kees (ITOP NM) - KLM]

CA-DISK has a similar function: Volume Map. The report is a little less useful 
(to me) so I process it with SAS to generate an FDR like report.

Kees.


Volume Map by CCH.   
 
Volser=SYSR02
 
Dsname  LengthExtent  CCH
 
  *VTOC*  270   1  16:00 
SYSRECV.TSS.MVST.VSAMBKUP   1   2  40:10 
SYSRECV.TSS.MVSX.VSAMBKUP   1   2  40:11 
SYSRECV.TSS.MVSY.VSAMBKUP   1   2  40:12 
SYSRECV.SAR.PROD.SARRECV1   1  40:13 
SYSRECV.TSS.MVSC.VSAMBKUP   1   2  40:14 
SYSRECV.TSS.MVST.VSAMBKUP  15   1  41:00 
  **FREE SPACE**   14  42:00 
SYSRECV.ICF.VXSYS30.ALIASES.G8056V001   1  42:14 
SYSRECV.ICF.VYSYS30.ALIASES.G8056V001   1  43:00 
  **FREE SPACE**3  43:01 
SYSRECV.ICF.RCVR#C.ALIASES.G6936V00 1   1  43:04 
SYSRECV.ICF.WARE#1.ALIASES.G0460V00 1   1  43:05 
SYSRECV.ICF.WARE#2.ALIASES.G0831V00 1   1  43:06 
SYSRECV.ICF.USER#2.ALIASES.G0014V00 5   1  43:07 
SYSRECV.ICF.DEPT#1.ALIASES.G0012V00 2   1  43:12 
SYSRECV.ICF.PROD#1.ALIASES.G0011V00 1   1  43:14


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: 18 June 2020 15:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

That's what we're looking for and DFDSS does not seem to have the 
equivalent

On 6/18/2020 9:42 AM, Vernooij, Kees (ITOP NM) - KLM wrote:
> FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
> dataset and their extents.
>
> Kees
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> John McKown
> Sent: 18 June 2020 15:36
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: dfdss equivalent to fdr map
>
> On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:
>
>>I can't find a dfdss equivalent to fdr's map. I see the print command
>> but can't seem to get a whole volume list of data sets as we do with
>> fdr's map. If it exists would someone please point me to it... THANX!!!
>>
> I don't know what an FDR MAP does. but if you need to know what datasets
> are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'
>
> Something like:
>
> //JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
> // REGION=0M
> //SYSPRINT DD  SYSOUT=*
> //TAPE1DD  DSN=JES2DISK.ADRDSSU,
> // DISP=OLD
> //SYSINDD  *
>   RESTORE  -
>  DATASET( -
>INCL( -
> **-
>  ) -
> ) -
>  IDD(TAPE1) -
>  ADMINISTRATOR -
>  TOL(ENQF) WAIT(0,0)
>
>
>
>
>> --
>> Brian W. France
>> Systems Administrator (Mainframe)
>> Pennsylvania State University
>> Penn State IT - Infrastructure/SYSARC
>> Rm 25 Shields Bldg., University Park, Pa. 16802
>> 814-863-4739
>> b...@psu.edu
>>
>> There's no such thing as The Cloud - it's just someone else's computer...
>>
>> "To make an apple pie from scratch, you must first invent the universe."
>>
>> Carl Sagan
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
-- 
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our 

Re: dfdss equivalent to fdr map

[Carmen Vitullo]

this may help 
quick and dirty 

JCL to dump the VTOC on a DASD volume: 

//CC10 EXEC PGM=AMASPZAP, 
// PARM=parm 
//SYSPRINT DD SYSOUT=* 
//SYSLIB DD DSN=FORMAT4.DSCB,DISP=OLD,UNIT=3390, 
// VOL=SER=mypack,DCB=KEYLEN=44 
//SYSIN DD * 
ABSDUMPT ALL 

Carmen Vitullo 

- Original Message -

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 18, 2020 8:48:14 AM 
Subject: Re: dfdss equivalent to fdr map 

ZAP ? 
AMASPZAP I may have some jcl let me look 


Carmen Vitullo 

- Original Message - 

From: "Brian France"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 18, 2020 8:45:19 AM 
Subject: Re: dfdss equivalent to fdr map 

That's what we're looking for and DFDSS does not seem to have the 
equivalent 

On 6/18/2020 9:42 AM, Vernooij, Kees (ITOP NM) - KLM wrote: 
> FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
> dataset and their extents. 
> 
> Kees 
> 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List  On Behalf Of 
> John McKown 
> Sent: 18 June 2020 15:36 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: dfdss equivalent to fdr map 
> 
> On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote: 
> 
>> I can't find a dfdss equivalent to fdr's map. I see the print command 
>> but can't seem to get a whole volume list of data sets as we do with 
>> fdr's map. If it exists would someone please point me to it... THANX!!! 
>> 
> I don't know what an FDR MAP does. but if you need to know what datasets 
> are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN' 
> 
> Something like: 
> 
> //JS010 EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN', 
> // REGION=0M 
> //SYSPRINT DD SYSOUT=* 
> //TAPE1 DD DSN=JES2DISK.ADRDSSU, 
> // DISP=OLD 
> //SYSIN DD * 
> RESTORE - 
> DATASET( - 
> INCL( - 
> ** - 
> ) - 
> ) - 
> IDD(TAPE1) - 
> ADMINISTRATOR - 
> TOL(ENQF) WAIT(0,0) 
> 
> 
> 
> 
>> -- 
>> Brian W. France 
>> Systems Administrator (Mainframe) 
>> Pennsylvania State University 
>> Penn State IT - Infrastructure/SYSARC 
>> Rm 25 Shields Bldg., University Park, Pa. 16802 
>> 814-863-4739 
>> b...@psu.edu 
>> 
>> There's no such thing as The Cloud - it's just someone else's computer... 
>> 
>> "To make an apple pie from scratch, you must first invent the universe." 
>> 
>> Carl Sagan 
>> 
>> -- 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>> 
> 
-- 
Brian W. France 
Systems Administrator (Mainframe) 
Pennsylvania State University 
Penn State IT - Infrastructure/SYSARC 
Rm 25 Shields Bldg., University Park, Pa. 16802 
814-863-4739 
b...@psu.edu 

There's no such thing as The Cloud - it's just someone else's computer... 

"To make an apple pie from scratch, you must first invent the universe." 

Carl Sagan 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[David Spiegel]

Hi John,
I am well aware of this capability, and I really do not want to appear 
to be overly chauvinistic, BUT, VTOC (File 112 on the CBT Tape) beats 
the pants off of your solution.


Regards,
David

On 2020-06-18 09:36, John McKown wrote:

On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:


   I can't find a dfdss equivalent to fdr's map. I see the print command
but can't seem to get a whole volume list of data sets as we do with
fdr's map. If it exists would someone please point me to it... THANX!!!


I don't know what an FDR MAP does. but if you need to know what datasets
are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'

Something like:

//JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
// REGION=0M
//SYSPRINT DD  SYSOUT=*
//TAPE1DD  DSN=JES2DISK.ADRDSSU,
// DISP=OLD
//SYSINDD  *
  RESTORE  -
 DATASET( -
   INCL( -
**-
 ) -
) -
 IDD(TAPE1) -
 ADMINISTRATOR -
 TOL(ENQF) WAIT(0,0)





--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Carmen Vitullo]

ZAP ? 
AMASPZAP I may have some jcl let me look 


Carmen Vitullo 

- Original Message -

From: "Brian France"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 18, 2020 8:45:19 AM 
Subject: Re: dfdss equivalent to fdr map 

That's what we're looking for and DFDSS does not seem to have the 
equivalent 

On 6/18/2020 9:42 AM, Vernooij, Kees (ITOP NM) - KLM wrote: 
> FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
> dataset and their extents. 
> 
> Kees 
> 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List  On Behalf Of 
> John McKown 
> Sent: 18 June 2020 15:36 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: dfdss equivalent to fdr map 
> 
> On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote: 
> 
>> I can't find a dfdss equivalent to fdr's map. I see the print command 
>> but can't seem to get a whole volume list of data sets as we do with 
>> fdr's map. If it exists would someone please point me to it... THANX!!! 
>> 
> I don't know what an FDR MAP does. but if you need to know what datasets 
> are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN' 
> 
> Something like: 
> 
> //JS010 EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN', 
> // REGION=0M 
> //SYSPRINT DD SYSOUT=* 
> //TAPE1 DD DSN=JES2DISK.ADRDSSU, 
> // DISP=OLD 
> //SYSIN DD * 
> RESTORE - 
> DATASET( - 
> INCL( - 
> ** - 
> ) - 
> ) - 
> IDD(TAPE1) - 
> ADMINISTRATOR - 
> TOL(ENQF) WAIT(0,0) 
> 
> 
> 
> 
>> -- 
>> Brian W. France 
>> Systems Administrator (Mainframe) 
>> Pennsylvania State University 
>> Penn State IT - Infrastructure/SYSARC 
>> Rm 25 Shields Bldg., University Park, Pa. 16802 
>> 814-863-4739 
>> b...@psu.edu 
>> 
>> There's no such thing as The Cloud - it's just someone else's computer... 
>> 
>> "To make an apple pie from scratch, you must first invent the universe." 
>> 
>> Carl Sagan 
>> 
>> -- 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>> 
> 
-- 
Brian W. France 
Systems Administrator (Mainframe) 
Pennsylvania State University 
Penn State IT - Infrastructure/SYSARC 
Rm 25 Shields Bldg., University Park, Pa. 16802 
814-863-4739 
b...@psu.edu 

There's no such thing as The Cloud - it's just someone else's computer... 

"To make an apple pie from scratch, you must first invent the universe." 

Carl Sagan 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Allan Staller]

Adrdssu defrag will produce some of the same information.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: Thursday, June 18, 2020 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

That's what we're looking for and DFDSS does not seem to have the equivalent

On 6/18/2020 9:42 AM, Vernooij, Kees (ITOP NM) - KLM wrote:
> FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
> dataset and their extents.
>
> Kees
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of John McKown
> Sent: 18 June 2020 15:36
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: dfdss equivalent to fdr map
>
> On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:
>
>>I can't find a dfdss equivalent to fdr's map. I see the print
>> command but can't seem to get a whole volume list of data sets as we
>> do with fdr's map. If it exists would someone please point me to it... 
>> THANX!!!
>>
> I don't know what an FDR MAP does. but if you need to know what
> datasets are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'
>
> Something like:
>
> //JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
> // REGION=0M
> //SYSPRINT DD  SYSOUT=*
> //TAPE1DD  DSN=JES2DISK.ADRDSSU,
> // DISP=OLD
> //SYSINDD  *
>   RESTORE  -
>  DATASET( -
>INCL( -
> **-
>  ) -
> ) -
>  IDD(TAPE1) -
>  ADMINISTRATOR -
>  TOL(ENQF) WAIT(0,0)
>
>
>
>
>> --
>> Brian W. France
>> Systems Administrator (Mainframe)
>> Pennsylvania State University
>> Penn State IT - Infrastructure/SYSARC Rm 25 Shields Bldg., University
>> Park, Pa. 16802
>> 814-863-4739
>> b...@psu.edu
>>
>> There's no such thing as The Cloud - it's just someone else's computer...
>>
>> "To make an apple pie from scratch, you must first invent the universe."
>>
>> Carl Sagan
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>>
>
--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Brian France]

Howdy Dave,

   I will have a look at it. Thanks...

On 6/18/2020 9:01 AM, David Spiegel wrote:

Hi Brian,
You may be interested in File 112 on the "CBT Tape" (cbttape.org) . 
I've been using it for more than 35 years and it has many filtering 
and print options.


Regards,
David

On 2020-06-18 08:53, Brian France wrote:
 I can't find a dfdss equivalent to fdr's map. I see the print 
command but can't seem to get a whole volume list of data sets as we 
do with fdr's map. If it exists would someone please point me to 
it... THANX!!!




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Brian France]

That's what we're looking for and DFDSS does not seem to have the 
equivalent


On 6/18/2020 9:42 AM, Vernooij, Kees (ITOP NM) - KLM wrote:

FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
dataset and their extents.

Kees


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: 18 June 2020 15:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:


   I can't find a dfdss equivalent to fdr's map. I see the print command
but can't seem to get a whole volume list of data sets as we do with
fdr's map. If it exists would someone please point me to it... THANX!!!


I don't know what an FDR MAP does. but if you need to know what datasets
are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'

Something like:

//JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
// REGION=0M
//SYSPRINT DD  SYSOUT=*
//TAPE1DD  DSN=JES2DISK.ADRDSSU,
// DISP=OLD
//SYSINDD  *
  RESTORE  -
 DATASET( -
   INCL( -
**-
 ) -
) -
 IDD(TAPE1) -
 ADMINISTRATOR -
 TOL(ENQF) WAIT(0,0)





--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Vernooij, Kees (ITOP NM) - KLM]

FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
dataset and their extents.

Kees


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: 18 June 2020 15:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:

>   I can't find a dfdss equivalent to fdr's map. I see the print command
> but can't seem to get a whole volume list of data sets as we do with
> fdr's map. If it exists would someone please point me to it... THANX!!!
>

I don't know what an FDR MAP does. but if you need to know what datasets
are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'

Something like:

//JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
// REGION=0M
//SYSPRINT DD  SYSOUT=*
//TAPE1DD  DSN=JES2DISK.ADRDSSU,
// DISP=OLD
//SYSINDD  *
 RESTORE  -
DATASET( -
  INCL( -
   **-
) -
   ) -
IDD(TAPE1) -
ADMINISTRATOR -
TOL(ENQF) WAIT(0,0)




>
> --
> Brian W. France
> Systems Administrator (Mainframe)
> Pennsylvania State University
> Penn State IT - Infrastructure/SYSARC
> Rm 25 Shields Bldg., University Park, Pa. 16802
> 814-863-4739
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[John McKown]

On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:

>   I can't find a dfdss equivalent to fdr's map. I see the print command
> but can't seem to get a whole volume list of data sets as we do with
> fdr's map. If it exists would someone please point me to it... THANX!!!
>

I don't know what an FDR MAP does. but if you need to know what datasets
are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'

Something like:

//JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
// REGION=0M
//SYSPRINT DD  SYSOUT=*
//TAPE1DD  DSN=JES2DISK.ADRDSSU,
// DISP=OLD
//SYSINDD  *
 RESTORE  -
DATASET( -
  INCL( -
   **-
) -
   ) -
IDD(TAPE1) -
ADMINISTRATOR -
TOL(ENQF) WAIT(0,0)




>
> --
> Brian W. France
> Systems Administrator (Mainframe)
> Pennsylvania State University
> Penn State IT - Infrastructure/SYSARC
> Rm 25 Shields Bldg., University Park, Pa. 16802
> 814-863-4739
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[Vernooij, Kees (ITOP NM) - KLM]

To be precise, MAP is not an FDR function, it is an ABR function, which also 
came along with COMPAKTR. When we dismissed the latter, we also lost the MAP 
function.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: 18 June 2020 14:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: dfdss equivalent to fdr map

  I can't find a dfdss equivalent to fdr's map. I see the print command 
but can't seem to get a whole volume list of data sets as we do with 
fdr's map. If it exists would someone please point me to it... THANX!!!

-- 
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: dfdss equivalent to fdr map

[David Spiegel]

Hi Brian,
You may be interested in File 112 on the "CBT Tape" (cbttape.org) . I've 
been using it for more than 35 years and it has many filtering and print 
options.


Regards,
David

On 2020-06-18 08:53, Brian France wrote:
 I can't find a dfdss equivalent to fdr's map. I see the print command 
but can't seem to get a whole volume list of data sets as we do with 
fdr's map. If it exists would someone please point me to it... THANX!!!




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Nai, Dean]

Personally I am thinking yes because we ran the same backups without 
dumpconditioning and we were able to restore the same volumes with no problems. 


Dean Nai









On 11/15/19, 6:04 AMEST, "IBM Mainframe Discussion List on behalf of Richards, 
Robert B."  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Does any of this apply and/or shed some light in this case seeing that you 
>used DUMPCONDITIONING? See below:
>
>DUMPCONDITIONING — Allows you to make a copy of the source volume in a full 
>volume copy operation—including volume index information—while keeping the 
>target volume online. Use this keyword when you want to create a copy of the 
>source volume for backup purposes, rather than to allow applications to use 
>the target volume.
>
>With DUMPCONDITIONING in effect, the volume serial number of the target volume 
>does not change, and the target volume remains online after the copy. The VVDS 
>and VTOC index names on the target volume do not change to match the target 
>volume serial number; they continue to match the source volume serial number.
>
>In Step 2 , for example, you can include the DUMPCONDITIONING keyword on the 
>full volume copy command to allow the target volume to remain online for 
>dumping.
>
>The target of a full volume copy operation using DUMPCONDITIONING is referred 
>to as a conditioned volume. A full volume dump of a conditioned volume appears 
>as if it were dumped from the original source volume of the copy operation. 
>However, if the conditioned volume is copied back using DUMPCONDITIONING, 
>conditioning is not performed on the original source volume. Instead, DFSMSdss 
>recognizes that it is copying from the target of a previous conditioned-backup 
>and recovers the original source volume.
>
>For example, suppose that you specify the DUMPCONDITIONING keyword when you 
>perform a full volume copy of volume VOL001 to volume VOL002. If you then 
>perform a full volume dump of VOL002 to tape, the output appears as if you had 
>dumped VOL001 directly. Now suppose that you copy VOL002 back to VOL001. Here, 
>the VOL002 volume serial number is not copied to VOL001's volume label, 
>because DFSMSdss treats VOL002 as a copy of VOL001.
>
>This example assumes that the source volume VOL001 has an indexed VTOC. If the 
>source volume does not have an indexed VTOC, a full volume dump of the 
>conditioned volume VOL002 would not look as if it was dumped from the original 
>source volume VOL001. Rather, it would be an exact image of the conditioned 
>volume. A subsequent full volume restore with the COPYVOLID keyword specified 
>results in the target volume having the same serial number as the conditioned 
>volume.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nai, Dean
>Sent: Wednesday, November 13, 2019 3:44 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
>STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT 
>FOR THIS TASK ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS 
>ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
>VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION
> 2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 
> ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
> FROM A CONDITIONED VOLUME ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON 
> DDNAME INDD1 LAST 0020 NEXT 0021 ADR006I (001)-STEND(02), 2019.317 
> 14:11:06 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK 
> COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 
> DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0008 FROM:
> TASK001
>
>Dean Nai   
>
>
>
>
>
>
>
>On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
>mainframer"  
>wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>Please provide the complete error message.
>>
>>The error message does not address tape labels.  (A wrong label would produce 
>>a system error before DFDSS got to the tape.)  It says the sequence number of 
>>data records is wrong.  This may indicate a corrupt file.
>>
>>What system level are you at.  There is a 5 year old APAR that addresses this 
>>issue.
>>
>>> -Original Message-
>&

Re: DFDSS backup retore

[Richards, Robert B.]

Does any of this apply and/or shed some light in this case seeing that you used 
DUMPCONDITIONING? See below:

DUMPCONDITIONING — Allows you to make a copy of the source volume in a full 
volume copy operation—including volume index information—while keeping the 
target volume online. Use this keyword when you want to create a copy of the 
source volume for backup purposes, rather than to allow applications to use the 
target volume.

With DUMPCONDITIONING in effect, the volume serial number of the target volume 
does not change, and the target volume remains online after the copy. The VVDS 
and VTOC index names on the target volume do not change to match the target 
volume serial number; they continue to match the source volume serial number.

In Step 2 , for example, you can include the DUMPCONDITIONING keyword on the 
full volume copy command to allow the target volume to remain online for 
dumping.

The target of a full volume copy operation using DUMPCONDITIONING is referred 
to as a conditioned volume. A full volume dump of a conditioned volume appears 
as if it were dumped from the original source volume of the copy operation. 
However, if the conditioned volume is copied back using DUMPCONDITIONING, 
conditioning is not performed on the original source volume. Instead, DFSMSdss 
recognizes that it is copying from the target of a previous conditioned-backup 
and recovers the original source volume.

For example, suppose that you specify the DUMPCONDITIONING keyword when you 
perform a full volume copy of volume VOL001 to volume VOL002. If you then 
perform a full volume dump of VOL002 to tape, the output appears as if you had 
dumped VOL001 directly. Now suppose that you copy VOL002 back to VOL001. Here, 
the VOL002 volume serial number is not copied to VOL001's volume label, because 
DFSMSdss treats VOL002 as a copy of VOL001.

This example assumes that the source volume VOL001 has an indexed VTOC. If the 
source volume does not have an indexed VTOC, a full volume dump of the 
conditioned volume VOL002 would not look as if it was dumped from the original 
source volume VOL001. Rather, it would be an exact image of the conditioned 
volume. A subsequent full volume restore with the COPYVOLID keyword specified 
results in the target volume having the same serial number as the conditioned 
volume.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nai, Dean
Sent: Wednesday, November 13, 2019 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS backup retore

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR 
THIS TASK ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS ADR780I 
(001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME 
FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION
 2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 
ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
FROM A CONDITIONED VOLUME ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON 
DDNAME INDD1 LAST 0020 NEXT 0021 ADR006I (001)-STEND(02), 2019.317 
14:11:06 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK 
COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 
DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0008 FROM:
 TASK001

Dean Nai







On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
mainframer"  
wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Please provide the complete error message.
>
>The error message does not address tape labels.  (A wrong label would produce 
>a system error before DFDSS got to the tape.)  It says the sequence number of 
>data records is wrong.  This may indicate a corrupt file.
>
>What system level are you at.  There is a 5 year old APAR that addresses this 
>issue.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Nai, Dean
>> Sent: Wednesday, November 13, 2019 11:55 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: DFDSS backup retore
>> 
>> Has anyone ever run into a problem where they have full volume 
>> backups that produce a ADR370E message when trying to restore? That 
>> message says the label and DSN on the tape don't match although I know they 
>> do. Any thoughts?
>> 
>> Control cards:
>> 
>> Restore -
>> Admin -
>> Inddname(indd1) outddname(outdd1) -
>> Full purge copyvolid
>> 
>> //indd1  dd
>> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=se
>> r=t

Re: DFDSS backup retore

[Edward Finnell]

That's the ticket. Thx...

In a message dated 11/14/2019 3:11:20 AM Central Standard Time, 
0224d287a4b1-dmarc-requ...@listserv.ua.edu writes:
Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Nai, Dean]

XXOUTDD1DD DSN=BACKUP.DLY.(+1),
  XX  DISP=(NEW,CATLG,DELETE),UNIT=,
  XX  VOL=,LABEL=(,SL,EXPDT=99000)
  IEFC653I SUBSTITUTION JCL - 
DSN=BACKUP.DLY.SMFLGB(+1),DISP=(NEW,CATLG,DELETE),UNIT=TAPE3592,VOL=(,RETAIN,,10),
  LABEL=(1,SL,EXPDT=99000)


DUMP  -.
.  ADMIN-   
   .
.  INDDNAME(INDD1)  OUTDDNAME(OUTDD1)   -   
   .
.  ALLDATA(*)  FULL ALLEXCP -   
   .
.  OPTIMIZE(4)






Dean Nai









On 11/14/19, 11:41 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, 
David"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Not why I asked.  Just wondering why you think you need to specify those.  Can 
>you post the JCL in its entirety used to create the backups?
>
>Looking at the tape label you posted separately, I cannot decipher all the 
>fields definitively without the headers, but I see RECFM=U, I just don’t know 
>what the next numbers are.  Also, what specific type of tape device are you 
>using?
>
>>> L.SMFLGB.G0303V00   19.287  99.000   U25458  200
>>> P1274  1274   SYSFBK1W/BACKUP
>
>But one of my DSS VOLUME dumps looks like this
>
>VOLSER = E55759 ACTVOL=SMSMC= BLANKS   
>DSN= TPE.TDP..DLB01A.D191022DSN17= 
>58.DLB01A.D191022
>EXPDT  = CATALOGACCT= BLANKS   
>FLAG1  = 41 FLAG2  = C0   FLAG3  = 00  BATCHID= 00 =   
>FLAG4  = 08 FLAG5  = 00   FLAG6  = 00  HOOKID = FD = SMF 83
>EDMID  =WMC= 0WWID   =  -  -   
>CDATE  = 2019/295   CJOB   =  CTIME  = 0855 CPGM   = ADRDSSU   
>LDATE  = 2019/295   LJOB   =  LTIME  = 0855 LPGM   = ADRDSSU   
>CSTEP  = VOLDUMPCDDNAME= TAPE2CUNIT  = 20CE LUNIT  = 20CE  
>OUTDATE= ZEROS  OUTCODE=  SLOT   = 000  TRERRC = 0 
>BTHDATE= 2007/125   VENDOR = BLANKS   COUNT  = 00264TWERRC = 0 
>DATECLN= ZEROS  USECLN = 0CLNCNT = 000  TRERRI = 0 
>VOLSEQ = 0001   ROBTY  = VIBM ROBID  = 001  TWERRI = 0 
>1STVOL =NEXTVOL=  PREVVOL=  PRERRC = 0 
>NUMDSNB= 0  1STDSNB=  LSTDSNB=  PWERRC = 0 
>LABEL  = SL DEN= 38KC TRTCH  = 36X2 PRERRI = 0 
>RECFM  = U  LRECL  = 00   BLKSIZE= 262144   PWERRI = 0 
>AUDATE = 2019/295   AUTIME = 0858 BESKEY = 0BLKCNT = 052020
>AUCODE = 02 AUFLAG1= 00   CPUID  = TEC1 USERID = CATALOG   
>VOLPERC= 001  FILPERC= 001  COMPRES= 043  BYTEPRC= 080  CTLGCNT= 001   
>
>_
>Dave Jousma
>AVP | Manager, Systems Engineering  
>
>Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
>MI 49546
>616.653.8429  |  fax: 616.653.2717
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Nai, Dean
>Sent: Thursday, November 14, 2019 11:16 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>**CAUTION EXTERNAL EMAIL**
>
>**DO NOT open attachments or click on links from unknown senders or unexpected 
>emails**
>
>Hi Dave,
>
>   Tried both.
>Dean Nai   
>
>
>
>
>
>
>
>
>
>On 11/14/19, 10:44 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, 
>David" 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>Why are you specifying label and volser info for the input?   
>>
>>___
>>__
>>Dave Jousma
>>AVP | Manager, Systems Engineering
>>
>>Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
>>Rapids, MI 49546
>>616.653.8429  |  fax: 616.653.2717
>>
>>
>>
>>-Original Message-
>>From: IBM Mainframe Discussion List  On 
>>Behalf Of Nai, Dean
>>Sent: Thursday, November 14, 2019 10:38 AM
>>To

Re: DFDSS backup restore

[Allan Staller]

As I recall, this was endemic to DF/DSS at the time.
The z/OS 1.12 version would not (by default) read the "old backup" (z/OS 1.11 
or below).

There is/was a PARM= or ctlcard option that needed to be specified in order to 
read a dump dataset created by the "old version".

Of course , given the age of this apar (circa 2015) it may not be applicable.

i.e. the data being restored would need to have been created prior to the 
installation of this APAR.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Thursday, November 14, 2019 7:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS backup retore

Hi Dean,
In case you're running Oracle (Sun (STK)) VSM, please see:
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.oracle.com%2Fknowledge%2FSun%2520Microsystems%2F1284809_1.htmldata=02%7C01%7Callan.staller%40HCL.COM%7C1b391799744f4a932d4708d769070f9f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637093351385087661sdata=ZACuymeHxEqGXxPUTvKATeaWKvtevzAz2apyYtDyF2c%3Dreserved=0

Regards,
David

On 2019-11-14 08:22, Nai, Dean wrote:
> Hi Carmen,
>   We tried using both catalog and VOL=SER=. Both failed.
>
>
>
>
>
>
>
> On 11/14/19, 7:55 AMEST, "IBM Mainframe Discussion List on behalf of Carmen 
> Vitullo"  wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>> norun will only syntax check your parms, control cards, are you using the 
>> catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ?
>>
>>
>>
>> Carmen Vitullo
>>
>> - Original Message -
>>
>> From: "Dean Nai" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Sent: Thursday, November 14, 2019 6:48:48 AM
>> Subject: Re: DFDSS backup retore
>>
>> Hi Mark,
>>
>> Ran the job with the NORUN part and it got a RC=0. Not sure what that proved 
>> but maybe something. I then dumped the tape label and it looks good although 
>> as we know it only shows the last 17 characters. I used one of the other 
>> tapes that had the same error for the tape label dump.
>>
>> L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274
>> SYSFBK1W/BACKUP
>>
>>
>>
>>
>>
>> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE
>> IN NORUN MODE RESTORE - ADMIN -
>> INDDNAME(INDD1) OUTDDNAME(OUTDD1) -
>> FULL COPYVOLID PURGE
>> ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
>> ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER
>> CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING
>> OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2019.318
>> 06:31:46 EXECUTION BEGINS ADR040I (001)-TDFP (01), PROCESSING
>> BYPASSED DUE TO NORUN OPTION ADR006I (001)-STEND(02), 2019.318
>> 06:31:46 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.318 06:31:46
>> TASK COMPLETED WITH RETURN CODE  ADR012I (SCH)-DSSU (01),
>> 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE
>> IS 
>>
>>
>>
>>
>> Dean Nai
>>
>>
>>
>>
>>
>>
>>
>>
>> On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark 
>> Jacobs" > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>>
>>> EXTERNAL: Do not open attachments or click on links unless you recognize 
>>> and trust the sender.
>>>
>>> Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card.
>>>
>>> Mark Jacobs
>>>
>>>
>>> Sent from ProtonMail, Swiss-based encrypted email.
>>>
>>> GPG Public Key -
>>> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
>>> ldefense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup
>>> %3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!eeWmBe9sc1cu
>>> Nw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaX
>>> Q%24data=02%7C01%7Callan.staller%40HCL.COM%7C1b391799744f4a932d
>>> 4708d769070f9f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63709335
>>> 1385087661sdata=V6fyTAtgRsOp4K7NISSGWWRoDPXH755mvbfbr5GU2A4%3D&
>>> amp;reserved=0
>>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Wednesday, November 13, 2019 8:42 PM, Edward Finnell 
>>> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>>>
>>>> Is there a DSS function to list the contents of the backup? We were FDR 
>>>> and it was straight forward.
>>>&g

Re: DFDSS backup retore

[Jousma, David]

Not why I asked.  Just wondering why you think you need to specify those.  Can 
you post the JCL in its entirety used to create the backups?

Looking at the tape label you posted separately, I cannot decipher all the 
fields definitively without the headers, but I see RECFM=U, I just don’t know 
what the next numbers are.  Also, what specific type of tape device are you 
using?

>> L.SMFLGB.G0303V00   19.287  99.000   U25458  200
>> P1274  1274   SYSFBK1W/BACKUP

But one of my DSS VOLUME dumps looks like this

VOLSER = E55759 ACTVOL=SMSMC= BLANKS   
DSN= TPE.TDP..DLB01A.D191022DSN17= 58.DLB01A.D191022
EXPDT  = CATALOGACCT= BLANKS   
FLAG1  = 41 FLAG2  = C0   FLAG3  = 00  BATCHID= 00 =   
FLAG4  = 08 FLAG5  = 00   FLAG6  = 00  HOOKID = FD = SMF 83
EDMID  =WMC= 0WWID   =  -  -   
CDATE  = 2019/295   CJOB   =  CTIME  = 0855 CPGM   = ADRDSSU   
LDATE  = 2019/295   LJOB   =  LTIME  = 0855 LPGM   = ADRDSSU   
CSTEP  = VOLDUMPCDDNAME= TAPE2CUNIT  = 20CE LUNIT  = 20CE  
OUTDATE= ZEROS  OUTCODE=  SLOT   = 000  TRERRC = 0 
BTHDATE= 2007/125   VENDOR = BLANKS   COUNT  = 00264TWERRC = 0 
DATECLN= ZEROS  USECLN = 0CLNCNT = 000  TRERRI = 0 
VOLSEQ = 0001   ROBTY  = VIBM ROBID  = 001  TWERRI = 0 
1STVOL =NEXTVOL=  PREVVOL=  PRERRC = 0 
NUMDSNB= 0  1STDSNB=  LSTDSNB=  PWERRC = 0 
LABEL  = SL DEN= 38KC TRTCH  = 36X2 PRERRI = 0 
RECFM  = U  LRECL  = 00   BLKSIZE= 262144   PWERRI = 0 
AUDATE = 2019/295   AUTIME = 0858 BESKEY = 0BLKCNT = 052020
AUCODE = 02 AUFLAG1= 00   CPUID  = TEC1 USERID = CATALOG   
VOLPERC= 001  FILPERC= 001  COMPRES= 043  BYTEPRC= 080  CTLGCNT= 001   

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nai, Dean
Sent: Thursday, November 14, 2019 11:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS backup retore

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi Dave,

   Tried both.
Dean Nai









On 11/14/19, 10:44 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, 
David"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Why are you specifying label and volser info for the input?   
>
>___
>__
>Dave Jousma
>AVP | Manager, Systems Engineering
>
>Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
>Rapids, MI 49546
>616.653.8429  |  fax: 616.653.2717
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Nai, Dean
>Sent: Thursday, November 14, 2019 10:38 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>**CAUTION EXTERNAL EMAIL**
>
>**DO NOT open attachments or click on links from unknown senders or 
>unexpected emails**
>
>The restore job gets the same error message for all restores. This time I 
>tried using a weekly backup instead of a daily backup. That got the same error.
>
>
>
>
>
>
>
>This e-mail transmission contains information that is confidential and may be 
>privileged.   It is intended only for the addressee(s) named above. If you 
>receive this e-mail in error, please do not read, copy or disseminate it in 
>any manner. If you are not the intended recipient, any disclosure, copying, 
>distribution or use of the contents of this information is prohibited. Please 
>reply to the message immediately by informing the sender that the message was 
>misdirected. After replying, please erase it from your computer system. Your 
>assistance in correcting this error is appreciated.
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listse

Re: DFDSS backup retore

[Nai, Dean]

Hi Dave,

   Tried both.
Dean Nai









On 11/14/19, 10:44 AMEST, "IBM Mainframe Discussion List on behalf of Jousma, 
David"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Why are you specifying label and volser info for the input?   
>
>_
>Dave Jousma
>AVP | Manager, Systems Engineering  
>
>Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
>MI 49546
>616.653.8429  |  fax: 616.653.2717
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Nai, Dean
>Sent: Thursday, November 14, 2019 10:38 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>**CAUTION EXTERNAL EMAIL**
>
>**DO NOT open attachments or click on links from unknown senders or unexpected 
>emails**
>
>The restore job gets the same error message for all restores. This time I 
>tried using a weekly backup instead of a daily backup. That got the same error.
>
>
>
>
>
>
>
>This e-mail transmission contains information that is confidential and may be 
>privileged.   It is intended only for the addressee(s) named above. If you 
>receive this e-mail in error, please do not read, copy or disseminate it in 
>any manner. If you are not the intended recipient, any disclosure, copying, 
>distribution or use of the contents of this information is prohibited. Please 
>reply to the message immediately by informing the sender that the message was 
>misdirected. After replying, please erase it from your computer system. Your 
>assistance in correcting this error is appreciated.
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Jousma, David]

Why are you specifying label and volser info for the input?   

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nai, Dean
Sent: Thursday, November 14, 2019 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS backup retore

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

The restore job gets the same error message for all restores. This time I tried 
using a weekly backup instead of a daily backup. That got the same error.







This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Nai, Dean]

The restore job gets the same error message for all restores. This time I tried 
using a weekly backup instead of a daily backup. That got the same error.









On 11/14/19, 8:58 AMEST, "IBM Mainframe Discussion List on behalf of retired 
mainframer"  
wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>In your first message, the LLQ was G0449V00.  Now it is G0303V00.  Are we 
>still talking about the same issue?
>
>One more time, the original error message did not relate to the label or DSN.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Nai, Dean
>> Sent: Thursday, November 14, 2019 4:49 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: DFDSS backup retore
>> 
>> Hi Mark,
>> 
>>Ran the job with the NORUN part and it got a RC=0. Not sure what that 
>> proved but
>> maybe something. I then dumped the tape label and it looks good although as 
>> we
>> know it only shows the last 17 characters. I used one of the other tapes 
>> that had the
>> same error for the tape label dump.
>> 
>> L.SMFLGB.G0303V00   19.287  99.000   U25458  200
>> P1274
>> 1274   SYSFBK1W/BACKUP
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[retired mainframer]

In your first message, the LLQ was G0449V00.  Now it is G0303V00.  Are we still 
talking about the same issue?

One more time, the original error message did not relate to the label or DSN.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Nai, Dean
> Sent: Thursday, November 14, 2019 4:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFDSS backup retore
> 
> Hi Mark,
> 
>Ran the job with the NORUN part and it got a RC=0. Not sure what that 
> proved but
> maybe something. I then dumped the tape label and it looks good although as we
> know it only shows the last 17 characters. I used one of the other tapes that 
> had the
> same error for the tape label dump.
> 
> L.SMFLGB.G0303V00   19.287  99.000   U25458  200P 
>1274
> 1274   SYSFBK1W/BACKUP

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[David Spiegel]

Hi Dean,
In case you're running Oracle (Sun (STK)) VSM, please see:
https://support.oracle.com/knowledge/Sun%20Microsystems/1284809_1.html

Regards,
David

On 2019-11-14 08:22, Nai, Dean wrote:
> Hi Carmen,
>   We tried using both catalog and VOL=SER=. Both failed.
>
>
>
>
>
>
>
> On 11/14/19, 7:55 AMEST, "IBM Mainframe Discussion List on behalf of Carmen 
> Vitullo"  wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>> norun will only syntax check your parms, control cards, are you using the 
>> catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ?
>>
>>
>>
>> Carmen Vitullo
>>
>> - Original Message -
>>
>> From: "Dean Nai" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Sent: Thursday, November 14, 2019 6:48:48 AM
>> Subject: Re: DFDSS backup retore
>>
>> Hi Mark,
>>
>> Ran the job with the NORUN part and it got a RC=0. Not sure what that proved 
>> but maybe something. I then dumped the tape label and it looks good although 
>> as we know it only shows the last 17 characters. I used one of the other 
>> tapes that had the same error for the tape label dump.
>>
>> L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP
>>
>>
>>
>>
>>
>> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN 
>> MODE
>> RESTORE -
>> ADMIN -
>> INDDNAME(INDD1) OUTDDNAME(OUTDD1) -
>> FULL COPYVOLID PURGE
>> ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
>> ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL 
>> STATEMENTS COMPLETED
>> ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
>> ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS
>> ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION
>> ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS
>> ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE 
>> 
>> ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. 
>> HIGHEST RETURN CODE IS 
>>
>>
>>
>>
>> Dean Nai
>>
>>
>>
>>
>>
>>
>>
>>
>> On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark 
>> Jacobs" > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>>
>>> EXTERNAL: Do not open attachments or click on links unless you recognize 
>>> and trust the sender.
>>>
>>> Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card.
>>>
>>> Mark Jacobs
>>>
>>>
>>> Sent from ProtonMail, Swiss-based encrypted email.
>>>
>>> GPG Public Key - 
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ%24data=02%7C01%7C%7Cbbae3136ff484aacd38c08d76905d087%7C84df9e7fe9f640afb435%7C1%7C0%7C637093346016362866sdata=heNINPkab1BaHySWa7zx0GVUUWgcp6Jxq%2B7aQac14BM%3Dreserved=0
>>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Wednesday, November 13, 2019 8:42 PM, Edward Finnell 
>>> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>>>
>>>> Is there a DSS function to list the contents of the backup? We were FDR 
>>>> and it was straight forward.
>>>>
>>>> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, 
>>>> retired-mainfra...@q.com writes:
>>>> The error has nothing to do with labels. DFDSS processed 32 blocks of data 
>>>> and reported a problem when reading the 33rd.
>>>>
>>>> -
>>>>
>>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with 

Re: DFDSS backup retore

[Nai, Dean]

Hi Carmen,
 We tried using both catalog and VOL=SER=. Both failed. 







On 11/14/19, 7:55 AMEST, "IBM Mainframe Discussion List on behalf of Carmen 
Vitullo"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>norun will only syntax check your parms, control cards, are you using the 
>catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? 
>
>
>
>Carmen Vitullo 
>
>- Original Message -
>
>From: "Dean Nai"  
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Thursday, November 14, 2019 6:48:48 AM 
>Subject: Re: DFDSS backup retore 
>
>Hi Mark, 
>
>Ran the job with the NORUN part and it got a RC=0. Not sure what that proved 
>but maybe something. I then dumped the tape label and it looks good although 
>as we know it only shows the last 17 characters. I used one of the other tapes 
>that had the same error for the tape label dump. 
>
>L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP 
>
>
>
>
>
>ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN 
>MODE 
>RESTORE - 
>ADMIN - 
>INDDNAME(INDD1) OUTDDNAME(OUTDD1) - 
>FULL COPYVOLID PURGE 
>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL 
>STATEMENTS COMPLETED 
>ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
>ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS 
>ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION 
>ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS 
>ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE 
> 
>ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. 
>HIGHEST RETURN CODE IS  
>
>
>
>
>Dean Nai 
>
>
>
>
>
>
>
>
>On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark 
>Jacobs" 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: 
>
>> EXTERNAL: Do not open attachments or click on links unless you recognize and 
>> trust the sender. 
>> 
>>Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. 
>> 
>>Mark Jacobs 
>> 
>> 
>>Sent from ProtonMail, Swiss-based encrypted email. 
>> 
>>GPG Public Key - 
>>https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$
>> 
>> 
>>‐‐‐ Original Message ‐‐‐ 
>>On Wednesday, November 13, 2019 8:42 PM, Edward Finnell 
>><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: 
>> 
>>> Is there a DSS function to list the contents of the backup? We were FDR and 
>>> it was straight forward. 
>>> 
>>> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, 
>>> retired-mainfra...@q.com writes: 
>>> The error has nothing to do with labels. DFDSS processed 32 blocks of data 
>>> and reported a problem when reading the 33rd. 
>>> 
>>> -
>>>  
>>> 
>>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>> 
>>-- 
>>For IBM-MAIN subscribe / signoff / archive access instructions, 
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>
>-- 
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Carmen Vitullo]

just now read Retired's post 


Carmen Vitullo 

- Original Message -

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, November 14, 2019 6:55:35 AM 
Subject: Re: DFDSS backup retore 

norun will only syntax check your parms, control cards, are you using the 
catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? 



Carmen Vitullo 

- Original Message - 

From: "Dean Nai"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, November 14, 2019 6:48:48 AM 
Subject: Re: DFDSS backup retore 

Hi Mark, 

Ran the job with the NORUN part and it got a RC=0. Not sure what that proved 
but maybe something. I then dumped the tape label and it looks good although as 
we know it only shows the last 17 characters. I used one of the other tapes 
that had the same error for the tape label dump. 

L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP 





ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN 
MODE 
RESTORE - 
ADMIN - 
INDDNAME(INDD1) OUTDDNAME(OUTDD1) - 
FULL COPYVOLID PURGE 
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED 
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS 
ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION 
ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS 
ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE  
ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS  




Dean Nai 








On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark 
Jacobs"  wrote: 

> EXTERNAL: Do not open attachments or click on links unless you recognize and 
> trust the sender. 
> 
>Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. 
> 
>Mark Jacobs 
> 
> 
>Sent from ProtonMail, Swiss-based encrypted email. 
> 
>GPG Public Key - 
>https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$
> 
> 
>‐‐‐ Original Message ‐‐‐ 
>On Wednesday, November 13, 2019 8:42 PM, Edward Finnell 
><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: 
> 
>> Is there a DSS function to list the contents of the backup? We were FDR and 
>> it was straight forward. 
>> 
>> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, 
>> retired-mainfra...@q.com writes: 
>> The error has nothing to do with labels. DFDSS processed 32 blocks of data 
>> and reported a problem when reading the 33rd. 
>> 
>> -
>>  
>> 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
>-- 
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Carmen Vitullo]

norun will only syntax check your parms, control cards, are you using the 
catalog for the restore volumes, or are you VOL=SER=(x,xx,) them ? 



Carmen Vitullo 

- Original Message -

From: "Dean Nai"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, November 14, 2019 6:48:48 AM 
Subject: Re: DFDSS backup retore 

Hi Mark, 

Ran the job with the NORUN part and it got a RC=0. Not sure what that proved 
but maybe something. I then dumped the tape label and it looks good although as 
we know it only shows the last 17 characters. I used one of the other tapes 
that had the same error for the tape label dump. 

L.SMFLGB.G0303V00 19.287 99.000 U 25458 200 P 1274 1274 SYSFBK1W/BACKUP 





ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN 
MODE 
RESTORE - 
ADMIN - 
INDDNAME(INDD1) OUTDDNAME(OUTDD1) - 
FULL COPYVOLID PURGE 
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED 
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS 
ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION 
ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS 
ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE  
ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS  




Dean Nai 








On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark 
Jacobs"  wrote: 

> EXTERNAL: Do not open attachments or click on links unless you recognize and 
> trust the sender. 
> 
>Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card. 
> 
>Mark Jacobs 
> 
> 
>Sent from ProtonMail, Swiss-based encrypted email. 
> 
>GPG Public Key - 
>https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$
> 
> 
>‐‐‐ Original Message ‐‐‐ 
>On Wednesday, November 13, 2019 8:42 PM, Edward Finnell 
><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: 
> 
>> Is there a DSS function to list the contents of the backup? We were FDR and 
>> it was straight forward. 
>> 
>> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, 
>> retired-mainfra...@q.com writes: 
>> The error has nothing to do with labels. DFDSS processed 32 blocks of data 
>> and reported a problem when reading the 33rd. 
>> 
>> -
>>  
>> 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
>-- 
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Nai, Dean]

Hi Mark,

   Ran the job with the NORUN part and it got a RC=0. Not sure what that proved 
but maybe something. I then dumped the tape label and it looks good although as 
we know it only shows the last 17 characters. I used one of the other tapes 
that had the same error for the tape label dump.

L.SMFLGB.G0303V00   19.287  99.000   U25458  200P   
 12741274   SYSFBK1W/BACKUP





ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN 
MODE
  RESTORE  -
 ADMIN-
 INDDNAME(INDD1)  OUTDDNAME(OUTDD1)   -
 FULL COPYVOLID PURGE
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
ADR109I (R/I)-RI01 (01), 2019.318 06:31:46 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
ADR006I (001)-STEND(01), 2019.318 06:31:46 EXECUTION BEGINS
ADR040I (001)-TDFP (01), PROCESSING BYPASSED DUE TO NORUN OPTION
ADR006I (001)-STEND(02), 2019.318 06:31:46 EXECUTION ENDS
ADR013I (001)-CLTSK(01), 2019.318 06:31:46 TASK COMPLETED WITH RETURN CODE 
ADR012I (SCH)-DSSU (01), 2019.318 06:31:46 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS 




Dean Nai








On 11/13/19, 9:02 PMEST, "IBM Mainframe Discussion List on behalf of Mark 
Jacobs"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card.
>
>Mark Jacobs
>
>
>Sent from ProtonMail, Swiss-based encrypted email.
>
>GPG Public Key - 
>https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!eeWmBe9sc1cuNw!C6r2Dq_pAAmw5ED-JfkCEFAiHr1h0inSSHCUa3btNClWHhfYEzg5k-BUvuBVhExaXQ$
> 
>
>‐‐‐ Original Message ‐‐‐
>On Wednesday, November 13, 2019 8:42 PM, Edward Finnell 
><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Is there a DSS function to list the contents of the backup? We were FDR and 
>> it was straight forward.
>>
>> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, 
>> retired-mainfra...@q.com writes:
>> The error has nothing to do with labels.  DFDSS processed 32 blocks of data 
>> and reported a problem when reading the 33rd.
>>
>> -
>>
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Mark Jacobs]

Execute a DFDSS restore with a PARM='TYPRUN=NORUN' on the exec card.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Wednesday, November 13, 2019 8:42 PM, Edward Finnell 
<000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> Is there a DSS function to list the contents of the backup? We were FDR and 
> it was straight forward.
>
> In a message dated 11/13/2019 6:59:32 PM Central Standard Time, 
> retired-mainfra...@q.com writes:
> The error has nothing to do with labels.  DFDSS processed 32 blocks of data 
> and reported a problem when reading the 33rd.
>
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Edward Finnell]

Is there a DSS function to list the contents of the backup? We were FDR and it 
was straight forward.

In a message dated 11/13/2019 6:59:32 PM Central Standard Time, 
retired-mainfra...@q.com writes:
The error has nothing to do with labels.  DFDSS processed 32 blocks of data and 
reported a problem when reading the 33rd.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[retired mainframer]

The error has nothing to do with labels.  DFDSS processed 32 blocks of data and 
reported a problem when reading the 33rd.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jesse 1 Robinson
> Sent: Wednesday, November 13, 2019 4:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFDSS backup retore
> 
> Unlikely to be your problem, but we actually had the following scenario 
> recently. We
> use 'STK' virtual tape VSMx. After a system crash of some sort, we got the 
> ubiquitous
> warning to 'run a tape audit'. We've seen this message for years. Somehow it 
> was
> overlooked in this case, and no 'audit' was run. We started getting similar 
> errors for
> mismatching tape labels. Damndest thing. We finally ran the STK tape audit. 
> The
> problem disappeared totally. Maybe the weirdest thing I ever saw.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Edward Finnell
> Sent: Wednesday, November 13, 2019 3:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: DFDSS backup retore
> 
> Only way to find out is run TAPEMAP on INDD1 VOLSER.
> 
> In a message dated 11/13/2019 5:11:20 PM Central Standard Time,
> dean@doit.nh.gov writes:
> ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING
> COMPLETE. HIGHEST RETURN CODE IS 0008 FROM:
> TASK001
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[PINION, RICHARD W.]

Reminds me of the original STK RVA, before IBM got involved with the microcode. 
The box would crash, and all of the data disappeared.  And there was no way to
recover it.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Wednesday, November 13, 2019 7:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS backup retore

[External Email]

Unlikely to be your problem, but we actually had the following scenario 
recently. We use 'STK' virtual tape VSMx. After a system crash of some sort, we 
got the ubiquitous warning to 'run a tape audit'. We've seen this message for 
years. Somehow it was overlooked in this case, and no 'audit' was run. We 
started getting similar errors for mismatching tape labels. Damndest thing. We 
finally ran the STK tape audit. The problem disappeared totally. Maybe the 
weirdest thing I ever saw.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edward Finnell
Sent: Wednesday, November 13, 2019 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: DFDSS backup retore

Only way to find out is run TAPEMAP on INDD1 VOLSER.

In a message dated 11/13/2019 5:11:20 PM Central Standard Time, 
dean@doit.nh.gov writes:
ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS 0008 FROM:
TASK001


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Jesse 1 Robinson]

Unlikely to be your problem, but we actually had the following scenario 
recently. We use 'STK' virtual tape VSMx. After a system crash of some sort, we 
got the ubiquitous warning to 'run a tape audit'. We've seen this message for 
years. Somehow it was overlooked in this case, and no 'audit' was run. We 
started getting similar errors for mismatching tape labels. Damndest thing. We 
finally ran the STK tape audit. The problem disappeared totally. Maybe the 
weirdest thing I ever saw. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edward Finnell
Sent: Wednesday, November 13, 2019 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: DFDSS backup retore

Only way to find out is run TAPEMAP on INDD1 VOLSER.

In a message dated 11/13/2019 5:11:20 PM Central Standard Time, 
dean@doit.nh.gov writes:
ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS 0008 FROM:
                        TASK    001


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Edward Finnell]

Only way to find out is run TAPEMAP on INDD1 VOLSER.

In a message dated 11/13/2019 5:11:20 PM Central Standard Time, 
dean@doit.nh.gov writes:
ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS 0008 FROM:
                        TASK    001

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[retired mainframer]

Since the JCL specified the volser, why do you think the catalog was used at 
all?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Carmen Vitullo
> Sent: Wednesday, November 13, 2019 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFDSS backup retore
> 
> I want to assume the tapes used to restore the volume are cataloged and you 
> are using
> the catalog?
 


> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Nai, Dean
> >> Sent: Wednesday, November 13, 2019 11:55 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: DFDSS backup retore
> >>
> >> Has anyone ever run into a problem where they have full volume backups that
> produce
> >> a ADR370E message when trying to restore? That message says the label and 
> >> DSN
> on
> >> the tape don't match although I know they do. Any thoughts?
> >>
> >> Control cards:
> >>
> >> Restore -
> >> Admin -
> >> Inddname(indd1) outddname(outdd1) -
> >> Full purge copyvolid
> >>
> >> //indd1 dd
> >> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=ser=tap001
> >> //outdd1 dd vol=ser=sc560c,unit=3390,disp=old
> >>
> >> Dean Nai
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Nai, Dean]

Sorry about that. I was just making up a tape number. The actual number was the 
one the list cat stated.

Dean Nai









On 11/13/19, 4:24 PMEST, "IBM Mainframe Discussion List on behalf of Bill 
Bishop (TMNA)"  
wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Your JCL said vol=ser=TAP001, but your catalog entry says  the serial number 
>is T000523.
>
>Are you trying to restore this tape on to a system other than where it was 
>created and is this tape not cataloged there or in that systems tape 
>management environment?
>
>Thanks
>
>Bill Bishop
>Consultant, Mainframe Engineer
>Mainframe and Scheduling | Infrastructure Technology Services 
>Toyota Motor North America
> bill.bis...@toyota.com
>Office:  (469) 292-5149
>Cell:  (502) 316-4386
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nai, Dean
>Sent: Wednesday, November 13, 2019 3:18 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: [EXTERNAL] Re: DFDSS backup retore
>
>
>NONVSAM --- BACKUP.DLY.SMFLGB.G0449V00
>  IN-CAT --- CATALOG.PRODCAT.VOEMP01
>  HISTORY
>DATASET-OWNER-(NULL) CREATION2019.311
>RELEASE2 EXPIRATION--.000
>  ENCRYPTIONDATA
>DATA SET ENCRYPTION-(NO)
>  VOLUMES
>VOLSERT00523 DEVTYPE--X'78048083' 
> FSEQN--1
>  ASSOCIATIONS
>GDG--BACKUP.DLY.SMFLGB
>  ATTRIBUTES
>
>
>
>
>
>
>
>
>
>On 11/13/19, 4:05 PMEST, "IBM Mainframe Discussion List on behalf of Leonardo 
>Vaz"  wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>Is the dataset on a single tape volume or multiple? Can you provide the 
>>LISTCAT ENT(/) ALL of the file?
>>
>>Leo
>>-Original Message-
>>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>>On Behalf Of Nai, Dean
>>Sent: Wednesday, November 13, 2019 4:00 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: DFDSS backup retore
>>
>>Looked at Ca1 catalog and os catalog. Label is correct. We are running 2.3 
>>Dean Nai  
>>Senior z/OS Systems Programmer
>>Technical Services Group
>>Department of Information Technology
>>State of New Hampshire
>>27 Hazen Drive
>>Concord, NH 03301
>> work: 603-271-1529
>>
>>
>>Statement of Confidentiality: The contents of this message are 
>>confidential.
>>Any unauthorized disclosure, reproduction, use or dissemination (either 
>>whole or in part) is prohibited. If you are not the intended recipient 
>>of this message, please notify the sender immediately and delete the 
>>message from your system.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On 11/13/19, 3:57 PMEST, "IBM Mainframe Discussion List on behalf of Carmen 
>>Vitullo"  wrote:
>>
>>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>>> and trust the sender.
>>>
>>>I want to assume the tapes used to restore the volume are cataloged and you 
>>>are using the catalog? 
>>>
>>>
>>>
>>>During a RESTORE, the sequence number of the record read, 2 (in 
>>>hexadecimal) did not match the previous record processed, 1 (in 
>>>hexadecimal). If there is an end of volume involved, a tape might have been 
>>>mounted in the wrong sequence. 
>>>
>>>
>>>
>>>
>>>
>>>or a very old APAR
>>>
>>>
>>>
>>>
>>>
>>>https://urldefense.com/v3/__https://www-01.ibm.com/support/docview.wss
>>>?uid=isg1OA46522__;!eeWmBe9sc1cuNw!F9dfrqbRDFdqANDbAYzH3fI-3PYk5ndProL
>>>x_v4VU98Ok7juTJsVbHWwDL1zH-xsYQ$
>>>
>>>
>>>
>>>
>>>
>>>Carmen Vitullo
>>>
>>>
>>>
>>>- Original Message -
>>>
>>>
>>>
>>>From: "Dean Nai" 
>>>
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>
>>>Sent: Wednesday, November 13, 2019 2:43:51 PM
>>>
>>>Subject: Re: DFDSS backup retore
>>>
>>>
>>>
>>>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>>>
>>>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER 
>>>CONTROL STATEMENTS COMPLETED
>>>
>&g

Re: DFDSS backup retore

[Bill Bishop (TMNA)]

Sorry, late to the game.  

Thought it was the serial number mis-matched.

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services 
Toyota Motor North America
 bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Bishop (TMNA)
Sent: Wednesday, November 13, 2019 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: DFDSS backup retore

Your JCL said vol=ser=TAP001, but your catalog entry says  the serial number is 
T000523.

Are you trying to restore this tape on to a system other than where it was 
created and is this tape not cataloged there or in that systems tape management 
environment?

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services Toyota Motor 
North America  bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nai, Dean
Sent: Wednesday, November 13, 2019 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: DFDSS backup retore


NONVSAM --- BACKUP.DLY.SMFLGB.G0449V00
  IN-CAT --- CATALOG.PRODCAT.VOEMP01
  HISTORY
DATASET-OWNER-(NULL) CREATION2019.311
RELEASE2 EXPIRATION--.000
  ENCRYPTIONDATA
DATA SET ENCRYPTION-(NO)
  VOLUMES
VOLSERT00523 DEVTYPE--X'78048083' 
FSEQN--1
  ASSOCIATIONS
GDG--BACKUP.DLY.SMFLGB
  ATTRIBUTES









On 11/13/19, 4:05 PMEST, "IBM Mainframe Discussion List on behalf of Leonardo 
Vaz"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Is the dataset on a single tape volume or multiple? Can you provide the 
>LISTCAT ENT(/) ALL of the file?
>
>Leo
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Nai, Dean
>Sent: Wednesday, November 13, 2019 4:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>Looked at Ca1 catalog and os catalog. Label is correct. We are running 2.3 
>Dean Nai   
>Senior z/OS Systems Programmer 
>Technical Services Group
>Department of Information Technology
>State of New Hampshire
>27 Hazen Drive
>Concord, NH 03301
> work: 603-271-1529
>
>
>Statement of Confidentiality: The contents of this message are 
>confidential.
>Any unauthorized disclosure, reproduction, use or dissemination (either 
>whole or in part) is prohibited. If you are not the intended recipient 
>of this message, please notify the sender immediately and delete the 
>message from your system.
>
>
>
>
>
>
>
>
>
>On 11/13/19, 3:57 PMEST, "IBM Mainframe Discussion List on behalf of Carmen 
>Vitullo"  wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>I want to assume the tapes used to restore the volume are cataloged and you 
>>are using the catalog? 
>>
>>
>>
>>During a RESTORE, the sequence number of the record read, 2 (in 
>>hexadecimal) did not match the previous record processed, 1 (in 
>>hexadecimal). If there is an end of volume involved, a tape might have been 
>>mounted in the wrong sequence. 
>>
>>
>>
>>
>>
>>or a very old APAR
>>
>>
>>
>>
>>
>>https://urldefense.com/v3/__https://www-01.ibm.com/support/docview.wss
>>?uid=isg1OA46522__;!eeWmBe9sc1cuNw!F9dfrqbRDFdqANDbAYzH3fI-3PYk5ndProL
>>x_v4VU98Ok7juTJsVbHWwDL1zH-xsYQ$
>>
>>
>>
>>
>>
>>Carmen Vitullo
>>
>>
>>
>>- Original Message -
>>
>>
>>
>>From: "Dean Nai" 
>>
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>
>>Sent: Wednesday, November 13, 2019 2:43:51 PM
>>
>>Subject: Re: DFDSS backup retore
>>
>>
>>
>>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>>
>>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER 
>>CONTROL STATEMENTS COMPLETED
>>
>>ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
>>
>>ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS
>>
>>ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN 
>>FULL VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION
>>
>>2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53
>>
>>ADR808I (001)-TDFP 

Re: DFDSS backup retore

[Bill Bishop (TMNA)]

Your JCL said vol=ser=TAP001, but your catalog entry says  the serial number is 
T000523.

Are you trying to restore this tape on to a system other than where it was 
created and is this tape not cataloged there or in that systems tape management 
environment?

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services 
Toyota Motor North America
 bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nai, Dean
Sent: Wednesday, November 13, 2019 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: DFDSS backup retore


NONVSAM --- BACKUP.DLY.SMFLGB.G0449V00
  IN-CAT --- CATALOG.PRODCAT.VOEMP01
  HISTORY
DATASET-OWNER-(NULL) CREATION2019.311
RELEASE2 EXPIRATION--.000
  ENCRYPTIONDATA
DATA SET ENCRYPTION-(NO)
  VOLUMES
VOLSERT00523 DEVTYPE--X'78048083' 
FSEQN--1
  ASSOCIATIONS
GDG--BACKUP.DLY.SMFLGB
  ATTRIBUTES









On 11/13/19, 4:05 PMEST, "IBM Mainframe Discussion List on behalf of Leonardo 
Vaz"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Is the dataset on a single tape volume or multiple? Can you provide the 
>LISTCAT ENT(/) ALL of the file?
>
>Leo
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Nai, Dean
>Sent: Wednesday, November 13, 2019 4:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>Looked at Ca1 catalog and os catalog. Label is correct. We are running 2.3 
>Dean Nai   
>Senior z/OS Systems Programmer 
>Technical Services Group
>Department of Information Technology
>State of New Hampshire
>27 Hazen Drive
>Concord, NH 03301
> work: 603-271-1529
>
>
>Statement of Confidentiality: The contents of this message are 
>confidential.
>Any unauthorized disclosure, reproduction, use or dissemination (either 
>whole or in part) is prohibited. If you are not the intended recipient 
>of this message, please notify the sender immediately and delete the 
>message from your system.
>
>
>
>
>
>
>
>
>
>On 11/13/19, 3:57 PMEST, "IBM Mainframe Discussion List on behalf of Carmen 
>Vitullo"  wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>I want to assume the tapes used to restore the volume are cataloged and you 
>>are using the catalog? 
>>
>>
>>
>>During a RESTORE, the sequence number of the record read, 2 (in 
>>hexadecimal) did not match the previous record processed, 1 (in 
>>hexadecimal). If there is an end of volume involved, a tape might have been 
>>mounted in the wrong sequence. 
>>
>>
>>
>>
>>
>>or a very old APAR
>>
>>
>>
>>
>>
>>https://urldefense.com/v3/__https://www-01.ibm.com/support/docview.wss
>>?uid=isg1OA46522__;!eeWmBe9sc1cuNw!F9dfrqbRDFdqANDbAYzH3fI-3PYk5ndProL
>>x_v4VU98Ok7juTJsVbHWwDL1zH-xsYQ$
>>
>>
>>
>>
>>
>>Carmen Vitullo
>>
>>
>>
>>- Original Message -
>>
>>
>>
>>From: "Dean Nai" 
>>
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>
>>Sent: Wednesday, November 13, 2019 2:43:51 PM
>>
>>Subject: Re: DFDSS backup retore
>>
>>
>>
>>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>>
>>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER 
>>CONTROL STATEMENTS COMPLETED
>>
>>ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
>>
>>ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS
>>
>>ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN 
>>FULL VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION
>>
>>2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53
>>
>>ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS 
>>CREATED FROM A CONDITIONED VOLUME
>>
>>ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON DDNAME INDD1 LAST 
>>0020 NEXT 0021
>>
>>ADR006I (001)-STEND(02), 2019.317 14:11:06 EXECUTION ENDS
>>
>>ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK COMPLETED WITH RETURN 
>>CODE 0008
>>
>>ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
>>HIGHEST RETURN CODE IS 0008 FROM: 
>>

Re: DFDSS backup retore

[Leonardo Vaz]

Single volume beats any chance of multivolume being the problem, I'd open a PMR 
at this point.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nai, Dean
Sent: Wednesday, November 13, 2019 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS backup retore


NONVSAM --- BACKUP.DLY.SMFLGB.G0449V00
  IN-CAT --- CATALOG.PRODCAT.VOEMP01
  HISTORY
DATASET-OWNER-(NULL) CREATION2019.311
RELEASE2 EXPIRATION--.000
  ENCRYPTIONDATA
DATA SET ENCRYPTION-(NO)
  VOLUMES
VOLSERT00523 DEVTYPE--X'78048083' 
FSEQN--1
  ASSOCIATIONS
GDG--BACKUP.DLY.SMFLGB
  ATTRIBUTES









On 11/13/19, 4:05 PMEST, "IBM Mainframe Discussion List on behalf of Leonardo 
Vaz"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Is the dataset on a single tape volume or multiple? Can you provide the 
>LISTCAT ENT(/) ALL of the file?
>
>Leo
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nai, Dean
>Sent: Wednesday, November 13, 2019 4:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>Looked at Ca1 catalog and os catalog. Label is correct. We are running 2.3 
>Dean Nai   
>Senior z/OS Systems Programmer 
>Technical Services Group
>Department of Information Technology
>State of New Hampshire
>27 Hazen Drive
>Concord, NH 03301
> work: 603-271-1529
>
>
>Statement of Confidentiality: The contents of this message are
>confidential.
>Any unauthorized disclosure, reproduction, use or dissemination (either
>whole or in part) is prohibited. If you are not the intended recipient of
>this message, please notify the sender immediately and delete the message
>from your system.
>
>
>
>
>
>
>
>
>
>On 11/13/19, 3:57 PMEST, "IBM Mainframe Discussion List on behalf of Carmen 
>Vitullo"  wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>I want to assume the tapes used to restore the volume are cataloged and you 
>>are using the catalog? 
>>
>>
>>
>>During a RESTORE, the sequence number of the record read, 2 (in 
>>hexadecimal) did not match the previous record processed, 1 (in 
>>hexadecimal). If there is an end of volume involved, a tape might have been 
>>mounted in the wrong sequence. 
>>
>>
>>
>>
>>
>>or a very old APAR 
>>
>>
>>
>>
>>
>>https://urldefense.com/v3/__https://www-01.ibm.com/support/docview.wss?uid=isg1OA46522__;!eeWmBe9sc1cuNw!F9dfrqbRDFdqANDbAYzH3fI-3PYk5ndProLx_v4VU98Ok7juTJsVbHWwDL1zH-xsYQ$
>>  
>>
>>
>>
>>
>>
>>Carmen Vitullo 
>>
>>
>>
>>- Original Message -
>>
>>
>>
>>From: "Dean Nai"  
>>
>>To: IBM-MAIN@LISTSERV.UA.EDU 
>>
>>Sent: Wednesday, November 13, 2019 2:43:51 PM 
>>
>>Subject: Re: DFDSS backup retore 
>>
>>
>>
>>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>>
>>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
>>STATEMENTS COMPLETED 
>>
>>ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
>>
>>ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS 
>>
>>ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
>>VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION 
>>
>>2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 
>>
>>ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
>>FROM A CONDITIONED VOLUME 
>>
>>ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON DDNAME INDD1 LAST 
>>0020 NEXT 0021 
>>
>>ADR006I (001)-STEND(02), 2019.317 14:11:06 EXECUTION ENDS 
>>
>>ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK COMPLETED WITH RETURN CODE 
>>0008 
>>
>>ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
>>HIGHEST RETURN CODE IS 0008 FROM: 
>>
>>TASK 001 
>>
>>
>>
>>Dean Nai 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
>>mainframer"  
>>wrote: 
>>
>>
>>
>&g

Re: DFDSS backup retore

[Nai, Dean]

NONVSAM --- BACKUP.DLY.SMFLGB.G0449V00
  IN-CAT --- CATALOG.PRODCAT.VOEMP01
  HISTORY
DATASET-OWNER-(NULL) CREATION2019.311
RELEASE2 EXPIRATION--.000
  ENCRYPTIONDATA
DATA SET ENCRYPTION-(NO)
  VOLUMES
VOLSERT00523 DEVTYPE--X'78048083' 
FSEQN--1
  ASSOCIATIONS
GDG--BACKUP.DLY.SMFLGB
  ATTRIBUTES









On 11/13/19, 4:05 PMEST, "IBM Mainframe Discussion List on behalf of Leonardo 
Vaz"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Is the dataset on a single tape volume or multiple? Can you provide the 
>LISTCAT ENT(/) ALL of the file?
>
>Leo
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Nai, Dean
>Sent: Wednesday, November 13, 2019 4:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFDSS backup retore
>
>Looked at Ca1 catalog and os catalog. Label is correct. We are running 2.3 
>Dean Nai   
>Senior z/OS Systems Programmer 
>Technical Services Group
>Department of Information Technology
>State of New Hampshire
>27 Hazen Drive
>Concord, NH 03301
> work: 603-271-1529
>
>
>Statement of Confidentiality: The contents of this message are
>confidential.
>Any unauthorized disclosure, reproduction, use or dissemination (either
>whole or in part) is prohibited. If you are not the intended recipient of
>this message, please notify the sender immediately and delete the message
>from your system.
>
>
>
>
>
>
>
>
>
>On 11/13/19, 3:57 PMEST, "IBM Mainframe Discussion List on behalf of Carmen 
>Vitullo"  wrote:
>
>> EXTERNAL:  Do not open attachments or click on links unless you recognize 
>> and trust the sender.
>>
>>I want to assume the tapes used to restore the volume are cataloged and you 
>>are using the catalog? 
>>
>>
>>
>>During a RESTORE, the sequence number of the record read, 2 (in 
>>hexadecimal) did not match the previous record processed, 1 (in 
>>hexadecimal). If there is an end of volume involved, a tape might have been 
>>mounted in the wrong sequence. 
>>
>>
>>
>>
>>
>>or a very old APAR 
>>
>>
>>
>>
>>
>>https://urldefense.com/v3/__https://www-01.ibm.com/support/docview.wss?uid=isg1OA46522__;!eeWmBe9sc1cuNw!F9dfrqbRDFdqANDbAYzH3fI-3PYk5ndProLx_v4VU98Ok7juTJsVbHWwDL1zH-xsYQ$
>>  
>>
>>
>>
>>
>>
>>Carmen Vitullo 
>>
>>
>>
>>- Original Message -
>>
>>
>>
>>From: "Dean Nai"  
>>
>>To: IBM-MAIN@LISTSERV.UA.EDU 
>>
>>Sent: Wednesday, November 13, 2019 2:43:51 PM 
>>
>>Subject: Re: DFDSS backup retore 
>>
>>
>>
>>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>>
>>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
>>STATEMENTS COMPLETED 
>>
>>ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
>>
>>ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS 
>>
>>ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
>>VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION 
>>
>>2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 
>>
>>ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
>>FROM A CONDITIONED VOLUME 
>>
>>ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON DDNAME INDD1 LAST 
>>0020 NEXT 0021 
>>
>>ADR006I (001)-STEND(02), 2019.317 14:11:06 EXECUTION ENDS 
>>
>>ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK COMPLETED WITH RETURN CODE 
>>0008 
>>
>>ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
>>HIGHEST RETURN CODE IS 0008 FROM: 
>>
>>TASK 001 
>>
>>
>>
>>Dean Nai 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
>>mainframer"  
>>wrote: 
>>
>>
>>
>>> EXTERNAL: Do not open attachments or click on links unless you recognize 
>>> and trust the sender. 
>>
>>> 
>>
>>>Please provide the complete error message. 
>>
>>> 
>>
>>>The error message does not address tape labels. (A wrong label would produce 
>>>a system 

Re: DFDSS backup retore

[Leonardo Vaz]

Is the dataset on a single tape volume or multiple? Can you provide the LISTCAT 
ENT(/) ALL of the file?

Leo
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nai, Dean
Sent: Wednesday, November 13, 2019 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS backup retore

Looked at Ca1 catalog and os catalog. Label is correct. We are running 2.3 
Dean Nai
Senior z/OS Systems Programmer  
Technical Services Group
Department of Information Technology
State of New Hampshire
27 Hazen Drive
Concord, NH 03301
 work: 603-271-1529


Statement of Confidentiality: The contents of this message are
confidential.
Any unauthorized disclosure, reproduction, use or dissemination (either
whole or in part) is prohibited. If you are not the intended recipient of
this message, please notify the sender immediately and delete the message
from your system.









On 11/13/19, 3:57 PMEST, "IBM Mainframe Discussion List on behalf of Carmen 
Vitullo"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>I want to assume the tapes used to restore the volume are cataloged and you 
>are using the catalog? 
>
>
>
>During a RESTORE, the sequence number of the record read, 2 (in 
>hexadecimal) did not match the previous record processed, 1 (in 
>hexadecimal). If there is an end of volume involved, a tape might have been 
>mounted in the wrong sequence. 
>
>
>
>
>
>or a very old APAR 
>
>
>
>
>
>https://urldefense.com/v3/__https://www-01.ibm.com/support/docview.wss?uid=isg1OA46522__;!eeWmBe9sc1cuNw!F9dfrqbRDFdqANDbAYzH3fI-3PYk5ndProLx_v4VU98Ok7juTJsVbHWwDL1zH-xsYQ$
>  
>
>
>
>
>
>Carmen Vitullo 
>
>
>
>- Original Message -
>
>
>
>From: "Dean Nai"  
>
>To: IBM-MAIN@LISTSERV.UA.EDU 
>
>Sent: Wednesday, November 13, 2019 2:43:51 PM 
>
>Subject: Re: DFDSS backup retore 
>
>
>
>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>
>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
>STATEMENTS COMPLETED 
>
>ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
>
>ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS 
>
>ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
>VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION 
>
>2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 
>
>ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
>FROM A CONDITIONED VOLUME 
>
>ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON DDNAME INDD1 LAST 0020 
>NEXT 0021 
>
>ADR006I (001)-STEND(02), 2019.317 14:11:06 EXECUTION ENDS 
>
>ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK COMPLETED WITH RETURN CODE 
>0008 
>
>ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
>HIGHEST RETURN CODE IS 0008 FROM: 
>
>TASK 001 
>
>
>
>Dean Nai 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
>mainframer"  
>wrote: 
>
>
>
>> EXTERNAL: Do not open attachments or click on links unless you recognize and 
>> trust the sender. 
>
>> 
>
>>Please provide the complete error message. 
>
>> 
>
>>The error message does not address tape labels. (A wrong label would produce 
>>a system error before DFDSS got to the tape.) It says the sequence number of 
>>data records is wrong. This may indicate a corrupt file. 
>
>> 
>
>>What system level are you at. There is a 5 year old APAR that addresses this 
>>issue. 
>
>> 
>
>>> -Original Message- 
>
>>> From: IBM Mainframe Discussion List  On 
>
>>> Behalf Of Nai, Dean 
>
>>> Sent: Wednesday, November 13, 2019 11:55 AM 
>
>>> To: IBM-MAIN@LISTSERV.UA.EDU 
>
>>> Subject: DFDSS backup retore 
>
>>> 
>
>>> Has anyone ever run into a problem where they have full volume backups that 
>>> produce 
>
>>> a ADR370E message when trying to restore? That message says the label and 
>>> DSN on 
>
>>> the tape don't match although I know they do. Any thoughts? 
>
>>> 
>
>>> Control cards: 
>
>>> 
>
>>> Restore - 
>
>>> Admin - 
>
>>> Inddname(indd1) outddname(outdd1) - 
>
>>> Full purge copyvolid 
>
>>> 
>
>>> //indd1 dd 
>
>>> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=ser=tap001
>&g

Re: DFDSS backup retore

[Nai, Dean]

Looked at Ca1 catalog and os catalog. Label is correct. We are running 2.3 
Dean Nai
Senior z/OS Systems Programmer  
Technical Services Group
Department of Information Technology
State of New Hampshire
27 Hazen Drive
Concord, NH 03301
 work: 603-271-1529


Statement of Confidentiality: The contents of this message are
confidential.
Any unauthorized disclosure, reproduction, use or dissemination (either
whole or in part) is prohibited. If you are not the intended recipient of
this message, please notify the sender immediately and delete the message
from your system.









On 11/13/19, 3:57 PMEST, "IBM Mainframe Discussion List on behalf of Carmen 
Vitullo"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>I want to assume the tapes used to restore the volume are cataloged and you 
>are using the catalog? 
>
>
>
>During a RESTORE, the sequence number of the record read, 2 (in 
>hexadecimal) did not match the previous record processed, 1 (in 
>hexadecimal). If there is an end of volume involved, a tape might have been 
>mounted in the wrong sequence. 
>
>
>
>
>
>or a very old APAR 
>
>
>
>
>
>https://urldefense.com/v3/__https://www-01.ibm.com/support/docview.wss?uid=isg1OA46522__;!eeWmBe9sc1cuNw!F9dfrqbRDFdqANDbAYzH3fI-3PYk5ndProLx_v4VU98Ok7juTJsVbHWwDL1zH-xsYQ$
>  
>
>
>
>
>
>Carmen Vitullo 
>
>
>
>- Original Message -
>
>
>
>From: "Dean Nai"  
>
>To: IBM-MAIN@LISTSERV.UA.EDU 
>
>Sent: Wednesday, November 13, 2019 2:43:51 PM 
>
>Subject: Re: DFDSS backup retore 
>
>
>
>ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
>
>ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
>STATEMENTS COMPLETED 
>
>ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
>
>ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS 
>
>ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
>VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION 
>
>2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 
>
>ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
>FROM A CONDITIONED VOLUME 
>
>ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON DDNAME INDD1 LAST 0020 
>NEXT 0021 
>
>ADR006I (001)-STEND(02), 2019.317 14:11:06 EXECUTION ENDS 
>
>ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK COMPLETED WITH RETURN CODE 
>0008 
>
>ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
>HIGHEST RETURN CODE IS 0008 FROM: 
>
>TASK 001 
>
>
>
>Dean Nai 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
>mainframer"  
>wrote: 
>
>
>
>> EXTERNAL: Do not open attachments or click on links unless you recognize and 
>> trust the sender. 
>
>> 
>
>>Please provide the complete error message. 
>
>> 
>
>>The error message does not address tape labels. (A wrong label would produce 
>>a system error before DFDSS got to the tape.) It says the sequence number of 
>>data records is wrong. This may indicate a corrupt file. 
>
>> 
>
>>What system level are you at. There is a 5 year old APAR that addresses this 
>>issue. 
>
>> 
>
>>> -Original Message- 
>
>>> From: IBM Mainframe Discussion List  On 
>
>>> Behalf Of Nai, Dean 
>
>>> Sent: Wednesday, November 13, 2019 11:55 AM 
>
>>> To: IBM-MAIN@LISTSERV.UA.EDU 
>
>>> Subject: DFDSS backup retore 
>
>>> 
>
>>> Has anyone ever run into a problem where they have full volume backups that 
>>> produce 
>
>>> a ADR370E message when trying to restore? That message says the label and 
>>> DSN on 
>
>>> the tape don't match although I know they do. Any thoughts? 
>
>>> 
>
>>> Control cards: 
>
>>> 
>
>>> Restore - 
>
>>> Admin - 
>
>>> Inddname(indd1) outddname(outdd1) - 
>
>>> Full purge copyvolid 
>
>>> 
>
>>> //indd1 dd 
>
>>> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=ser=tap001
>>>  
>
>>> //outdd1 dd vol=ser=sc560c,unit=3390,disp=old 
>
>>> 
>
>>> Dean Nai 
>
>> 
>
>>-- 
>
>>For IBM-MAIN subscribe / signoff / archive access instructions, 
>
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>
>
>
>-- 
>
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>
>
>
>
>
>--
>
>For IBM-MAIN subscribe / signoff / archive access instructions,
>
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Carmen Vitullo]

I want to assume the tapes used to restore the volume are cataloged and you are 
using the catalog? 

During a RESTORE, the sequence number of the record read, 2 (in 
hexadecimal) did not match the previous record processed, 1 (in 
hexadecimal). If there is an end of volume involved, a tape might have been 
mounted in the wrong sequence. 


or a very old APAR 


https://www-01.ibm.com/support/docview.wss?uid=isg1OA46522 


Carmen Vitullo 

- Original Message -

From: "Dean Nai"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, November 13, 2019 2:43:51 PM 
Subject: Re: DFDSS backup retore 

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' 
ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED 
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 
ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS 
ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION 
2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 
ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
FROM A CONDITIONED VOLUME 
ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON DDNAME INDD1 LAST 0020 
NEXT 0021 
ADR006I (001)-STEND(02), 2019.317 14:11:06 EXECUTION ENDS 
ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK COMPLETED WITH RETURN CODE 0008 
ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS 0008 FROM: 
TASK 001 

Dean Nai 







On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
mainframer"  
wrote: 

> EXTERNAL: Do not open attachments or click on links unless you recognize and 
> trust the sender. 
> 
>Please provide the complete error message. 
> 
>The error message does not address tape labels. (A wrong label would produce a 
>system error before DFDSS got to the tape.) It says the sequence number of 
>data records is wrong. This may indicate a corrupt file. 
> 
>What system level are you at. There is a 5 year old APAR that addresses this 
>issue. 
> 
>> -Original Message- 
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Nai, Dean 
>> Sent: Wednesday, November 13, 2019 11:55 AM 
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> Subject: DFDSS backup retore 
>> 
>> Has anyone ever run into a problem where they have full volume backups that 
>> produce 
>> a ADR370E message when trying to restore? That message says the label and 
>> DSN on 
>> the tape don't match although I know they do. Any thoughts? 
>> 
>> Control cards: 
>> 
>> Restore - 
>> Admin - 
>> Inddname(indd1) outddname(outdd1) - 
>> Full purge copyvolid 
>> 
>> //indd1 dd 
>> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=ser=tap001
>>  
>> //outdd1 dd vol=ser=sc560c,unit=3390,disp=old 
>> 
>> Dean Nai 
> 
>-- 
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[Nai, Dean]

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS
ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL 
VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION
 2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53
ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED 
FROM A CONDITIONED VOLUME
ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON DDNAME INDD1 LAST 0020 
NEXT 0021
ADR006I (001)-STEND(02), 2019.317 14:11:06 EXECUTION ENDS
ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK COMPLETED WITH RETURN CODE 0008
ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS 0008 FROM:
 TASK001

Dean Nai







On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired 
mainframer"  
wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Please provide the complete error message.
>
>The error message does not address tape labels.  (A wrong label would produce 
>a system error before DFDSS got to the tape.)  It says the sequence number of 
>data records is wrong.  This may indicate a corrupt file.
>
>What system level are you at.  There is a 5 year old APAR that addresses this 
>issue.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Nai, Dean
>> Sent: Wednesday, November 13, 2019 11:55 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: DFDSS backup retore
>> 
>> Has anyone ever run into a problem where they have full volume backups that 
>> produce
>> a ADR370E message when trying to restore? That message says the label and 
>> DSN on
>> the tape don't match although I know they do. Any thoughts?
>> 
>> Control cards:
>> 
>> Restore -
>> Admin -
>> Inddname(indd1) outddname(outdd1) -
>> Full purge copyvolid
>> 
>> //indd1  dd
>> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=ser=tap001
>> //outdd1 dd vol=ser=sc560c,unit=3390,disp=old
>> 
>> Dean Nai
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS backup retore

[retired mainframer]

Please provide the complete error message.

The error message does not address tape labels.  (A wrong label would produce a 
system error before DFDSS got to the tape.)  It says the sequence number of 
data records is wrong.  This may indicate a corrupt file.

What system level are you at.  There is a 5 year old APAR that addresses this 
issue.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Nai, Dean
> Sent: Wednesday, November 13, 2019 11:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFDSS backup retore
> 
> Has anyone ever run into a problem where they have full volume backups that 
> produce
> a ADR370E message when trying to restore? That message says the label and DSN 
> on
> the tape don't match although I know they do. Any thoughts?
> 
> Control cards:
> 
> Restore -
> Admin -
> Inddname(indd1) outddname(outdd1) -
> Full purge copyvolid
> 
> //indd1  dd
> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=ser=tap001
> //outdd1 dd vol=ser=sc560c,unit=3390,disp=old
> 
> Dean Nai

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Richards, Robert B.]

> IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS  IGD01014I DATA SET 
> ALLOCATION REQUEST FAILED -  SPECIFIED STORCLAS STDSYS DOES NOT EXIST

Doesn't Elaine need to resolve the non-existent storclas (STDSYS) first? The 
rest of the recommendation are nice too! :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Thursday, May 23, 2019 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

STORCLAS(desired storclas) BYPASSACS(**)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elaine Beal
Sent: Thursday, May 23, 2019 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I'm copying disk to disk.
source file is 2 volumes and I want to copy (expand) to pre-allocated, 
catalogued 3 volume file.
I modified the  OUTDDNAME(DASD2) to include all 3 (new) volumes.

The issue (now) is that the copy is trying to use the original STORCLAS but the 
new file is a different STORCLAS

ADR709E (001)-ACS  (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM 
WHILE DETERMINING SMS CONSTRUCTS FOR DATA SET
 SYS7.R30.V22.ROOT.HFS WITH NEWNAME 
SYS7.R30.V22.RSU.ROOT.HFS. SMS MESSAGES FOLLOW.
 IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS  IGD01014I DATA SET 
ALLOCATION REQUEST FAILED -  SPECIFIED STORCLAS STDSYS DOES NOT EXIST


JCL -

//COPYSTEP EXEC PGM=ADRDSSU
//SYSPRINT DD   SYSOUT=*
//DASD1DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS050,SSS051)
//DASD2DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS052,SSS053,SSS054)
//SYSINDD   *
   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
   LOGINDDNAME(DASD1)  -
   OUTDDNAME(DASD2)  -
   SELECTMULTI(ANY)  -
   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
   SYS7.R30.V22.RSU.ROOT.HFS)) -
REPLACEUNCONDITIONAL   -
   ALLDATA(*) ALLEXCP CANCELERROR -
   SHARE -
   WRITECHECK

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Jackson, Rob]

BYPASSACS(**) -
STORCLAS(x) - 
ADMINISTRATOR -

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elaine Beal
Sent: Thursday, May 23, 2019 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

[External Email]

I'm copying disk to disk.
source file is 2 volumes and I want to copy (expand) to pre-allocated, 
catalogued 3 volume file.
I modified the  OUTDDNAME(DASD2) to include all 3 (new) volumes.

The issue (now) is that the copy is trying to use the original STORCLAS but the 
new file is a different STORCLAS

ADR709E (001)-ACS  (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM 
WHILE DETERMINING SMS CONSTRUCTS FOR DATA SET
 SYS7.R30.V22.ROOT.HFS WITH NEWNAME 
SYS7.R30.V22.RSU.ROOT.HFS. SMS MESSAGES FOLLOW.
 IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS  IGD01014I DATA SET 
ALLOCATION REQUEST FAILED -  SPECIFIED STORCLAS STDSYS DOES NOT EXIST


JCL -

//COPYSTEP EXEC PGM=ADRDSSU
//SYSPRINT DD   SYSOUT=*
//DASD1DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS050,SSS051)
//DASD2DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS052,SSS053,SSS054)
//SYSINDD   *
   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
   LOGINDDNAME(DASD1)  -
   OUTDDNAME(DASD2)  -
   SELECTMULTI(ANY)  -
   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
   SYS7.R30.V22.RSU.ROOT.HFS)) -
REPLACEUNCONDITIONAL   -
   ALLDATA(*) ALLEXCP CANCELERROR -
   SHARE -
   WRITECHECK

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FIRST TENNESSEE

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Mark Jacobs]

Storageclass ACS routine error, or the storage administrator deleted the STDSTS 
STORCLAS from the active SMS environment?

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Thursday, May 23, 2019 12:56 PM, Elaine Beal  wrote:

> I'm copying disk to disk.
> source file is 2 volumes and I want to copy (expand) to pre-allocated, 
> catalogued 3 volume file.
> I modified the OUTDDNAME(DASD2) to include all 3 (new) volumes.
>
> The issue (now) is that the copy is trying to use the original STORCLAS but 
> the new file is a different STORCLAS
>
> ADR709E (001)-ACS (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM 
> WHILE DETERMINING SMS CONSTRUCTS FOR DATA SET
> SYS7.R30.V22.ROOT.HFS WITH NEWNAME SYS7.R30.V22.RSU.ROOT.HFS. SMS MESSAGES 
> FOLLOW.
> IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS
> IGD01014I DATA SET ALLOCATION REQUEST FAILED -
> SPECIFIED STORCLAS STDSYS DOES NOT EXIST
>
> JCL -
>
> //COPYSTEP EXEC PGM=ADRDSSU
> //SYSPRINT DD SYSOUT=*
> //DASD1 DD DISP=SHR,UNIT=3390,VOL=SER=(SSS050,SSS051)
> //DASD2 DD DISP=SHR,UNIT=3390,VOL=SER=(SSS052,SSS053,SSS054)
> //SYSIN DD *
> COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS)) -
> LOGINDDNAME(DASD1) -
> OUTDDNAME(DASD2) -
> SELECTMULTI(ANY) -
> RENAMEU((SYS7.R30.V22.ROOT.HFS, -
> SYS7.R30.V22.RSU.ROOT.HFS)) -
> REPLACEUNCONDITIONAL -
> ALLDATA(*) ALLEXCP CANCELERROR -
> SHARE -
> WRITECHECK
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Allan Staller]

STORCLAS(desired storclas) BYPASSACS(**)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elaine Beal
Sent: Thursday, May 23, 2019 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I'm copying disk to disk.
source file is 2 volumes and I want to copy (expand) to pre-allocated, 
catalogued 3 volume file.
I modified the  OUTDDNAME(DASD2) to include all 3 (new) volumes.

The issue (now) is that the copy is trying to use the original STORCLAS but the 
new file is a different STORCLAS

ADR709E (001)-ACS  (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM 
WHILE DETERMINING SMS CONSTRUCTS FOR DATA SET
 SYS7.R30.V22.ROOT.HFS WITH NEWNAME 
SYS7.R30.V22.RSU.ROOT.HFS. SMS MESSAGES FOLLOW.
 IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS  IGD01014I DATA SET 
ALLOCATION REQUEST FAILED -  SPECIFIED STORCLAS STDSYS DOES NOT EXIST


JCL -

//COPYSTEP EXEC PGM=ADRDSSU
//SYSPRINT DD   SYSOUT=*
//DASD1DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS050,SSS051)
//DASD2DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS052,SSS053,SSS054)
//SYSINDD   *
   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
   LOGINDDNAME(DASD1)  -
   OUTDDNAME(DASD2)  -
   SELECTMULTI(ANY)  -
   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
   SYS7.R30.V22.RSU.ROOT.HFS)) -
REPLACEUNCONDITIONAL   -
   ALLDATA(*) ALLEXCP CANCELERROR -
   SHARE -
   WRITECHECK

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Elaine Beal]

I'm copying disk to disk.
source file is 2 volumes and I want to copy (expand) to pre-allocated, 
catalogued 3 volume file.
I modified the  OUTDDNAME(DASD2) to include all 3 (new) volumes.

The issue (now) is that the copy is trying to use the original STORCLAS but the 
new file is a different STORCLAS

ADR709E (001)-ACS  (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM 
WHILE DETERMINING SMS CONSTRUCTS FOR DATA SET
 SYS7.R30.V22.ROOT.HFS WITH NEWNAME 
SYS7.R30.V22.RSU.ROOT.HFS. SMS MESSAGES FOLLOW.
 IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS
 IGD01014I DATA SET ALLOCATION REQUEST FAILED -
 SPECIFIED STORCLAS STDSYS DOES NOT EXIST


JCL -

//COPYSTEP EXEC PGM=ADRDSSU
//SYSPRINT DD   SYSOUT=*
//DASD1DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS050,SSS051)
//DASD2DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS052,SSS053,SSS054)
//SYSINDD   *
   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
   LOGINDDNAME(DASD1)  -
   OUTDDNAME(DASD2)  -
   SELECTMULTI(ANY)  -
   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
   SYS7.R30.V22.RSU.ROOT.HFS)) -
REPLACEUNCONDITIONAL   -
   ALLDATA(*) ALLEXCP CANCELERROR -
   SHARE -
   WRITECHECK

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Elaine Beal]

Robert,

Thank you- duh, read the whole error message:(
I was looking at only the first xxx reason code.

Elaine

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Robert2 Gensler]

Hi Elaine,

Assuming you are getting a ADR380E reason code 75, the message is saying
that sys7.r30.v22.root.hfs resides on more volumes than just the volume
pointed to by DASD1.  It was mentioned by a couple people already to
specify SELECTMULTI(ANY), that should do the trick for you.  If not, please
include the entire error message and I will see what I can do.

Thanks,
Robert
DFSMSdss Architecture and Development
Tucson, AZ
rgen...@us.ibm.com

IBM Mainframe Discussion List  wrote on
05/16/2019 05:50:46 PM:

> From: Elaine Beal 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/16/2019 05:51 PM
> Subject: [EXTERNAL] DFDSS copy to pre-allocated dsn
> Sent by: IBM Mainframe Discussion List 
>
> I've found a lot of " it's " confusing comments on this topic and I
> am beleaguered-
> I am trying to copy a file to an existing, pre-allocated new name.
> Seems that should be pretty straight forward... but having to
> specify rename to make a copy is anything but straight forward
>
> I'm getting ADR380E (001)-FDSCO(08) indicating REPLACEUNCONDITIONAL
> is not specified
> but I get this whether I specify it or not-
>
>
>   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
>   LOGINDDNAME(DASD1)  -
>   OUTDDNAME(DASD2,DASD3,DASD4)  -
>   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
>   SYS7.R30.V22.RSU.ROOT.HFS)) -
>   REPLACEUNCONDITIONAL   -
>   NULLSTORCLAS BYPASSACS(**) -
>   ALLDATA(*) ALLEXCP CANCELERROR -
>   SHARE -
>   WRITECHECK
>
> Thanks for any help-
> Elaine
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFDSS copy to pre-allocated dsn

[Paul Gilmartin]

On 2019-05-17, at 07:58:45, Styles, Andy (ITS zPlatform Services) wrote:

> Assuming we're talking copying to disk (I'm not sure you could copy a dataset 
> to tape, never tried),
> but ZFS's, being VSAM, must be cataloged; you couldn't thus copy a ZFS to two 
> different volumes
> with the same dataset name because of the catalog clash.
>  
Could it be catalogued in a different catalog?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN