On Tuesday 11 April 2006 20:41, David Boyes wrote:
> > Sorry, but I don't understand what a "MOVE VOLUME" -- or rather what
>
> an
>
> > operator area is. I do understand the concept of an area that is
> > accessible
> > from the outside without opening the library case.
>
> Sorry -- terminology thing again. In the very large libraries (the big
> STK and IBM silos), the "operator area" is the port where you can
> load/unload volumes w/o opening the case. It's usually addressed as a
> range of special slot numbers (in my STK silos, it's slot 9900-9910, in
> the IBM ones it's slots 10000 through 10010)
>
> > By the way, I don't see any problem for InChanger to have multiple
>
> values.
>
> Kind of a misleading name, though. It's really a volume state indication
> -- eg, the volume is mountable or not.
In its current usage, I find it to be the best name. It indicates if the
volume is in the changer or not.
>
> Rough idea I was discussing with Arno on the volume management thing:
>
> There's three things we need to know for a classic full volume
> management lifecycle implementation:
>
> 1) the state of a volume (where it is in the volume management cycle)
>
> 2) the location of a volume (set of predefined locations)
>
> 3) a comment to indicate information that may not be determinable from
> the media itself (the case of a DR vendor needing a external ID # that
> is different from the volser of the media is an example where you would
> need that kind of ability to tag a comment onto a volume record)
>
> If we use the cycle that TSM uses (a pretty classic implementation), we
> get about 7 standard states, only one of which makes sense using
> InChanger as a variable name (MOUNTABLE, the implication of the current
> InChanger=1).
>
> You've already added the location field as an index to a location table.
> This is Good.
>
> A comment field in the volume record would be a simple text string
> (60-80 bytes).
This shouldn't pose any problems.
>
> We redefine InChanger to be VolumeState (or add a VolumeState variable
> and transiton to it over time).
I'm not sure I want to change InChanger. Every change to the database is
extremely painful for me, particularly because of SQLite which does not have
ALTER TABLE -- it requires hours of work involving minutia.
What would the new values for InChanger (or VolumeState) be?
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
