Conference cookie::mru

	For what it is worth, I found an example of a medium changer
	that doesn't use a consistent element status size; the loader
	of the 16 slot optical (RW5something).  The slots, port and
	transport only use about 4 bytes, while the drive uses 12.
	I changed the MRD once again to deal with it.  I really wish
	I could have used Read Element Status to get the answer
	correctly and quickly...

    Can you do the following read_element_status command: 
    
    %xb8,0,0,0,%x3f,%xff,0,0,0,%x8,0,0
    
    look at the 8 bytes returned, get the "Byte count of report available"
    data from bytes 5,6,7 and resend the read_element_status command with
    bytes 7,8,9 set to the "Byte count of report available".
    
    This will give you all the element status information for the jukebox.
    At that point you can use the data header information for each page
    type to determine how many bytes belong that page.
    
    The older LaserStar parts of OSMS just specifies the an "allocation
    length" to handle the largest jukebox that it supports, this was
    8192 bytes for a 1000 slot jukebox. OSMS doesn't have any chaining
    of multiple jukeboxes.
    
    Do the multiple tape libraries cause a problem in getting the
    read_element_status data?
    
    LaserStar had a similar problem about 4 years ago until we decided to
    invest in coding the "map" routines to handle the variations that our
    multiple vendors were throwing at us.
    
    Rob

	Using the 8 byte command is at the heart of the problem.  Most
	robots handle this gracefully and quickly.  We have encounted
	at least one insane robot that doesn't handle it gracefully,
	and so poorly that the answer is undetectably unusable.  In
	the case of the TL820 MUSL code, it handles the command 
	correctly, but not quickly.  If you ask for a small number
	of elements it is fast.  If you ask for a large number of
	elements it is slow.  When a 5 tower MUSL configuration can
	have 1,320 slots, waiting nearly a minute just to find out
	how much data is needed is too long.

	We believe that the problem is in the robot, but we are apparently
	in the minority.  Lots of work-arounds have been offered,
	but we'd prefer a robot that worked to spec, quickly.  We have
	our own work-arounds that simply involve allocating too much
	temporary memory.

    As with some other problems this sounds like an implementation
    problem in the hardware.  How much flexibility do you have
    controlling your own destiny?  Can you exclude various hardware
    from product support?   Can you get the hardware changed so it
    doesn't cause this problem.  Maybe the next dot releses will have
    to support some problem cases but a "solution" should include
    corrections (or non-inclusion) in the hardware longer term.
    
    Rob

	The particular configuration is the multi-tower TL820 family.
	Given that we have a good enough work-around and that the
	over-allocation of memory is around 44 KB in the worst case,
	there doesn't seem to be much point.