|
Has anyone ever heard that LOCAL-STORAGE could improve efficiency of a
COBOL program?
QUESTION:Has anyone ever heard that LOCAL-STORAGE could improve efficiency of a
COBOL program?
I'm working in the IBM mainframe arena, with non-Object Oriented COBOL
programs. A standard is proposed that says to add LOCAL-STORAGE to
every program, and to move "variables" from WORKING-STORAGE to
LOCAL-STORAGE, while leaving "constants" in WORKING-STORAGE. VALUE
clauses are to be removed from the "variables", and any existing
"initialization" logic (procedure statements is how I read this) that
sets a value for these items will be deleted.
When I read about LOCAL-STORAGE, I'm bothered by this proposal for
several reasons.
1. LOCAL-STORAGE is part of the OO language additions made by IBM to
mainframe compilers in advance of these being an adopted standard for OO
COBOL. To me, this means the LOCAL-STORAGE construct is "non-standard",
and could change, or even disappear, from COBOL. Also, if a shop wishes
to prohibit use of OO constructs, the compilers offer an option to
accomplish this - WORD(NOOO) - but if this were used, LOCAL-STORAGE
would be disallowed.
2. In the COBOL for OS/390 & VM Language Reference manual,
LOCAL-STORAGE is described as being "...allocated and freed on a
per-invocation basis. On each invocation, data items defined ... are
reallocated and initialized to the value assigned in their VALUE
clauses." This seems to be slower than using WORKING-STORAGE, if
accurate. However, a test I wrote (where a driver calls a subroutine 1
million times - both non-OO) seems to show that this is not how the
mainframe compiler operates. A Storage Report after execution did not
show any significant amount of allocation and freeing of storage in the
heap, on the stack, or elsewhere.
3. Removing VALUE clauses from the "variables" seems downright dumb in
at least some cases. For example, say I have a counter for the number
of records read and written while processing files. It seems intuitive
to give these items a value of zero and add to them, without any
initialization logic. If they really got reallocated, how could I use
them for counting anyway? On the other hand, if I have a subroutine
which will calculate a present value, I probably wouldn't expect the
target variable to have any initial value. But what advantage would I
get from locating such a variable in LOCAL-STORAGE versus
WORKING-STORAGE?
This makes me wonder if the proposal I'm reading is what the writer
intended?
ANSWER: Q: Has anyone ever heard that LOCAL-STORAGE could improve efficiency of a
COBOL program?
A: Working-Storage exists while the program is loaded, Local-Storage is
created when the sub-program is CALLed and is deleted on EXIT PROGRAM
(or GOBACK). This means that in a program that is many modules being
CALLed and EXITed the total memory requirement is [slightly] less.
If main memory is a significant problem then this may save a few
milliseconds swap time. Otherwise it just wastes CPU time in creating
and initialising heap storage.
In situations where the program is reentrant or serially-reusable or
threaded then there may be several copies of a 'Local-Storage' existing
at one time, one for each thread that is active in that program.
Q:1. LOCAL-STORAGE is part of the OO language additions made by IBM to
A: It is not strictly part of OO as it is in other implementations (such as
MF) independently of OO. Certainly OO may use it.
Q: 3. Removing VALUE clauses from the "variables" seems downright dumb in
at least some cases. For example, say I have a counter for the number
of records read and written while processing files. It seems intuitive
to give these items a value of zero and add to them, without any
initialization logic. If they really got reallocated, how could I use
them for counting anyway?
A: If you expect the value to survive an EXIT PROGRAM and be available on
the next CALL then DO NOT put it LOCAL-STORAGE, it just won't work.
Q: This makes me wonder if the proposal I'm reading is what the writer
intended?
A: Another clueless manager making technical decisions, or worse, accepting
a 'consultants' report intended to justify his charge out costs by
faking 'efficiencies' or 'savings'.
|
|
|
|
