Check the SETOBJACC command. Terry
Unconfigured Ad Widget
Collapse
Announcement
Collapse
No announcement yet.
Keeping a COBOL program and file resident in memory
Collapse
X
-
Keeping a COBOL program and file resident in memory
Bob, you're correct. But there is some benefit ON A "LOCAL" level or just for the one user. About 4 or 5 yrs ago, I attended one of John Sears' seminars about COBOL/400 performance and design issues. Amongst so many minor details that can lead to better performance, if I remember correctly STOP RUN causes a full "flush" from memory of the WORKING STORAGE. The actual MI of the code can stay in memory for all CALLers to use so that a new copy is not fetched on each CALL. Without STOP RUN, variables in WORKING STORAGE that do not have a VALUE initializing the contents, can retain their contents on subsequent calls (and these programs can execute faster without the initialization instructions happenning on each CALL). But this is on each USERs own session. HTH Phil
Comment
-
Keeping a COBOL program and file resident in memory
There are some downsides to SETOBJACC for files. The file may be larger than the actual memory available, leading to constant thrashing of parts in & out of memory if access of records is in different areas of the object that are currently in memory. The file may not even be loaded if it is larger than the available memory. I believe it is a copy of the file and UPDATES don't happen in REAL-TIME to the real object on disk. If the job for the SETOBJACC is not the only one running on the system, another job may cause the file to be taken in & out of memory as each session is attended to by the CPU. Your mileage may vary. HTH Phil
Comment
Comment