| Clark F. Morris, Jr. 2004-06-25, 6:50 pm |
| 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 writing
> 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 aware
> 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 entry
> points into system software libraries, including but not limited to the MCP
> itself, and that it is written in some dialect of ALGOL. I seriously doubt
> 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 does
> so.
>
>
>
>
> I don't disagree. Reliance on the nonexistence of constructs that can allow
> breaches of security is rather better, though. If you can't get there from
> COBOL you can't get there from COBOL.
>
>
>
>
> No doubt to mine personally if "yours" is singular, although I would contend
> 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 being
> 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 that
> 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 release"
> if he tries); it may not be nearly so clear *how* the undocumented internal
> 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
>
>
|