Multiple members work, assuming you want to
deal with the "alias" issue for any sql, but
I agree it's kind of an oil and water mix.
I am a long-time (system 38) person, but I would
not use multiple members for the app you describe,
rather I think I would prefer "temp" work files,
because I don't see a need to store data after the
Also, I don't think I would use multiple libraries,
maybe use the temp lib of the job or maybe a permanent
lib for the app.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Naughton
Sent: Wednesday, November 21, 2012 12:43 PM
To: Midrange Systems Technical Discussion
Subject: 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?
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA 01376
Internal: x 444
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.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l