RE: Normalization was Left AS/400 and Returned

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