We did a major migration from iSeries to Windows/SQL last November, and we have utilized virtual batch queues. They have actually been quite handy for load balancing and server maintenance. The main consideration for us was the fact that by adopting that path we were essentially de-centralizing our batch servers, so any process that we had in place that required manipulation of a flat file on a specific server (such as table conversions) needed to have logic within the process to make sure the file exists on all possible batch servers (you could theoretically force it to run on a specific batch server, but to us that sort of defeated the purpose of utilizing virtual batch queues). Also due to the decentralization we had to move our UBE storage to the database from the filesystem, which hasn't caused any real issues since we have been transitioning from Optio to BIP for all of our forms.
Right now we have a total of 2 possible batch servers, one primary and one DR. We normally leave the DR batch server in an inactive state through P9655 and only activate it when switching over to DR. It has been a godsend in situations where we need to do a quick reboot of our production batch server during work hours or other types of maintenance, since users don't really see much of a difference with their submitted jobs.
Setting it up is a bit of a timesink, mainly due to the fact you have to set the oneworld queues up for not only the "virtual batch" server, but also the physical enterprise servers as well (so if you have 2 enterprise servers being driven by 1 VBQ, you would set up 3 sets of queues in P986130). The documentation on Oracle's site was pretty easy to follow and I don't recall having any real issues getting it going. I haven't used it to segregate any batch jobs between servers, since at our organization we just let them run where they run, but you could theoretically do it by making it so a batch queue is only set up on one of the enterprise servers and not the other, which would cause that to be the only option when submitting to the VBQ (we learned that the hard way by having a queue name with a space at the end, and beat ourselves up for a minute trying to figure out why jobs submitted to that queue would never start processing).
Personally, I would recommend that if you are on/going to Windows or *nix, it would be in your best interest to set it up even if you don't plan on using it or only have a single enterprise server just for the mere fact it's not at all difficult to hook additional servers into it later on down the road should the need arise for your organization. Of course, that's just my opinion, so take it with a grain of salt
-Terry B
