Re: "Shared" procedure division code


"Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
news:3kp9r4Fvcc0pU2@xxxxxxxxxxxxxxxxx

> It is based on an assumption that was 'urban myth' when Virtual Storage
was
> first invented.

>From the Unisys History Newsletter, Vol. 3 #5 (10/1999), available through a
search of "Burroughs virtual memory" on the internet:

"IBM's 1972 announcement of virtual storage for its large 370 series
machines was taken by Burroughs as validation of the virtual memory concept.
The company held a well-publicized tenth birthday party for the B5000 at the
old ElectroData plant in Pasadena, where a B5500 (which had been rebuilt
from a B5000) was still in operation. By the early 1970s, both the large and
medium Burroughs computers had inspired a high degree of loyalty among their
users, who were proud of the advanced features incorporated in the Burroughs
architecture. It would still be several more years before IBM really moved
into multiprocessing, while it was commonplace to Burroughs users. "

Have you checked your forehead lately? Sounds to me like a blue-ink tattoo
of three block letters thereupon might be starting to show through! ;-)

>Prior to VS it was common practice for COBOL programmers to
> write their main line and place performed code into subroutines after the
> mainline.

It was common practice on the B5000 and is still common practice on its
descendants, if you're talking about paragraphs and sections, as distinct
from ANSI-85 "nested programs", which of course weren't available in
standard COBOL until something like thirteen years after the introduction of
Virtual Memory on the IBM S/370 (and twenty-three or more years after the
introduction of Virtual Memory on the Burroughs B5000).

>(Some people still do this; it doesn't impact performance and it
> never has...)

Some people do this, and whether it impacts performance or not depends on
the architecture of the system and where the code segment boundaries fall.

It may never have impacted performance on the systems with which you are
most familiar, but because something is true for a subset of the universe
does not make it universally true; ditto for false!

> The 'myth' seemed quite logical and I was persuaded by it at the time.

I still am, actually, to a degree, particularly if a segment boundary falls
within a critical path in the program.

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

Our experiments showed that in an era in which memory was a precious
commodity arbitrary-length data paging combined with unmodifiable object
code led to a *much* higher virtual-to-real ratio than was practical on
fixed-page virtual memory architectures. I am not convinced that what you
describe as the "new Virtual system" is somehow more advanced or
fundamentally more efficient than what the B5000 had a decade before.

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

That may be the theory on certain Virtual Memory systems, but it does not
apply to all.

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

If there was -- and is -- memory available, a code segment is loaded when it
is first touched, just as is true when memory is not available. If there
isn't memory available there's a good chance the code will be marked absent
and will have to be reloaded.

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

While I understand your arguments about repeating code in a program, in the
broader sense there are practices that you might deem irrelevant in the
machines *you* work on, but that might have significant benefit for machines
*others* work on. To dismiss out of hand that with which you are not
familiar because it is irrelevant *to you* is one thing; to proclaim it more
universally irrelevant quite another.

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

By "called subroutines" do you mean nested programs, separately-compiled
programs, or PERFORMed paragraphs/sections?

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

Ah. That puts us into the OO model, and I don't have a quarrel with that
approach to application design. I think it more an efficient approach to
the *design* process (just as Structured Programming is viewed as an
improvement over "spaghetti") bement , but I think it more than anything
else an appropach to *design* for its own sake than an approach that will
always and everywhere produce applications that consume fewer resources at
execution time compared to all competitive design approaches.

But have you verified the efficacy of all of these conclusions on, oh, say,
a large Unisys ClearPathPlus Libra 580 system? On such a system, it's
probable that a monolithic one-megaline COBOL program will outperform a
hundred 10K-line COBOL programs doing the same thing (regardless of whether
memory is constrained on the system or not). And how code is arranged in
the program may impact its efficiency, whether it's one of the 10K line
programs or the monolithic monster.

-Chuck Stevens


.

Relevant Pages

  • Re: "Shared" procedure division code
    ... within THAT universe my comments were general. ... > It was common practice on the B5000 and is still common practice on its ... > Virtual Memory on the IBM S/370 (and twenty-three or more years after the ... >> the new Virtual system was paging the code into 4K blocks it would have ...
    (comp.lang.cobol)
  • Re: Processes memory
    ... As long as it was confined to niche players like Burroughs ... and DEC and IBM, and hadn't been picked up by any of the ... virtual memory were still quite common until around 1988. ...
    (comp.unix.programmer)
  • Re: 32 bit flat memory model
    ... perform paging or should the OS do it? ... segments, but others have allowed various degrees of modifiable data in ... You try to convince the overlay linker that if code segments 3, ... Before "conventional" virtual memory became common, ...
    (comp.lang.asm.x86)
  • Re: Page size error after upgrading from XP Home to XP Professiona
    ... I've tried changing the virtual memory paging size ... "Windows created a tempory paging file because of a problem that occured ... Any ideas why Windows doesn't seem to be taking my virtual memory page size ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Old Hashing Routine
    ... Even IBM had paging in the laboratory. ... added virtual memory support and changed the name to 470V/6. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)