× 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.



Unfortunately, I don't think a user space can be brought in using SETOBJACC. 
You could use the Set Access State (SETACST) MI function for this, however, 
which works with any kind of object. Check out this link

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/info/rzatk/SETACST.htm

or

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/info/rzajp/sc092418.pdf

for an example in C.

For concurrent write control you can use the MI functions LOCKSL/UNLOCKSL, 
which deal with space locations. They're both in the PDF cited above, and you 
can substitute their names where SETACST appears in the first link.

Too much fun, eh?
Vern

-------------- Original message -------------- 

> Good points Vern. 
> 
> While accessing a file placed into memory using SETOBJACC wouldn't be as fast 
> as 
> accessing a preloaded array, because of the overhead required for the RDBMS 
> code. The data is shared, including any updates and you don't have to worry 
> about dealing with concurrent writes. 
> 
> Another option, if you want the absolute fastest, shared access would be (I 
> think) a user space placed into memory via SETOBJACC. Question is how to deal 
> with concurrent writes? 
> 
> Charles Wilt 
> iSeries Systems Administrator / Developer 
> Mitsubishi Electric Automotive America 
> ph: 513-573-4343 
> fax: 513-398-1121 
> 
> 
> > -----Original Message----- 
> > From: midrange-l-bounces@xxxxxxxxxxxx 
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Vernon Hamberg 
> > Sent: Friday, May 06, 2005 8:20 AM 
> > To: Midrange Systems Technical Discussion 
> > Subject: RE: Normalization was Left AS/400 and Returned 
> > 
> > 
> > This will vary widely, based on load and how many accesses 
> > you have. I 
> > recently spoke with one of our customers that reported orders 
> > of magnitude 
> > improvement. The key to this is, anything in memory in 
> > whatever pool is 
> > available to all jobs on the system, no matter the pool they 
> > are running 
> > in. Memory access is much faster than disk access. If you 
> > could put all 
> > your data, and possibly programs, in memory, you'd really fly. 
> > 
> > One thing to be sure to do is to make SETOBJACC preload the 
> > file or files 
> > into a *FIXED pool, not *CALC. Also, no jobs should be allowed to run 
> > there, as that could force purging to disk. 
> > 
> > I think this is basically the same as preloading an array, 
> > just on a larger 
> > scale. BTW, inserts to a file end up in the pool, too. 
> > 
> > Results will also vary, because once one user has brought a 
> > record into 
> > memory, it is available to every job. So the benefit of 
> > SETOBJACC might not 
> > be as great in a very busy system with lots of access to the 
> > same data from 
> > separate jobs. Of course, data can be paged out, whereas the 
> > SETOBJACC 
> > stuff will not be. 
> > 
> > HTH 
> > Vern 
> > 
> > At 02:43 AM 5/6/2005, you wrote: 
> > 
> > >Hi Joe 
> > > 
> > >I understand that the SETOBJACC command allows a file to be "pinned" 
> > >(cached might be a better term) in memory to avoid multiple 
> > disk accesses. 
> > >Have you ever experimented with what performance benefits might be 
> > >obtained using this method instead of the slightly less 
> > direct method of 
> > >transforming the file into an array ? 
> > > 
> > >Anyone else got any benchmarks or experiences ? 
> > > 
> > >I'm just curious , not trying to prove a point or anything ;) 
> > > 
> > >Regards 
> > >Evan Harris 
> > > 
> > >>And I understand your preference. Checking every date by 
> > doing a CHAIN 
> > >>or SETLL on a file is easy. I think part of my bias is 
> > that I come from 
> > >>a scheduling background, which means I need information for periods, 
> > >>rather than single days. I might have to schedule an 
> > operation to run 
> > >>over 10 days, and thus I'll have to know all the working days. By 
> > >>reading a one-year array once, I'm covered and I can 
> > schedule all the 
> > >>work for that item. 
> > >> 
> > >>With a one-record per date approach, I'll be doing lots of 
> > I/O, over and 
> > >>over again (unless I read the data from the file into an 
> > array, at which 
> > >>point your argument about how hard it is becomes moot). 
> > >> 
> > >>I guess my point is that I think you need to look not only 
> > at the data 
> > >>but also at how it is used when determining the normalization of a 
> > >>database. 
> > >> 
> > >>Joe 
> > > 
> > >-- 
> > >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. 
> > > 
> > 
> > -- 
> > 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. 
> > 
> > 
> 
> -- 
> 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 ...


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.