If I have a volume backed up using ADRDSSU 1.11 (DUMP DATASET) is
possible to restore it using ADRDSSU 1.10? (backward compatibility)
--
Carlos Bodra
São Paulo - SP Brazil
--
For IBM-MAIN subscribe / signoff / archive access
On Fri, 18 Nov 2011 10:26:32 -0200, Carlos Bodra - Pessoal wrote:
If I have a volume backed up using ADRDSSU 1.11 (DUMP DATASET) is
possible to restore it using ADRDSSU 1.10? (backward compatibility)
--
Yes, if the coexistence and fallback PTFs are installed on z/OS 1.10
http
On 11/18/2011 07:11 AM, Norbert Friemel wrote:
On Fri, 18 Nov 2011 10:26:32 -0200, Carlos Bodra - Pessoal wrote:
If I have a volume backed up using ADRDSSU 1.11 (DUMP DATASET) is
possible to restore it using ADRDSSU 1.10? (backward compatibility)
--
Yes, if the coexistence and fallback PTFs
On 11/18/2011 08:18 AM, Norbert Friemel wrote:
On Fri, 18 Nov 2011 07:42:34 -0600, Joel C. Ewing wrote:
...
But, take note that this backward compatibility does not always exist.
It seems that about every ten years or so as tape technology advances
IBM decides to raise the block size written
I'm glad to know n-2 compatibility is now supported. If that were true long
ago when the previous dfdss 64KiB change was made, it
certainly wasn't advertised then.
Funny, I thought n-1 was supported for a long time!
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
On 11/18/2011 04:15 PM, Ted MacNEIL wrote:
I'm glad to know n-2 compatibility is now supported. If that were true long
ago when the previous dfdss 64KiB change was made, it
certainly wasn't advertised then.
Funny, I thought n-1 was supported for a long time!
-
Ted MacNEIL
eamacn...@yahoo.ca
Still on z/OS 1.10. 1.12 is in the works, but due to a problem caused by lack
of a maintenance contract, we need to be off of a vendor product before we can
convert.
Somewhat on topic to this is an interesting discovery I made. If you do a
logical dump of a multivolume VSAM KSDS using ADRDSSU
I've been asked a question that I can't find the answer to. We are dumping VSAM
KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this
reorganized the file, removing CA and CI splits and compressing the data
back in physical/logical order? Or is it more like a physical
W dniu 2011-10-12 14:41, McKown, John pisze:
I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using
ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file,
removing CA and CI splits and compressing the data back in physical
@bama.ua.edu
Subject: ADRDSSU logical dump of VSAM restore
I've been asked a question that I can't find the answer to. We are dumping VSAM
KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this
reorganized the file, removing CA and CI splits and compressing the data
back
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of McKown, John
I've been asked a question that I can't find the answer to. We are
dumping VSAM KSDSes using ADRDSSU
in logical dump mode. We then do a RESTORE. Does this reorganized
the file, removing CA and CI
splits
, 2011 7:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU logical dump of VSAM restore
A Listcat of the restored file should answer that question.
I think Idcams Export/Import is invoked under the covers but
I could be mistaken about that.
-Original Message-
From: McKown, John
REC-DELETED---18 SPLITS-CA--0
---1
-Original Message-
From: Chase, John [mailto:jch...@ussco.com]
Sent: Wednesday, October 12, 2011 8:58 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU
Are you able to Listcat ent(/) all
From ISPF 3.4 screen?
-Original Message-
From: McKown, John [mailto:john.mck...@healthmarkets.com]
Sent: Wednesday, October 12, 2011 9:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU logical dump of VSAM restore
Thanks. The problem
and The
MEGA Life and Health Insurance Company.SM
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W.
(NIH/CIT) [C]
Sent: Wednesday, October 12, 2011 8:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU logical dump of VSAM
On Wed, 12 Oct 2011 07:41:49 -0500, McKown, John wrote:
I've been asked a question that I can't find the answer to. We are dumping
VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does
this reorganized the file, removing CA and CI splits and compressing the
data back
If you're on z/OS R12, you might consider using CA Reclaim rather than
re-orging KSDSs.
McKown, John wrote:
I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using
ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file
While I am not certain of any magical incantations, if you update the
DATACLAS for the existing data sets with the desired EATTR value then, during a
DSS COPY, the new allocation of these data sets should be allocated with the
new EATTR value you defined. You could also define a new DATACLAS,
On 10/10/2011 10:18 AM, Justin Eastman wrote:
While I am not certain of any magical incantations, if you update the
DATACLAS for the existing data sets with the desired EATTR value then, during a DSS COPY,
the new allocation of these data sets should be allocated with the new EATTR value you
EATTR only specifies whether a data set is allocated with F8/F9 DSCBs. In
order for a data set to be allocated to the cylinder managed space, it must
have EATTR = OPT (or EATTR=NS for VSAM as the default is to have F8/F9 DSCBs)
and then it must be larger than the defined Break Point Value(BPV)
On 10/10/2011 12:07 PM, Justin Eastman wrote:
EATTR only specifies whether a data set is allocated with F8/F9 DSCBs. In
order for a data set to be allocated to the cylinder managed space, it must
have EATTR = OPT (or EATTR=NS for VSAM as the default is to have F8/F9 DSCBs)
and then it must
On 10/6/2011 8:58 AM, Edward Jaffe wrote:
http://www.redbooks.ibm.com/redbooks/SG247768/wwhelp/wwhimpl/api.htm?href=4-3-3.htm
contains:
IBM ITSO Documentation
[Snip]
To change the EATTR value after a new allocation requires you to run the AMS
ALTER command.
[Snip]
/IBM ITSO Documentation
Maybe you could preallocate it. Probably not what you were looking for though.
The other option is an exit 28, Target dataset allocation exit.
MA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
On 10/6/2011 5:13 AM, Mary Anne Matyaz wrote:
Maybe you could preallocate it. Probably not what you were looking for though.
The other option is an exit 28, Target dataset allocation exit.
We want to move literally hundreds--maybe thousands--of data sets into the EAS,
so pre-allocating
Ed,
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.adru000%2Fexit28.htm
I suspect preallocate is going to be the answer until DSS supports it. The
reason I say this is from the RECLAIMCA doc:
You may use data set RESTORE to upgrade your non CA Reclaim
Sorry Ed, I guess I didn't answer your question. This is ADRUIXIT.
And, I didn't look at z/os 1.13 manuals...I'm in day four of downloading my
serverpak. :(
MA
--
For IBM-MAIN subscribe / signoff / archive access
Sorry, ADRUIXIT isn't going to work. It seems the only way to get the UIM is to
invoke adrdssu programmatically.
MA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu
http://www.redbooks.ibm.com/redbooks/SG247768/wwhelp/wwhimpl/api.htm?href=4-3-3.htm
contains:
IBM ITSO Documentation
In z/OS V1.10, customers controlled whether VSAM data sets could reside in the
EAS by including or excluding EAVs in particular storage groups. For non-SMS
managed data sets,
I need to know the magical incantations necessary to copy (via ADRDSSU) files
from a normal-sized DASD volume to the EAS of a target EAV. The existing files
are allocated with EATTR=NO. We would like them automatically changed to
EATTR=OPT by the copy process so they will reside in the EAS
Hello List,
We are running ZOS 1.12 here, under Z/VM.
We want, execute a BACKUP from our production , and restore to another CMS
MACHINE.
We have a cartridge , with ADRDSSU STANDALONE.
If we do a backup from all dasd with the job like this :
//ZOSBKP JOB (SUPORTE),'BKP-DB2',CLASS=S
1.12 here, under Z/VM.
=
= We want, execute a BACKUP from our production , and restore to another
= CMS MACHINE.
=
= We have a cartridge , with ADRDSSU STANDALONE.
=
= If we do a backup from all dasd with the job like this :
=
= //ZOSBKP JOB (SUPORTE),'BKP-DB2',CLASS=S,
= // MSGCLASS=H
@bama.ua.edu] Em nome de J.
Cassidy
Enviada em: segunda-feira, 19 de setembro de 2011 16:18
Para: IBM-MAIN@bama.ua.edu
Assunto: Re: Guff! ADRDSSU Restore
Sergio,
I presume when you say CMS you mean another z/OS instance under z/VM.
If this is the case, you can avoid the MVS JCL and use good ole
Hi,
I was trying to restore some dataset using the below JCL :
01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B,
02 // REGION=0M,NOTIFY=SYSUID
03 //RESTORE EXEC PGM=ADRDSSU
04 //TAPE DD UNIT=680,DISP=SHR,LABEL=(1,SL),
05 //DSN=BACKUP.USRBKP,VOL=SER=USRBKP
On Wed, Jun 22, 2011 at 10:32 AM, jagadishan perumal
jagadish...@gmail.comwrote:
Hi,
I was trying to restore some dataset using the below JCL :
01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B,
02 // REGION=0M,NOTIFY=SYSUID
03 //RESTORE EXEC PGM=ADRDSSU
04
,
I was trying to restore some dataset using the below JCL :
01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B,
02 // REGION=0M,NOTIFY=SYSUID
03 //RESTORE EXEC PGM=ADRDSSU
04 //TAPE DD UNIT=680,DISP=SHR,LABEL=(1,SL),
05 //DSN=BACKUP.USRBKP,VOL=SER=USRBKP
read the TAPE1
input -
15.19.25 JOB02012 IEC036I
002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK
are you sure that this tape was created using ADRDSSU.
Jim McAlpine
--
For IBM-MAIN subscribe / signoff / archive access
ADRDSSU.
Jim McAlpine
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
jagadishan perumal wrote:
15.19.25 JOB02012 IEC036I
002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK
Do a TAPEMAP on that volume and post the result here.
I really doubt your tape was written correctly in the backup stage.
Groete / Greetings
Elardus Engelbrecht
Hi,
The back up went fine with CC=0. Below is my JCL
//BACKUP$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=T,
// REGION=5M,NOTIFY=SYSUID
//DUMPDS EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//DASD1 DD VOL=SER=LDSN16,UNIT=3390,DISP=SHR
//DASD2 DD VOL=SER=LDSN15,UNIT=3390
15.19.25 JOB02012 IEC036I
002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK
are you sure that this tape was created using ADRDSSU.
01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B,
02 // REGION=0M,NOTIFY=SYSUID
03 //RESTORE EXEC PGM=ADRDSSU
04 //TAPE DD UNIT
for
Innovation Data Processing, Inc.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of jagadishan perumal
Sent: Wednesday, 22 June 2011 8:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Restore Error - Adrdssu
Hi,
The back up went fine
On Wed, Jun 22, 2011 at 12:28 PM, Stephen Mednick ibmm...@css.au.comwrote:
Hi Jagadishan.
Did you really run the JCL with PARM='TYPRUN=NORUN'?
If you did, the backup didn't actually run because the TYPRUN=NORUN parm
specifies that the DUMP option will only be simulated!
Stephen Mednick
Stephen Mednick wrote:
Did you really run the JCL with PARM='TYPRUN=NORUN'?
Hopefully not, because there is no comma to the left of PARM and we should
see ADR031I if it was really mentioned.
Groete / Greetings
Elardus Engelbrecht
-MAIN@bama.ua.edu] On Behalf
Of Elardus Engelbrecht
Sent: Wednesday, 22 June 2011 9:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Restore Error - Adrdssu
Stephen Mednick wrote:
Did you really run the JCL with PARM='TYPRUN=NORUN'?
Hopefully not, because there is no comma to the left of PARM and we should
Stephen Mednick wrote:
Yes you're right, I missed seeing it.
Nevermind. It is all right!
Getting late here and the eyes are droopy!
Get a cup of good strong coffee for your eye! :-D
:-D
Groete / Greetings
Elardus Engelbrecht
It must be some kind of mistakes , if you look further down yo see:
ADR454I (001)-DTDSC(01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY
PROCESSED
mace
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
To: IBM-MAIN@bama.ua.edu
Subject: Re: Restore Error - Adrdssu
Hi,
The back up went fine with CC=0. Below is my JCL
//BACKUP$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=T,
// REGION=5M,NOTIFY=SYSUID
//DUMPDS EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//DASD1 DD VOL=SER=LDSN16
In banlktikhgiqgw7zlhn4eedn5eyzu0u+...@mail.gmail.com, on 06/22/2011
at 03:02 PM, jagadishan perumal jagadish...@gmail.com said:
Could'nt figure out the exact syntax error with my JCL.
If there had been a syntax error then your job wouldn't have run.
IEC036I
Hi,
The back up was taken at V1R6 and the restoration is happening at v1r12. Is
there any version incompatibility.
now i get
U195530
1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173
19:20
-ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN
NORUN MO
i have figured out the problem. Parm='type=norun' was just printing
not restoring. . so took of this parameter and everything went fine.
thanks all
On 6/22/11, jagadishan perumal jagadish...@gmail.com wrote:
Hi,
The back up was taken at V1R6 and the restoration is happening at v1r12. Is
there
Jags,
PARM='TYPRUN=NORUN' will show you how the restore could go.
So it says it will restore all files but the following
U195530.SPFLOG1.LIST 0
U195530.ISPF.ISPPROF 0
So I am not sure what your issue is now. You are using different datasets
from the original question you posted. Before you
On Wed, Jun 22, 2011 at 3:30 PM, jagadishan perumal
jagadish...@gmail.comwrote:
i have figured out the problem. Parm='type=norun' was just printing
not restoring. . so took of this parameter and everything went fine.
thanks all
Yes, but you had already made changes before that to make the
Could you eliminate the problem completely by directing the restore to a
different volume instead of the default?
Well, yes, of course, but that would require effort and aforethought on my part
... not bloody likely (grin)
Chris Hoelscher
IDMS DB2 Database Administrator
502-476-2538
You
I occasionally restore using ADRDSSU and rename the restored dataset to my HLQ
- so that I can have an older version of a dataset to compare to the current
dataset. By default (it appears) - the restore process will put the
restored/renamed dataset on the same DASD volume as from which
add DS(INCLUDE(**) EXCLUDE(SYS1.VTOC.**, SYS1.VVDS.**, *OMVS.**,
hlq.**)) or as you need. (we have a separate backup step for *OMVS*.**
files).
On Wed, May 18, 2011 at 12:02 PM, Chris Hoelscher choelsc...@humana.com wrote:
I occasionally restore using ADRDSSU and rename the restored dataset
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Chris Hoelscher
Sent: Wednesday, May 18, 2011 12:02 PM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS 1.11 question on DFDSS/ADRDSSU
I occasionally restore using ADRDSSU and rename the restored dataset to my HLQ
- so that I can have an older version of a dataset
Subject: z/OS 1.11 question on DFDSS/ADRDSSU
I occasionally restore using ADRDSSU and rename the restored dataset to my HLQ
- so that I can have an older version of a dataset to compare to the current
dataset. By default (it appears) - the restore process will put the
restored/renamed dataset
this ADRDSSU COPY,
1.in original post, there is no 'delete' parameter specified, but even so,
there are still some DataSets had been copied successfully. Do not know why,
may these copied ones are not cataloged? seems not the reason.
2.'PROCESS(SYS1)' is also not specified, but some SYS1.** get copied
VSAM data sets are required to be cataloged. If you look up the ADR468E
message is says:
If the REPLACE or REPLACEUNCONDITIONAL keyword was not specified, one of the
following conditions applies:
* If DELETE is specified and the entry name is a SYS1., page, or swap
data set, the
The error with the IODF (ADR468E) looks like it was caused by the lack of
PROCESS(SYS1) parameter.
On the other hand, the parameter for copying VSAM properly is SPHERE.
I copied your last try and it worked ok for me. Maybe the last //* is not
at the column 1?. I would delete it and try again
I
I am using below JCL and this also not able to backup VSAM dataset. I am
getting same error.
JCL
//DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
// NOTIFY=SYSUID
//STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//INVOL1DD VOL=SER
=(1,1),
// NOTIFY=SYSUID
//STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//INVOL1DD VOL=SER=DMTCAT,UNIT=3390,DISP=SHR
//OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR
//SYSIN DD *
COPY DATASET(INCLUDE
JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
// NOTIFY=SYSUID
//STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//INVOL1DD VOL=SER=DMTCAT,UNIT=3390,DISP=SHR
//OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR
//SYSIN DD
I am trying to copy my SYSRES volume( ex: IPE100) into one new
volume (
ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging.
As per my knowledge, only non SMS managed dataset used to be on RES volume.
Then I am not sure, why I am getting above
VSAM datasets If I remember are always SMS Managed and.
NO. I have several z/OS datasets on my SYSRES volume sets that are not SMS
managed.
...z/OS V1.12 that you can use indirect VSAM cataloging.
I am not sure. I will have to go look this up.
I am using below JCL and this also not able to backup VSAM dataset. I am
getting
same error.
JCL
//DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
// NOTIFY=SYSUID
//STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//INVOL1DD
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
jagadishan perumal
Sent: Tuesday, April 05, 2011 8:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] ADRDSSU issue
Hi,
1) Instead of copying your
being used
will cause copy to fail and the system to issue this message. The data
set identified in the message represents either the source or target
data set that is in use.
JCL :
//DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
// NOTIFY=SYSUID
//STEP1EXEC PGM=ADRDSSU,REGION
*0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG1 IN CATALOG
CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE.
0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG2 IN CATALOG
CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE.
*
*0ADR410E error description is
this message. The data set
identified in the message represents either the source or target data set
that is in use.
JCL :
//DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
// NOTIFY=SYSUID
//STEP1EXEC PGM=ADRDSSU,REGION=2M,PARM=''
//D1 DD UNIT=3390,VOL=SER=DMTCAT,DISP=SHR
//D2
I had non-managed VSAM datasets (zFS to be exact) on z/OS 1.8.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Lizette Koehler
Sent: Wednesday, April 06, 2011 5:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU issue
I see you are at z
I have following question about this ADRDSSU COPY,
1.in original post, there is no 'delete' parameter specified, but even so,
there are still some DataSets had been copied successfully. Do not know why,
may these copied ones are not cataloged? seems not the reason.
2.'PROCESS(SYS1)' is also
),
// NOTIFY=SYSUID
//STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT)
//SYSPRINT DD SYSOUT=*
//RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR
//RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR
//SYSIN DD *
COPY INDD(RES1IN) OUTDD(RES1OUT) -
DS(EXCLUDE(SYS1.VTOCIX.* -
SYS1.VVDS
] On Behalf Of SAURABH KHANDELWAL
Sent: Tuesday, April 05, 2011 7:58 AM
To: IBM-MAIN@bama.ua.edu
Subject: ADRDSSU issue
Hello,
I am trying to copy my SYSRES volume( ex: IPE100)
into one
new volume ( ex IPE101). All the dataset inside IPE100 is managed by
indirect cataloging
Saurabh,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual.
HTH
Richard
From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown,
John [john.mck
Hi,
You can use the below as sample JCL :
*
//CPxxx EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA
//TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA
//SYSIN DD *
COPY LOGINDD(FROM1) OUTDD(TO1) TOL(IOERROR) -
ALLDATA(*) ALLEXCP ADMIN PURGE -
DELETE RECAT
Thanks Richard,
I tried using STORAGE CLASS parameter(
NOSMS). but still got same error. Now I am searching for the parameter
you suggested.
Regards
On 4/5/2011 7:38 PM, Richard Marchant wrote:
Saurabh,
There is a parameter in ADRDSSU where you can bypass
On 4/5/2011 7:54 PM, jagadishan perumal wrote:
Hi,
You can use the below as sample JCL :
*
//CPxxx EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA
//TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA
//SYSIN DD *
COPY LOGINDD(FROM1) OUTDD(TO1) TOL(IOERROR
use the below as sample JCL :
*
//CPxxx EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA
//TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA
//SYSIN DD *
COPY LOGINDD(FROM1) OUTDD(TO1) TOL(IOERROR) -
ALLDATA(*) ALLEXCP ADMIN PURGE -
DELETE RECAT
,
I tried using STORAGE CLASS parameter(
NOSMS). but still got same error. Now I am searching for the parameter you
suggested.
Regards
On 4/5/2011 7:38 PM, Richard Marchant wrote:
Saurabh,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS
in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual.
HTH
Richard
From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of
McKown, John [john.mck...@healthmarkets.com]
Sent: 05 April
, Richard Marchant wrote:
Saurabh,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual.
HTH
Richard
From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of
McKown, John
/5/2011 7:38 PM, Richard Marchant wrote:
Saurabh,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual.
HTH
Richard
From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu
(
NOSMS). but still got same error. Now I am searching for the parameter
you
suggested.
Regards
On 4/5/2011 7:38 PM, Richard Marchant wrote:
Saurabh,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual.
HTH
Richard
oh, sorry, 'PROCESS(SYS1)' is a control stmt that can be specified AS input
to ADRDSSU(DDname SYSIN), NOT a parameter, ;-)
Do not know whether it work or not, cause from your job's output, I got some
SYS1.** get copied successfully, Just have a try.
2011/4/6 chen lucky chenluck...@gmail.com
use this and let me know what you get..
//VFRVOLSER EXEC PGM=ADRDSSU,PARM='LINECNT=',REGION=4M
//SYSPRINT DD SYSOUT=*
//INVOL1DD VOL=SER=FRVOLSER,UNIT=3390,DISP=SHR
//OUTVOL1 DD VOL=SER=TOVOLSER,UNIT=3390,DISP=SHR
aah,forgot remove by condition so job can be ..
//VFRVOLSER EXEC PGM=ADRDSSU,REGION=4M,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//INVOL1DD VOL=SER=FRVOLSER,UNIT=3390,DISP=SHR
//OUTVOL1 DD VOL=SER=TOVOLSER,UNIT=3390
Ok, I will run this in 15 min . and send you output
On 4/6/2011 9:40 AM, Ravi Gaur wrote:
aah,forgot remove by condition so job can be ..
//VFRVOLSER EXEC PGM=ADRDSSU,REGION=4M,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//INVOL1DD VOL=SER=FRVOLSER,UNIT=3390,DISP=SHR
//OUTVOL1 DD VOL
Output of below JCL
*JCL Used*
//DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
// NOTIFY=SYSUID
//STEP2 EXEC PGM=ADRDSSU,REGION=4M,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//INVOL1DD VOL=SER=DMTRES,UNIT=3390,DISP=SHR
//OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR
you
suggested.
Regards
On 4/5/2011 7:38 PM, Richard Marchant wrote:
Saurabh,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual.
HTH
Richard
,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual.
HTH
Richard
From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of
McKown, John [john.mck...@healthmarkets.com]
Sent: 05
using STORAGE CLASS parameter(
NOSMS). but still got same error. Now I am searching for the parameter
you
suggested.
Regards
On 4/5/2011 7:38 PM, Richard Marchant wrote:
Saurabh,
There is a parameter in ADRDSSU where you can bypass the ACS routines,
something like BYPASSACS. Check out the manual
Hi Greg,
In respect of your query:
RUNNING CA'S TOP SECRET 5.0
I'm trying to dump all my disk to tape for a DR test and I believe I need to
use the ADMIN keyword.
Error when using the ADMIN keyword on the Dump command of pgm ADRDSSU.
PAGE 0001 5695-DF175 DFSMSDSS V1R3.0 DATA SET SERVICES
RUNNING CA'S TOP SECRET 5.0
I'm trying to dump all my disk to tape for a DR test and I believe I need to
use the ADMIN keyword.
Error when using the ADMIN keyword on the Dump command of pgm ADRDSSU.
PAGE 0001 5695-DF175 DFSMSDSS V1R3.0 DATA SET SERVICES 2011.066
DUMP FULL INDD(INVOL
To: IBM-MAIN@bama.ua.edu
Subject: ADMIN failure using DUMP command in pgm ADRDSSU
RUNNING CA'S TOP SECRET 5.0
I'm trying to dump all my disk to tape for a DR test and I believe I need to
use the ADMIN keyword.
Error when using the ADMIN keyword on the Dump command of pgm ADRDSSU.
PAGE 0001
The following scenario:
z/OS 1.11
DSS job
COPY DS(INC(**) EXC(SYS1.VVDS.**)) -
LOGINDDNAME(IND) -
CANCELERROR TOLERATE(ENQF) -
OUTDD(OTD) ALLDATA(*) ALLEXCP -
RECATALOG(CAT.MAST.NEWCAT) -
RENAMEU(ZFS.OLDSYS.**,ZFS.NEWSYS.**)
The job succesfully copies all ZFS (VSAM LDS)
I just went through a similar situation. If I remember what I read,
DF/dss actually invokes IDCAMS under the covers to actually perform
the action you are trying. IF you dump the zfs dataset, and restore it
with a newname, it should work properly.
Doug
On 16-Nov-10 09:28, R.S. wrote:
The
W dniu 2010-11-16 22:39, Doug Fuerst pisze:
I just went through a similar situation. If I remember what I read,
DF/dss actually invokes IDCAMS under the covers to actually perform
the action you are trying. IF you dump the zfs dataset, and restore it
with a newname, it should work properly.
Obviously some shops must be radically different. In a full SMS shop,
applications programmers of course have no business doing volume-level
or volume-specific operations, and to prevent override of RACF access
restrictions ADRDSSU ADMIN authority must be tightly restricted to those
Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Joel C Ewing
Sent: Tuesday, May 12, 2009 10:58 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
Obviously some shops must be radically different. In a full SMS shop,
applications
1 - 100 of 246 matches
Mail list logo
