Method to force keeping of source was Re: Is it possible to use the

Chuck Stevens wrote:

> "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> news:40d77642.32368855@news.optonline.net...
>
> 
>
> 'give
> 
>
>
> To write MCP-like code, or to modify the current MCP, you have to be writi
ng
> in a language that allows you that sort of access to the hardware in the
> first place.   Programs containing such constructs can't be executed as
> standalone programs to begin with (although COBOL programs *might* be able
> to access them through other interfaces if the MCP has previously "blessed
"
> those other interfaces and the wind is right).
>
> 
>
>
> Thanks for the reference.  Taking this as an example:  "A dynamic memory
> cache algorithm, which alters the cache size based on the instantaneous I/
O
> and memory traffic."  I don't know what the particular system software
> interfaces this particular piece of system software uses are, but I am awa
re
> that there are a whole lot of procedures in the system software that the
> knowledgeable can exploit to provide this sort of functionality without
> having to fish it out of raw memory, and as I recall these interfaces are
> documented.  My guess is that this program is making use of documented ent
ry
> points into system software libraries, including but not limited to the MC
P
> itself, and that it is written in some dialect of ALGOL.  I seriously doub
t
> that *any* of the entry points this program is using to gather and modify
> this information are accessible from COBOL.
>
> 
>
>
> Ummm ... ?   Do I?
>
> 
>
>
> I don't know whether users are building software that might exploit such
> holes.  I *do* know that they are not building software *in COBOL* that do
es
> so.
>
> 
>
>
> I don't disagree.  Reliance on the nonexistence of constructs that can all
ow
> breaches of security is rather better, though.   If you can't get there fr
om
> COBOL you can't get there from COBOL.
>
> 
>
>
> No doubt to mine personally if "yours" is singular, although I would conte
nd
> the knowledge of the architects of the system (some of whom have been
> involved in the evolution from the B5000 to the latest Libra 580 over a
> period of forty years or so) would be hard to beat.
>
> If some third party comes up with a "better idea" for the Unisys MCP
> environment, it might be a demonstration that the developer saw it as a
> greater marketing opportunity than the Unisys beancounters did.  I've seen
> that happen on a number of occasions.   I've also seen third-party
> developers take on projects that Unisys started and then decided not to
> pursue.
>
> There is a great deal about our system software *and* our hardware that
> changes over time, sometimes significantly, without there necessarily bein
g
> any notice of the speicifics of those changes to the users, except that we
> require our users to recompile all their programs every few years to keep 
up
> with these changes.
>
> It's one thing for a user to know *that* he has to recompile a program tha
t
> was compiled under SSR 45.1 before it will execute under SSR 50.1 (after
> all, the MCP will tell him "This codefile is too old to run on this releas
e"
> if he tries); it may not be nearly so clear *how* the undocumented interna
l
> interfaces might have changed, much less *why*, between those releases, or
> what the consequences would be if he convinced the MCP to relent in its
> prohibition.

The above is one way to force a shop to keep correct source.  This must
make system upgrades interesting.  I think that IBM is of two minds on
this.  The z series is still able to execute many programs that were
compiled and linked 30 years ago and more (360 and descendants).  I
understand the i series (S38 and AS400 and descendants) requires mass
recompiles as a part of system upgrades.  I don't know what shops do if
they lose the source.

>     -Chuck Stevens
>
>