Re: "Shared" procedure division code



"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:T9ADe.499087$3V6.422305@xxxxxxxxxxxxxxxxxxxxxxxxx
> As a follow up on another thread ....
>
> It seems to me that the most common place where I *used* to see the same
> source
> code (paragraph/section) repeated within a single program was in OLDER
> (IBM)
> CICS code where "locality of code" was an issue. That was that it was
> important
> that the application not need to "page in and out" sections of machine
> code
> depending upon application logic flow. Although this is still a MINOR
> consideration in that (and possibly other) environments, I don't know
> where it
> happens with NEW code today. However, in that older code, it was (medium)
> common to see the same (differently named) paragraph/section "near"
> multiple
> places in the program logic where it could be needed.
>
> This was also one of the few places that I have ever seen (again
> infrequent -
> but occasionally) COPY statements within a paragraph, e.g. (CAPS and '74
> Standard code)
>
> PARA1.
> IF XYZ
> PERFORM PARA2
> ELSE
> PERFORM PARA3
> .
> PERFORM PARA4
> PERFORM WINDUP
> .
> PARA2.
> lots of logic here
> IF XXX
> PERFORM PARA5-1
> .
> more logic
> .
> PARA5-1.
> COPY P5LOGIC.
> .
> PARA3.
> some logic - more than "one page" of memory required
> .
> PARA4.
> lots of logic here
> IF XXX
> PERFORM PARA5-2
> .
> more logic
> .
> PARA5-2
> COPY P5LOGIC.
> .
>
> ***
>
> With this "copy in procedure division" approach one could "physically"
> store
> common source code in a single place - but also have "locality of code"
> for the
> generated machine code.
>
> I neither recommend this approach nor (personally) know of any reason to
> use it
> in today's computing environment, but did think it was worth mentioning
> (both
> for the "use of duplicated code" and the solution to "maintenance of such
> code")
>

Bill, I know you don't condone this and I don't want to shoot the messenger,
but this is the biggest load of bollocks I have ever seen posted here, and I
have seen some good ones...

There is not and never has been any way you can guarantee 'locality of
code' by duplicating procedure code, whether you copy it or not. You cannot
know where the page boundaries are in generated code, by looking at source
code, without a huge amount of effort, and even if you did, the first time
you amend it, they are likely to change. The best you can hope for is to
increase the probability of code sharing a virtual page, and even if you do,
it doesn't matter by any amount of significance.

It is based on an assumption that was 'urban myth' when Virtual Storage was
first invented. Prior to VS it was common practice for COBOL programmers to
write their main line and place performed code into subroutines after the
mainline. (Some people still do this; it doesn't impact performance and it
never has...)

The 'myth' seemed quite logical and I was persuaded by it at the time. If
the new Virtual system was paging the code into 4K blocks it would have to
do a heap of paging to get to the subroutines that were physically removed
from the mainline. The theory was that the system would encounter a perform
and start paging through the mainline to get to the subroutines. It would be
much more efficient if the performed code was somewhere near to the place it
was performed. (Less paging). Some people went even further and started
duplicating code using COPY, exactly as you describe (I saw it too, in the
late 60s/early 70s after VS was released.) The reasoning was that this would
minimise paging. But the reasoning was flawed for the following reasons:

1. If there was memory available NO paging took place even in a VS
environment. (So the duplicated code simply gave you less chance of getting
your program loaded in the first place.)
2. The paging algorithm was not sequential and did NOT page through the
program to get to virtual addresses that were already resident. In fact, the
algorithm was much smarter than us COBOL programmers, and once something was
resident it stayed there until it really needed to go. (I once had it
explained to me by a Hungarian Mathematician who was also a Chess Grand
Master. It wasn't even as simple as 'least frequently used' being paged out
(which I believe is how the Windows Swap File works...))
3. The duplicated code was more problematic in increasing load time (and
paging) than it was succesful in optimizimg performance.
4. As much faster paging devices became available, the whole question became
more academic and these days it would be rare (and, in my opinion, stupid)
to see people in CICS environments still using this practice.

I realise you were documenting something that is historic fact, but it would
be wrong for people reading this to think it is good practice and
reincarnate a stupid practice that was buried in the 70s. In today's
environment this is irrelevant.

My personal preference is to encapsulate functionality into components that
can be shared from one location (by a .dll, suitably wrapped for the
environment). In environments that don't support this (like the mainframe),
called subroutines have to be a better solution than duplicated source.

I covered all of this in: http://66.152.52.10/archives/v3/v30201.asp and
http://66.152.52.10/archives/v5/v50101.asp where I also discuss the pros and
cons of called modules vs components.

Pete.



.