I agree on the below.--  Nick Demos
 
On Fri, 5 May 1995, Scott Herman wrote:
 
> At 12:48 PM 5/4/95 P, Ken Sletten b894 c331 x2525 wrote:
> >>>>>    First the update:
> >
> >After post-IPROF discussion with HP, it is now my
> >understanding that the "shareware" FSF GNU  C++
> >compiler that HP talked about bringing to the 3000 at
> >IPROF *will* be supported by HP;  i.e.:  The compiler
> >itself will be downloadable from JAZZ or whatever,
> >but users will have the option to purchase software
> >support for that compiler directly from HP (I assume
> >what this means is that HP will contract with the third
> >party to act as the lab for C++).  This sounds like at
> >least one big step in the right direction to me.
> >
> >Something else I wasn't aware of (maybe old news
> >to many of you, but new to me):   Most other vendors
> >who have C++ compilers on their platforms apparently
> >use the shareware C++ product as a base for what
> >they provide.  If that is the case, having a 3000 version
> >of GNU  C++ should mean it will be easier to port C++
> >programs from other vendor platforms, compared to
> >porting C++ from HP-UX.  And a 3000 GNU C++ can
> >be available much faster than a port from UX....  Since
> >we need C++ on the 3000 ASAP for the client-server
> >extension to our Transact system that we are working
> >on, this is a major factor for our site....
> >
>
> I thought this was clear from HP's announcement. IMHO this gives us the best
> possible solution for portability and evolutionary capability, giving us,
> the MPE/iX developer community, unprecedented capability to drive the
> enhancements and optimization of this critical development tool.
>
> >
> >======================================
> >
> >***   C++ on MPE/iX:   Requirements and Options   ***
> >
> >1)   If a compiler existed which handled only Unix-like
> >constructs (at least initially) were supported, would
> >you use it ?
> Yes. In fact I think that a 'unix only' mode would be appropriate even for a
> mature product, since it will often be used to compile code which needs to
> be portable to unix.
>
> >
> >2)   If an MPE C++ compiler were enhanced after the
> >initial port, what capabilities would it need:  indicate
> >"don't care", "useful", or "must have" for each ?
> >        Intrinsic support:
>             useful (I can just declare them as externs, if I need to)
>
> >        Access to IMAGE:
>             It depends on the form.
>             How would this differ from Intrinsic Support?
>
> >        Access to KSAM:
>             Again. It depends on the form.
>             How would this differ from Intrinsic Support?
>
> >        Long pointer support:
>             MUST HAVE!!!
>
> >        Ability to run in MPE Name Space:
>             MUST HAVE!!!
>
> >        Use default MPE naming conventions:
>             MUST HAVE!!!
>
> >        Other >________________________:
>             A Well defined and documented means of building XL code.
>             A fully XL resident runtime library, so that c++ code in the XL
> could be called by a non c++ outer block (main) such as a
>             CM SPL program, or a NM COBOL program.
>
> >3)   Would you trust a third-party compiler that was
> >supported by HP ?
> Yes. and I would feel even better about it if source for the compiler were
> accessible.
>
> >
> >4)   What would you be willing to pay HP for annual
> >support of C++ on MPE/iX ?
> Yes, provided the cost is not unreasonable.
>
> >5)   If the cost of acquisition of the compiler were
> >minimal or non-existent, would you be willing to pay
> >higher support fees over a guaranteed term ?
> Yes. Hoever I think that HP should take into consideration that supporting
> this compiler will make it much much easier for 3rd party developers to port
> products that will generate mucho business for HP. In other words, HP, Help
> us help you.
>
> >
> >6)   Additional comments/remarks/concerns on this
> >subject:
> I have, throughout this thread, been very supportive of HP's decision to go
> with the de facto standard in c++ compilers. IMHO this gives us the best
> possible solution for portability and evolutionary capability, giving us,
> the MPE/iX developer community, unprecedented capability to drive the
> enhancements and optimization of this critical development tool. It also
> paves the way for a true partnership between HP and those develooping
> applications for MPE/iX.
>
>
>
>
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> :                                                                           :
> : Scott Herman          [log in to unmask]   Yale-New Haven Hospital
> :
> : Dept of Lab Medicine                                       20 York Street :
> : (203) 785-2449                                       New Haven, Ct. 06504 :
> :                                                                           :
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>