I KNEW someone's going to say that and I do use address COMMAND, but - obviously not in this exec. I was going to insert it now to prevent the backlash, but since I don't have a system anymore to test the exec, I decided against it. Ivica Brodaric
On 08/02/2008, Kris Buelens <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > >
