Design Question - Multi Member Files

I'm curious what people's thoughts are on the following situation. I've got a web application that makes multiple requests to our iSeries through a non-i web server, receiving back information each time until there is nothing more to send. The only
persistent piece is the browser; the web server application fires up with each request, contacts the iSeries, gets a reply, and sends it back to the browser. (It's the potential size of some of the possible replies that is driving this -- the server app
has some limits that might be exceeded if everything came back all at once.)

The iSeries application builds a work file on the first pass and then reads through it, sending the information back to the web. The design issue is how to maintain persistence on the data in the work file in a situation where multiple people may be
doing this at once. My solution right now is to make the work file multi member, so each user uses a member named for their user profile and the program does an OVRDBF to that member on the way in.

It seems like a nice, neat way to use a handy feature of DB2 on the iSeries, but I'm wondering -- it's kind of an oddball feature to the rest of the world, and SQL doesn't play with multiple members very well (I don't think?), so is this a dangerous long
term solution? I know there are other options -- I could give the users their own libraries and make a copy of the work file in each library, or I could add the user profile as a key to the work file, etc. -- but they all seem more involved than what I'm
doing now. Should I just figure "if it ain't broke, don't fix it", or is that likely to be short-sighted?

Thoughts, anyone?

Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA 01376
413-676-3144
Internal: x 444
mnaughton@xxxxxxxxxxxx
****************************************
NOTICE: This e-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that any use is
strictly prohibited. If you have received this e-mail in error, please notify us immediately by replying to it and then delete it from your computer.