Portability and porting (was: Micro Focus position on the "Standardized" OO

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1154042276.584592.119660@i42g2000cwa.googlegroups.com...
> William M. Klein wrote:
>
<snip> 
>
> Vendors provide the ability to port _to_ their special features from
> other vendors. They do not support  'portable source code' in the sense
> of 'write it for our compiler and recompile it on someone else's'
> (except for example MF targetting mainframe development).
>

Interesting point and one that once upon a time and long ago was a major par
t of
my "job".

When I did work for Micro Focus (pre-MERANT) my primary respoonsibility (for
much of the time) was "IBM Mainframe compatibility".  This was because a lar
ge
portion of MF's revenue at that time was in providing a workstation environm
ent
for developing applications intended to run on IBM mainframes (and be compil
ed
with IBM mainframe compilers) - as you mention above.

This was also the primary revenue source for Realia (pre- CA - if not
afterwards).  Fujitsu's compiler actually started out as "shared" source cod
e
with IBM (but the law-suits related to that were well documented).

The history of COBOL and portability is one of "de jure" vs. "de facto"
standards.  When COBOL was "young and growing", IBM mainframes were a (the?)
dominant playing field for "business" data processing.  What IBM did (with C
OBOL
as with many other things) was OFTEN (not always) "copied" by other vendors 
- so
that people COULD "port" their applications (easily) from IBM to their
environments - regardless of what any Standard did and did not say. Today, t
here
is (IMHO) no correspondingly DOMINANT COBOL vendor. (M$ may be considered a
correspondingly dominant operating system vendor - whether people like them 
or
not <G> )

X/Open was a (relatively) early attempt to take EXISTING extensions and crea
te a
"Standard" that actually provided portabilikty across "open systems" (usuall
y
Unix or similar environments).  Some of those extensions are still common to
day,
others are not, e.g.
-  Line Sequential files
- Comp-5 (non-truncated binary and/or operating system specific binary)
- methods of getting and setting environment variables and program "argument
s"
- even extended Accept/Display (especially with screen section)

Most of those (I think) appeared first as an extension in one vendor's
implementation and then in multiple vendors implementations then in X/Open. 
 The
'02 Standard actually "picked up" both Screen Section and
File-Sharing/Record-locking FROM the X/Open specification, but made them
"processor dependent" which is "newspeak" for optional.

My impression (true or false) is that when an implentor provides a "new
extension" that meets their customers' needs (perceived or real) that other
vendors DO add similar and usually dentical extensions
- if their customers also want this type of facility
and
- if this vendor wants to provide a "portation facility" FROM (as you
indicated) the other implementation

The more various implementors provide the "same" extension, the more likely 
it
is to become a de facto Standard.

***

Bottom-Line:
Other than providing a "development off-loading platform" (e.g. Micro Focus
Mainframe Express), you are certainly correct that most (all?) vendors are N
OT
in the business of providing "easy" portation AWAY from their products.  On 
the
other hand, my perception is still that vendors DO provide extensions to mee
t
the actual "buisness needs" of their current customers (e.g. both Micro Focu
s
and IBM XML support/extensions).  If these extensions are truly needed in
"portable" source code, then multiple vendors will pick them up.  If they ar
e
not (such as my perception of the COBOL OO Collection Classes - and COBOL
Standard Arithmetic) then no amount of "standardization" will get vendors to
provide them

--
Bill Klein
wmklein <at> ix.netcom.com