Here's my take on this Jerry. If this is a one off, then just use
WRKMEDBRM and take the option 8 to move it. If, however, this is a
regular thing then I think you're trying to fight the system. If you have
the appropriate move policy setup with the appropriate locations and are
using the appropriate control group that uses that move policy then the
MOVMEDBRM will know exactly which particular volume from that location to
move. And you don't have to do crap like analyzing the joblog to
determine which volume was used and plug that volume id into some custom
movmedbrm system.

WRKMEDBRM. Tapes that are expired and are either sitting on the shelf at
KVLCMPROOM or are one of the hundred or so waiting their turn in TAPKVL01
automatically have a move policy of *NONE assigned to them. Soon as one
particular volume is consumed via STRBKUBRM it automatically changes it's
move policy from *NONE to IRONMTN.

This is not like the bad old days before BRMS where we had to track each
volume. It will do it for us. You just have to start thinking BRMS and
forget all that crap you used to do.

STRMNTBRM is the command which will expire the media
From the job schedule entry BRMMAINT:
Command . . . . . . . . . . . : STRMNTBRM RMVMEDI(*REUSE)
PRTEXPMED(*NO) PRTVSNRPT(*NO) PRTBKUACT(*NO) PRTRCYRPT(*RCYANL *SAVEXCP)

Job schedule entry BRMRECOVER is a CL wrapper for STRRCYBRM
OPTION(*SYSTEM) ACTION(*REPORT) which takes the reports, convert them to
PDF files and saves them on three different servers spread out over two
countries.

Rob Berendt

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].