|
Oh, never mind, I get it...... :/ Memory resident object might get paged out when the subsystem needs more memory for running applications. If you need to keep it in main storage, you must have a pool with enough storage and no other activity. Eric DeLong Sally Beauty Company MIS-Project Manager (BSG) 940-898-7863 or ext. 1863 -----Original Message----- From: DeLong, Eric [mailto:EDeLong@xxxxxxxxxxxxxxx] Sent: Friday, October 10, 2003 12:31 PM To: 'Midrange Systems Technical Discussion' Subject: RE: FNDSTRPDM memory enhancement Craig, I was thinking about SETOBJACC, to just force these source files into main storage... but I looked at help to refresh myself, and now I'm confused. <snip> Set Object Access - Help The Set Object Access (SETOBJACC) command temporarily changes the speed of access to an object by bringing the object into a main storage pool or purging it from all main storage pools. An object can be kept main storage resident by selecting a pool for the object that has available space and does not have jobs associated with it. Repeated use of the command can cause a set of objects to be resident in a main storage pool. <end> The part about using a pool that does not have jobs associated with it.... I don't remember that part. Does that mean there has to be a pool defined that's not allocated to a subsystem? It's been a while since I looked at this stuff. :( Eric DeLong Sally Beauty Company MIS-Project Manager (BSG) 940-898-7863 or ext. 1863 -----Original Message----- From: craigs@xxxxxxxxx [mailto:craigs@xxxxxxxxx] Sent: Friday, October 10, 2003 11:35 AM To: midrange-l@xxxxxxxxxxxx Subject: FNDSTRPDM memory enhancement I have been teetering on whether this should go on the RPG list or the MIDRANGE list. Maybe it is better here. So, I will make a copy from the RPG list. ----- Forwarded by Craig Strong/DEKKO on 10/10/2003 11:33 AM ----- Craig Strong To: rpg400-l@xxxxxxxxxxxx 10/10/2003 09:37 cc: AM Fax to: Subject: FNDSTRPDM memory enhancement I have a command I created called FNSTR that searches for a string in any source file in any or all libraries in batch. It has the same options as FNDSTRPDM so it is basically a beefed up version of FNDSTRPDM. As many of you have probably noticed, doing a FNDSTRPDM (or 25 then F13) on members goes a little slow the first time. It is slowest when interactive as it is displaying the scan progress. The second time around on the same command on the same set of members goes fast. My guess it that these members are saved in memory since any user doing scans on that set of members goes fast. If you open each member in an RPG program, do a single read, and close, I think that places the entire member in memory. Doing a test on this (open, 1 read, close) of each member in a source file in a library and then doing a "25" F13 in that source file showed it being very quick. Just doing an open and close without a read did not speed up the process. Every morning a system scan is initiated in batch that basically does a DSPFD for all common source physical files to outfiles. I was thinking of taking these resulting outfiles and submitting jobs to batch for each library processed for each source file. Then, whenever someone does any type of find, it would be quick. I think members would open faster too. We also have a utility called FNDSRC that uses these outfiles to scan for any library containing the input member and source file name. This utility wouldn't be effected but it comes in very handy. Should I do the open, 1 read, close of every source member in batch jobs (1 library per job)? Any system issues that might come up in doing this? Am I correct in thinking of this as members stored in memory? Is this the same thing as when a program is replaced while someone is using it and they are running the version still stored in memory until they exit? Am I crazy? Thanks, Craig Strong _______________________________________________ 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 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.