If EMC has done this then they are in my opinion unfit to "design" 
software - I know that in the past people have asked for an optional hard 
limit on sessions per drive, so they have more control, this 'feature' 
makes it impossible to control networker in ways that we rely on. 
ie. setting target sessions to one for a large server then when it is 
happily sending a partition to each of several tape drives setting the 
sessions for the other drives up to 4 so slow backups will interleave and 
keep the drive humming - it's not perfect but it reduces the backup time 
for one server from ~12 hours to 4 hours!
I would have to avoid any version on Networker as brain dead as this!

On Mon, 27 Nov 2006 12:49:14 -0500, Landwehr, Jerome <jlandweh AT HARRIS DOT 
COM> 
wrote:

>This is something I too have seen at version 7.3.2
>
>After months of having a case open, this is the (infuriating) response I 
finally got:
>
>
>Here is the details of the target sessions behavior and how it is 
expected to work in NetWorker 7.3.x. Hope this explains the changes in 
target sessions behavior comparing to the previous version of NetWorker 
and related concern from Jerry.
>
>Background:    Prior to the changes made to target sessions behavior, we 
had many complains from different customers about one or few devices are 
being hammered when other devices sitting idle doing nothing 
(eligible/enabled devices). This was only an issue when we had different 
target sessions settings for each device, and say the first device had it 
set to 10 and others set to 1 or 2. in this scenario by getting 8 save 
sessions coming to the networker storage node the first device (selected 
as per device selection criteria) was hosting them all 8 sessions and 
remaining devices sitting idle.
>
>Due to couple of enhancement request to address above issue for better 
utilization of the eligible devices, a fix has been implemented to query 
the respective storage node and it's eligible devices, then select the ?
lowest? target session setting amongst the devices and use this number as 
the target session value for all devices for the backup in order for 
better distribution and load balancing on incoming save sessions.
>
>Suggestions    While attempting to utilize more devices (if possible) is 
a good thing, I would ask Jerry however to make the target sessions value 
more close to minimize the request for additional volumes and slightly 
improve the performance. Values from 1 to 10 as per above explanation 
could have negative impact on resource utilization and as per above 
explanation and in this configuration value 10 not taking effect 
eventually because of the lowest number. So either setting the target 
session value in a range like 4-6 is recommended (if it is really required 
to be different) or making some changes to the configuration (group, 
client?.etc) to achieve better resource allocation also performance.
>
>As we have mentioned the Escalation LGTpa89210 is open on device request 
issue and the fix is not verified yet. This escalation is however is a 
side effect of other settings especially target sessions and with making 
suggested changes this will not be a problem.
>
>
>
>So rather than telling customers to fix the target sessions to their 
liking, they 'fixed' the software to find and use the lowest target 
sessions available on any device for the storage node and ignore the user 
setting!
>
>this broke my environment since I have two jukeboxes connected to the 
storage nodes: a VTL jukebox with target sessions set to 1 for all 
devices, while the LTOII jukebox has significantly more target sessions on 
each of it's devices
>
>the result is that whenever a LTOII savegroup kicks off, I get a hundred 
messages emailed about all the storage nodes wanting more tapes than they 
need...  nice!
>
>Jerry

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER