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



On 14 Nov 2012 05:23, Gad Miron wrote:

<<SNIP>>

2. while looking at CHGPF/CHGLF CMDs I noticed a
KEEPINMEM(*SAME/*NO/*YES) parameter I haven't noticed before.
Is it new to 7.1 ?

Seems so; FWiW:
http://archive.midrange.com/rpg400-l/201111/msg00094.html

The last sentence in that message assumes prior knowledge of the discussion thread, particularly what is responded to in the message:
http://archive.midrange.com/rpg400-l/201111/msg00114.html

Is it equivalent/substitute/enhancement to SETOBJACC ?

The SETOBJACC allows a /user/ to request\attempt to move into memory the object\data. The /user/ has the capability to assign the pool to avoid the Storage Management from purging the objects and\or data from that pool.

The Keep In Memory parameter is apparently specific to the SQL Query Engine (SQE), and there is only Query INI [via CHGQRYA QRYOPTLIB()] capability to control which pool; i.e. not specific to any file. Any non-SQE utilization of the data would benefit only as a side effect of any prior /bring/ [paging] request effected by the SQE, and only if the data had not been paged out already.

The SQE can optimize for use of an "already paged" Access Path or Data [Dataspace] by building an Access Plan which can take advantage of that knowledge. I imagine that the KeepInMem attribute is a hint to the SQE to perform explicit [synchronous or asynchronous] paging of an Access Path or the Data [Dataspace] when implementing the query, after having built the plan which inferred the "already paged" is in effect. An additional possible effect might be that the SQE would not request an asynchronous release\purge when that KeepInMem attribute is in effect, for any scenario in which that might normally have been done; e.g. for an especially memory aggressive implementation.?

Isn't it actually unnecessary once you have a SSD unit?

Irrespective of Single-Level-Storage, Disk and Memory remain different. The Solid State Drive is still a drive, just as a spinning Hard Disk Drive is, and paging from /Drives/ into memory will still occur whether that be via faulting or by explicit /bring/ request. So while a particular SSD may perform faster for a read than a particular spinning HDD, the code path is effectively the same to get that data, and the memory\Storage Management to share the memory among all work is still going to be a point of contention. Any improved throughput would be expected to reduce chances that such work will be a bottleneck.


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.