× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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
transfer completes.

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.

-----Original Message-----
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?

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.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.