Re: Design Question - Multi Member Files

You didn't say how big the work table was? Depending on how big,
alternatives might be using the IFS, then you could have a long name. The
other alternative is to use a user space (Assuming you are not looking at
data over 16mb). A lot quicker and easier to use. Just create a unique name
and pass that name back to maintain state between calls.


On Wed, Nov 21, 2012 at 12:42 PM, Michael Naughton <
michael_naughton@xxxxxxxxxxxx> wrote:

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.

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.