Re: "Shared" procedure division code


Oh Dear! I pressed a button... sorry Chuck.

Yes, my post was intended for IBMers. In future I'll make that clear.

And, within THAT universe my comments were general.

It was implicit (I thought) because I was responding to a post from Bill
Klein.

I did not mean to denigrate Unisys by implication and if Burroughs were into
virtual storage 10 years sooner than IBM, well , good for them. I worked on
B500 which did not employ it.

Probably because of your annoyance, you seem to have missed what I was
getting at in places, but I have no intention of labouring it. Suffice to
say I am aware that on occasions, large monolithic programs can run faster
than many smaller ones; that is why I was careful to specify the environment
I'm talking about. (The discussion was specific to CICS and IBM environments
that are doing online processing, not batch...)

Everything I want to say about this I said already in the two linked
articles.

If you have issues with what is stated there, I might be prepared to
respond... (then again, I might not... I'm getting pretty laid back about
programming these days...:-))

Pete.

TOP POST No more below.

"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:dc8854$4gp$1@xxxxxxxxxxxxxxxxxxxxxxx
>
>
> "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
>
>
>



.

Quantcast