X-no-Archive:yes
Others have answered Boris's questions to me, for me, and said what I would
have, and probably did a better job of it. I have certainly enjoyed reading
this thread.

I find it interesting that OSF's definition of 'open' seems to me to only
describe the kinds of systems sold by its members, while excluding
non-members' systems. Microsoft later responded with their own definition of
openness that neatly fits NT, but not quite anything else. It would seem
that what is generally meant in trade press by an open system is one that
started with more or less 'open' features, although its vendor then layered
on, um, 'vendor-implemented' features that are, um, well, 'proprietary' to
that vendor. Whereas other systems start from a feature set that is more or
less proprietary, while adding features to 'open' up that system. Of course,
all of this is at the OS level; at least, that is the way it seems to me.

Joe, you are in august company in your 'humble opinion' on the term "open
system". I once started reading Bjourne Stroustroupe's (sp? pronunciation?)
C++ Language Reference and his Design and Evolution of C++ (which had a
wealth of very dry humor - or at least I thought it did). In one of these
(if anyone else can point me to which book and what page, I would be in your
debt), he expressed his view that portability meant that the application
could be moved from one platform to another with one department-week of
effort, indicating that he expected some code work on the port to be the
norm.

As for the example of my beloved COBOL, it does take effort and even a
strategy for keeping the code portable. Don Nelson's COBOL 85 for
Programmers does state that "the SELECT clause is the clause that has to be
changed when moving from one implementation to another". I think that this
is primarily because of file system requirements, although HP COBOL has its
own colorful way of handing dynamic file naming. So I've been careful to use
platform-specific copybooks for SELECTs, as well as tucking away in
copybooks anything else that by definition tends toward the platform
specific, such as setting return codes  and getting environment variables.
This then requires a small set of such code for each platform, and the rest
can be and is ANSI COBOL. It also helps to set compiler directives on each
platform to flag code that the compiler thinks deviate from ANSI COBOL,
which is where some of that work goes for us. Our LAN compiler may not have
warnings that the HP COBOL compiler does, requiring some tweaking to keep
the warnings down to none. Obviously, not everyone thinks this is worth
doing, and not everyone who tries succeeds. It does take effort, and even a
strategy to keep the code portable.

Greg Stigers
http://www.cgiusa.com

-----Original Message-----
From: Joe Geiser [mailto:[log in to unmask]]
Sent: Wednesday, August 25, 1999 9:38 AM
To: [log in to unmask]
Subject: Re: IBM S/390 update reported

<snip>
I love when people bandy about the term "open systems" - as there is no such
thing.
<snip>
Even languages - people say
COBOL is COBOL is COBOL... which is true to a point - but every system
manufacturer that offers a COBOL compiler has placed their own extensions
into
it, and even the SELECT clause has differing syntaxes.

Basically, the term "open system" (at least IMHO) means that one can port a
program from System 1 running one OS, to System 2 running another, with
minimal
effort.  Sometimes we get lucky and it'll port over, compile clean and run
without any work at all other than extracting it from a tarball... but they
are
not the rule, they are the exception.  Most ports will require some work,
however minimal.