Nicely formatted REXX, quoted what need to be, CP commands targeted
directly to CP. But..... Where is the ADDRESS COMMAND? And why use
PIPE CMS instead of PIPE COMMAND? Running with ADDRESS CMS and PIPE
CMS are two loaded guns too.
Why: read our free Telecourse
http://www.vm.ibm.com/download/packages/descript.cgi?TCVM1
--
Kris Buelens,
IBM Belgium, VM customer support
2008/2/7, Ivica Brodaric <[EMAIL PROTECTED]>:
> Chris,
>
>
> Since you are a VM newbie (welcome!) I thought I might give you a simple
> DDRCOPY EXEC so that you are all set. I found one in my archive. Exec doesn't
> use minidisk passwords in LINK commands, so put OPTION LNKNOPAS in SYSDMPPR
> profile or work around it (depends on your security requirements). This exec
> uses another disk for backup. If you want to use a tape as output, you need
> to replace the second LINK command with ATTACH command for the tape drive,
> modify OUTPUT subcommand of DDR and replace 'COPY ALL' with 'DUMP ALL'.
>
>
> One warning: This is a loaded gun. Please be careful with those "target_addr"
> parameters in DMPnnnnn EXECs previously mentioned. Maybe tell your co-worker
> to read them aloud for you in a melodic voice after you did the same. ;-)
>
>
>
> /**
> *** Function: Copy a minidisk with DDR
> **/
> arg userin addrin userout addrout disktype rest
> if rest ^= ''
> then do
> say 'Invalid parameter:' rest'.'
> exit 3
> end
> if disktype = ''
> then disktype = '3390'
> if addrout = ''
> then do
> say 'Missing parameters.'
> say 'Format: DDRCOPY userin addrin userout addrout <disktype>'
> say ' < 3390 >'
> exit 4
> end
> 'CLRSCRN'
> 'MAKEBUF'
> 'GETFMADR'
> if rc ^= 0 then exit rc
> pull . fm1 addr1
> 'DROPBUF'
> parse value diagrc(8, 'LINK' userin addrin addr1 'RR') with rc .
> if rc ^= 0 then exit rc
> 'ACCESS' addr1 fm1
> 'MAKEBUF'
> 'GETFMADR'
> pull . fm2 addr2
> 'DROPBUF'
> parse value diagrc(8, 'LINK' userout addrout addr2 'M') with rc .
> if rc ^= 0 then exit rc
> 'MAKEBUF'
> queue 'SYSPRINT CONS'
> queue 'INPUT' addr1 disktype
> queue 'OUTPUT' addr2 disktype
> queue 'COPY ALL'
> queue 'YES'
> queue 'YES'
> queue
> call time 'R'
> 'DDR'
> src = rc
> 'DROPBUF'
> 'ACCESS' addr1 fm1
> 'ACCESS' addr2 fm2
> 'PIPE CMS Q DISK' fm1'|CONS'
> 'PIPE CMS Q DISK' fm2'|TAKE LAST|CONS'
> 'RELEASE' fm1
> 'RELEASE' fm2
> call diag 8, 'DETACH' addr1
> call diag 8, 'DETACH' addr2
> say 'Elapsed time:' time('E')
> 'CP SLEEP 1 SEC'
> exit src
>
>
> Ivica Brodaric
> Not with Tabcorp anymore
> (not because of this exec - mainframe is not with Tabcorp anymore either)
>
>
>
> On 08/02/2008, Ivica Brodaric <[EMAIL PROTECTED]> wrote:
> > If you create a PROFILE EXEC on 191 that checks who's running and invokes
> > another exec if it's a dumper machine, e.g.:
> >
> >
> > if userid() /= 'DMPADMIN' then do
> > 'CP SP CON DMPADMIN'
> > 'EXEC' userid()
> > 'CP LOGOFF'
> > end
> >
> >
> > and create "<userid> EXEC" for every dumper machine that you are actually
> > going to use and that contains something simple (you are going to maintain
> > this), e.g.:
> >
> >
> > ' EXEC DDRCOPY $VOLS$ <source_addr> $VOLS$ <target_addr>'
> >
> >
> > then you only need to write a DDRCOPY EXEC that will link source and target
> > minidisks and invoke DDR program.
> >
> >
> > From here you only need to maintain <userid> EXEC's from dump maintenance
> > machine and autolog dumper machines to do the work.
> >
> >
> >
> >
> > On 08/02/2008, Ivica Brodaric <[EMAIL PROTECTED]> wrote:
> > > And if you move 191 minidisk from dumper machines to maintenance
> > > userid, and add a link to that minidisk as 191 RR to SYSDMPPR profile,
> > > you can define a pool of dumper machines, e.g.:
> > >
> > >
> > > USER DMP password 5M 25M G
> > > POOL LOW 0 HIGH 99 PROFILE SYSDMPPR
> > >
> > >
> > >
> > > On 08/02/2008, RPN01 <[EMAIL PROTECTED]> wrote:
> > > > If you can get them to use a common profile, and possibly run a
> > > > script or
> > > > control file that matches the userid, then there'd really be no need
> > > > for the
> > > > writable 191 in each dumper virtual machine. You could place the 191
> > > > under
> > > > either $VOLS$ or some other "maintenance" user, and have the
> > > > profile just
> > > > link it rr as well.
> > > >
> > > > We do this with all our Linux guests; they share a single 191 minidisk,
> > > > and
> > > > the profile accounts for any differences that may be required.
> > > >
> > > > --
> > > > .~. Robert P. Nix Mayo Foundation
> > > > /V\ RO-OE-5-55 200 First Street SW
> > > > /( )\ 507-284-0844 Rochester, MN 55905
> > > > ^^-^^ -----
> > > > "In theory, theory and practice are the same, but
> > > > in practice, theory and practice are different."
> > > >
> > > >
> > > >
> > > >
> > > > On 2/6/08 3:25 PM, "Aria Bamdad" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > On Wed, 6 Feb 2008 12:44:02 -0500 Hilliard, Chris said:
> > > > >>
> > > > >> I need a short lesson on backing up DASD volumes using DDR.
> > > > >>
> > > > > snip
> > > > >
> > > > > Chris,
> > > > >
> > > > > Others have made good suggestions. Over time, you may have more DASD
> > > > > that you want to dump or use multiple virtual machines that you want
> > > > > to
> > > > > use simultaniously to dump from. Here is one way to address
> > > > that:
> > > > >
> > > > > Define one dummy user that owns a full pack minidisk on each volume:
> > > > >
> > > > > USER $VOLS$ NOLOG
> > > > > ACCOUNT SYSTEM SYSTEM
> > > > > MDISK A00 3390 0000 3339 VOLA00 RR
> > > > > MDISK A01 3390 0000 3339 VOLA01 RR
> > > > > MDISK A02 3390 0000 3339 VOLA02 RR
> > > > > MDISK A03 3390 0000 3339 VOLA03 RR
> > > > > MDISK A04 3390 0000 3339 VOLA04 RR
> > > > >
> > > > >
> > > > > Now define multiple dump users that do the dumping to tape. These
> > > > > users
> > > > > will have access to the dummy account disks above. To make it
> > > > > simpler,
> > > > > just define a user profile first then use that in each dump account:
> > > > >
> > > > >
> > > > > PROFILE SYSDMPPR
> > > > > * Profile for SYSDUMP users
> > > > > ACCOUNT SYSUTIL SYSTEM
> > > > > MACHINE XC
> > > > > IPL CMS PARM AUTOCR
> > > > > CONSOLE 009 3215
> > > > > SPOOL 00C 2540 READER *
> > > > > SPOOL 00D 2540 PUNCH A
> > > > > SPOOL 00E 1403 A
> > > > > LINK MAINT 190 190 RR
> > > > > LINK MAINT 19E 19E RR
> > > > > LINK $VOLS$ A00 A00 RR
> > > > > LINK $VOLS$ A01 A01 RR
> > > > > LINK $VOLS$ A02 A02 RR
> > > > > LINK $VOLS$ A03 A03 RR
> > > > > LINK $VOLS$ A04 A04 RR
> > > > >
> > > > > Now each new dump account can be define using:
> > > > >
> > > > > USER SYSDUMP PASSWORD 5M 25M G
> > > > > INCLUDE SYSDMPPR
> > > > > MDISK 191 3390 xxxx yyyy zzzzzz W
> > > > > *
> > > > > USER SYSDUMP2 PASSWORD 5M 25M G
> > > > > INCLUDE SYSDMPPR
> > > > > MDISK 191 3390 xxxx yyyy zzzzzz W
> > > > >
> > > > >
> > > > > Now each dump account has a virtual address that matches the real
> > > > > address of a real DASD. You can then do a DDR with input statements
> > > > > that point to the virtual address.
> > > > >
> > > > > Remember to never make this LINK or MDISK statements in write mode.
> > > > > Everything
> > > > > should be in read only mode.
> > > > >
> > > > > Aria
> > > >
> > >
> > >
> >
> >
>
>
