If they're too long, they could interfere with DSMSERV RESTORE.
I ran into a problem with my coalescing 6.3 infrastructure that I wanted
to share; if you're prepared for it you can deal with it
straightforwardly, but it could be terrifying otherwise.
The problem evinces thus: You're doing a DSMSERV restore, and:
ANR2144E DEFINE SERVER: Invalid password - .
ANR0902W Unsupported keyword found in file /tsm/home/tsmtest/devconfig.
ANR0906I Line No. : 0
ANR0907I Statement : DEFINE SERVER TSMCTRL COMMMETHOD=TCPIP
HLADDRESS=128.227.-
129.119 LLADDRESS=1826 NODENAME=TSMTEST PASSWORD=[thus]
SERVERPASSWORD=[other thus]
ANR3239E Error 2800 while creating device class DBBACK_R.
[...]
ANR2032E RESTORE DB: Command failed - internal server error detected.
ANR9999D Thread<1> issued message 2032 from:
ANR9999D Thread<1> 0x00000000d65516 outMsgf
ANR9999D Thread<1> 0x000000004f715a AdmRestoreDb
ANR9999D Thread<1> 0x00000000492a66 admRestoreDatabase
ANR9999D Thread<1> 0x0000000048116b main
ANR9999D Thread<1> 0x00003286e1ecdd *UNKNOWN*
ANR9999D Thread<1> 0x0000000047f579 *UNKNOWN*
The problem was that my SERVERPASSWORD was greater than 16 characters.
This is evidently "invalid", for very particular meanings of invalid.
It is not in the docs for SET SERVERPASSWORD; it is not rejected when
you run SET SERVERPASSWORD. After having set it, and used it for a
DEFINE SERVER somewhere else, you can set up communications, and things
run smoothly for e.g. command redirection. (and virtual volumes, but
that's a different password anyway) But when you try to read the
devconfig file, things will break.
So the time you'll encounter this is when everything has been going fine
for a while, and then you have a failure and need to restore.
*shudder*. I'm really glad I exercised it when I was doing initial
testing, with an instance holding only transient, beta data. It was a
compelling problem, but not an actual present disaster.
Here's how I worked around it, and got my beta server back: I built a
brand new, empty server using the same name. Basically I took the
instance ('TSMTEST') and built it new. I introduced this new baby
server to the server holding the DB backups, under the same server host
name. I did a DB backup and restore of the new, empty TSMTEST to prove
I could. Of course, as far as it was concerned, there was only one DB
backup in the universe, the one It did just then.
Then I copied the old VOLHIST but left the new DEVCONFIG in place. The
new DEVCONFIG didn't have all my old instance's devices, but it had
enough to pull down the database backup. The older VOLHIST had records
of the older backups, and could pull down the desired state, with client
data references &c. Then I could do a new backup devconfig, and
soldier on.
IBM is musing about how to classify this. I say that the minimum change
necessary is 1) documentation of the constraint on password length, and
2) rejection with diagnostic of out-of-spec passwords.
- Allen S. Rout
|
