move drmedia w/ remove=untileefull

tsmtodd

ADSM.ORG Member
Joined
May 17, 2005
Messages
79
Reaction score
2
Points
0
Website
http
Before I get to the real problem, some history, to ensure I am doing the right stuff ahead of time. I may be doing something wrong in my set up that is causing the problem later. This is my first DRM setup, so I am learning by example and failure, here.



I am running TSM 5.3.2.0 on AIX with a 3584 library that has 16 Entry/Exit slots.



I have set all the variables I care about that show in "q drmstat". Copy storage pools and DB Backups show up as DR volumes with "q drm".



Daily, I have a cron submitted script I created that runs TSM scripts (similar to the wizard created "Maintenance_Plan") and AIX commands. The order of events is...

1. run a mini-maint-plan that backs up primary to copy pools, and then does DB Backup.

2. wait until all tapes are dismounted

3. run move drm commands to move vols

---- wherestate=mountable tostate=notmountable

---- wherestate=vaultretrieve tostate=courierretrieve

4. create the text for an email that lists tapes to take offsite, and tapes to bring back

5. backup volhist, devconfig

6. perform mksysb (mkcd)

7. email the list



Now we get to the problem. I need to eject all of the tapes from the library to take offsite. There are 16 I/O slots (entry/exit slots) on the library. "q drm" indicates there are 24 volumes at "notmountable" state. My understanding of the move drmedia command is the the "remove=untileefull" option will process enough volumes to fill the EE-I/O slots and then stop, leaving the remaining volumes at the current state (notmountable).

I used the command

move drmedia * wherestate=notmountable remove=untileefull tostate=vault

All 24 tapes are now at state "vault"

Only 8 of the tapes were placed into the EE-I/O slots, leaving 16 tapes in normal slots in the library.



There were no error messages in the activity log to indicate any problems.

Where am I going wrong here?
 
Your DRM plan needs to show the wherestate=MOUNTABLE => where you have NOTMOUNTABLE. The next thing the untileefull means that all media will be sent to the CAP and continue to do so until all the media has been ejected. This is your problem I do believe.



Your script should then process when you change the wherestate to courier with remove=no then change to vault with a wait=yes. Continue on until you have reached the courierretrieve state. Once completed, you change to vaultretrieve then to courierretrieve. As your script runs...you can always redirect the output of each drm step to a temporaru working file(s) and then email the results of each.



So your eject line should read q drm * wherestate=mountable remove=untileefull

to state=courier wait=yes



One way to validate is to execute q drm * and look at the different states - I do believe you will not see a "notmountable" state. It will either be mountable, vault, courier, courierretrieve or vaultretrieve.



Good luck.
 
From the "help move drmedia" command...

possible values for wherestate:

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Code:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><PRE> '-WHERESTate--=--+-MOuntable-------+-'

+-NOTMOuntable----+

+-COUrier---------+

+-VAULTRetrieve---+

'-COURIERRetrieve-'</PRE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



Possible values for tostate:

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Code:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><PRE>'-TOSTate--=--+-NOTMOuntable----+-'

+-COUrier---------+

+-VAult-----------+

+-COURIERRetrieve-+

'-ONSITERetrieve--'</PRE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



So, notmountable is a valid state. From what I understand, if you leave the tostate value undefined, the move drm command moves to the next state... and from what I understand, the order of states is as follows:

mountable

notmountable

courier

vault

vaultretrieve

courierretrieve

onsiteretrieve



I need to move the tapes to "notmountable" first, to make sure they don't get mounted between the time of the stg pool copy/DB backup, and when they get ejected from the library.

I re-read the help info on move drmedia. According to that, the "untileefull" option will behave if the libary:

--Has e/e ports and an e/e port is available-- the server moves the cartridge to the available e/e port and specifies the port address in a message. The server does not prompt you to remove the cartridge and does not request a REPLY command.

--Has e/e ports but no ports are available -- the command fails and any remaining eligible volumes are not processed. Make the port available and issue the command again.



... so, my commands should be working as I originally stated. Or.. is a 3584 LTO Library not considered a "SCSI Library"?



I will try the wait=yes option, to see if that helps things.



I may try the "bulk" option, because it just waits until the ports are available.



I shouldn't need to move things to "courier". We do our own offsite rotation. However, I probably will implement the user of "courier" and additional procedures for our operations staff to move courier->vault. That really would be safest. Right now, I am just trying to get things working.
 
The environment I left, If I remember right= do believe the 3584's were ACSLS / LM Managed libraries. And I do believe they were listed as "External" as well rather than SCSI since there was a Library Manager in the loop.



You are correct on the states - but if you have already backed up your storage pool and DB ahead of time. And if prepare was also run, why bother with the Notmountable state within your script? The DR work has been done, proceed with the DRM process.

By the way - Is this routine all consequtive or in separate schedules.



Good luck
 
I was told ACSLS libraries are StorageTek only, and managed by special software for that type of library. I will ask my IBM guy, and find out if that is true. I am almost certain that he said 3584 libraries are NOT ACSLS. The TSM server is the "library manager" in this case. If it is external, then the move drm command behaves very differently from the checkout libv command.



I am not running "prepare", yet. I intend to incorporate that later. Does that make a difference to what is happening here?



This routine is done in several steps. The cron submitted script mentioned in the original post is one step (with many steps in it, of course). Other steps would be operations executing the move drm from notmountable to vault, to eject the tapes, and then later, after tapes have been delivered offsite, and empty tapes retrieved, they would move drm from courierretrieve to onsiteretrieve, and then checkin the volumes.
 
Right again - goes to show you what happens to you when you work in a mixed environment :) and type very quickly - sorry for the crossed information :sad:



Good luck, I dont think it will hurt to create a new library, a couple of drives, create the paths and give it a run - Do you?
 
<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>...I dont think it will hurt to create a new library, a couple of drives, create the paths and give it a run - Do you?



</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



um.. Huh? what did I miss? Give what a run?
 
I think I figured out what was wrong. I was running with the understanding that a ...

move drm * wherestate=mountable remove=no tostate=notmountable

would not perform a checkout libvol function (becuase of the remove=no).



The checkout function DOES occur, but because the remove=no is there, the library doesn't move the volumes.



So, I am redesigning my flow with all that in mind.

move drm * wherestate=mountable remove=bulk tostate=courier



That should get them out of the library. My understanding is that remove=bulk will fill the EE slots and then wait until slots are available, and then continue to eject tapes when slots become available.

I just hope it doesn't have a time out function... Operations doesn't always get on this right away :rolleyes:
 
what is the reason you would want to mark tapes in the copy stg pool offsite as "not,mountable" rather then "vault"?



you are right that remove=bulk is better then untileeful



with STK ACSLS libraries (or Gresham EDT) you would use the acsls eject command with the tsm remove=no parm to move drm



TSM simply queries the ACSLS server to get its audit information



The only libraries that use ACSLS are from STK and are the SL8500 SL500 L700E Dual Framed 9310 and 9740 that's it



regards
 
Back
Top