BRMS: Change in MOVMEDBRM report

I was having an issue with my MOVMEDBRM report. This should only affect
BRMS clients with networked systems that may have some strange WRKRDBDIRE
entries set up on their systems to facilitate HA switches like Mimix.

Our original lpar was GDIHQ. We added a Mimix lpar called GDIHQ2

GDIHQ2 has two WRKRDBDIRE entries germane to this discussion:

Relational database . . . . . . : GDIHQ
Remote location:
Remote location . . . . . . . : *LOCAL
Type . . . . . . . . . . . . : *IP

Relational database . . . . . . : GDIHQ
Relational database alias . . : GDIHQ2
Remote location:
Remote location . . . . . . . : GDIHQ2
Type . . . . . . . . . . . . : *IP

This allows ODBC clients to do a CONNECT TO GDIHQ and have it think it's
talking to GDIHQ regardless of whether or not it is on GDIHQ or GDIHQ2.
Very critical.

GDIHQ1 is setup the same way. Replacing the 2 with a 1.

Where we screwed up was not renaming GDIHQ to GDIHQ1 in BRMS. Until
recently, it was not a problem. However IBM came out with some new PTF's
to enhance BRMS functionality and blew this up. RTF:

<from IBM>
Dec 2014:

48. In 6.1 and later, the Move Media using BRM (MOVMEDBRM) and
Verify Moves using BRM (VFYMOVBRM) commands have been enhanced
to run the Remove Tape Cartridge (RMVTAPCTG) command for volumes
that are in media libraries when the media libraries are not
configured on the local system.

[ To disable the new function CRTDTAARA DTAARA(QUSRBRM/Q1ANORMDE)
TYPE(*CHAR) ]
</from IBM>

I was getting errors that it couldn't connect. And once GDIHQ2 couldn't
connect to GDIHQ (yo dude, I'm freaking already on GDIHQ) it just wouldn't
connect to ANY of our other networked systems.
I created the data area and I'm back to working.

I suppose the long term solution is to rename GDIHQ to GDIHQ1 in BRMS. I'm
in discussions with IBM about this.

Rob Berendt