[Originally posted to SIGCOBOL-L; this sent to SIGIMAGE-L/HP3000-L since
it covers a wide variety of topics.  Excuse the length]

Kriss Rant solicited some feedback for a new team looking at COBOL,
IMAGE, and VPLUS developments [don't have original message, sorry I
can't quote an appropriate lead-in] asking for suggestions for "modest"
improvements:

Mark Undrill wrote after Kriss Rant:
> Why be modest? If you've got it, flaunt it. I hope that was just an
> unfortunate choice of words and not another sign of marginalisation of
> the HP3000 platform.

I concur.  I don't think it is realistic to expect a massive effort on
the part of HP, but we can always ask.  Similarly, I don't think HP can
simply let products "retire to Roseville" either.  The entire compiler,
link-editor, and loader code will need to be addressed *if* HP elects to
exploit the capabilities in new hardware technology (e.g., 64-bit code
on PA-8000).  The current code generation back-ends are still PA-RISC
1.0 based.  Compatibility issues have been pointed out before and
represent a valid concern, but this is primarily an MPE kernel issue;
however, if HP elects to pursue 64-bit, the languages must adapt as
well.  At the language level, this could be a compile-time option (look
at current code with $CONTROL SYNC16/32, CALLALIGNED16/32).  I digress,
but wanted to point out the bigger picture of desirable evolution versus
the current stagnation at the very foundation.

> Implement COBOL'97 in full ASAP.

Ideal, but decidedly nontrivial.  Where does Cobol/UX stand today?  (I
have no idea myself).  How far removed from Cobol/iX?  We would likely
have a better chance of progress if there was a common front-end that
could be done jointly cross-platform.  I'm skeptical that CSY/ISO/WCSO
Roseville is/are adequately funded/staffed for something of this
magnitude (I'd love to be wrong).  MicroFocus is an option but an
expensive one; Fujitsu is another work-in-progress.  Do we wait for HP
to catch up on Cobol/iX, or have them help with a robust port of
something else?  I'd prefer to see COBOL97/xX (iX and UX) from HP.

> Make IMAGE/SQL a more coheasive product rather than the "IMAGE with a
> bit of ALLBASE tacked on around the edges" product we have at the
> moment.

This can't be done (IMHO) without using an RDBMS foundation, or in other
words, emulating IMAGE in Allbase (or Oracle, or whatever).  This loses
the speed, integrity, and support utilities we have in IMAGE today.  The
current IMAGE/SQL, despite its faults, is quite miraculous.  The weak
point is ODBC (particularly 32-bit client).  If by "cohesive" you mean
better support of IMAGE-like access via ODBC, I agree 100% and this is a
realistic goal.  If you mean "robust implementation of SQL" I don't
think this is realistic with an IMAGE foundation.

> V/PLUS is getting a bit long in the tooth. VPlusWindows and NewFace are
> steps in the right direction but it seems that as soon as HP announce
> them they disappear forever. Part of the problem is that V/PLUS is in
> FOS and NewFace (or somthing like it isn't). Maybe an approach similar
> to the one taken with Image/SQL where it could be included in FOS for a
> slight uplift in support fees could be used.

I don't know that this excites me to the point of bumping my support
fees again, especially in light of the additional IMAGE/SQL fees I'm
paying to wait for 32-bit ODBC.  I'm also biased; we're not VPLUS
intensive.

One underlying issue at stake is HP terminal dependencies.  In our
mixed-platform environment at the university, the typical (academic)
user is accustomed to getting freeware networking (Trumpet
Winsock/MacTCP),
and telnet/vt100 terminal emulator (EWAN/NCSA telnet).  Hard to justify
the bucks for Reflection, and more bucks for NS/VT.  Telnet/iX server
fixed the latter, but the former problem remains.  I'd prefer to see MPE
and applications become less "terminal dependent" where possible.  In
the Posix shell you can have vt100 or hp2392a termtype emulation almost
transparently.  At least one 3rd-party application emulates VPLUS on a
variety of terminal types (Preview<?> from Unison <formerly Tymlabs>);
I'd rather see that in the FOS.  Getting back to COBOL'97, if the screen
module is implemented, please don't make it hpterm only.

I also agree with Jeanette's earlier comments on SIGCOBOL-L that COBOL
enhancements should address Posix issues.  Most of "the Wall" around
Posix however lies in MPE and the intrinsics, not the language itself.
As an example, you would expect to be able to implement a COBOL cgi-bin
web procedure.  If you didn't already know, you can't do it directly on
either the NCSA freeware port or the OpenMarket supported server unless
you play games with an intermediate interface.  This is no fault of
COBOL, it's an MPE/Posix/$stdin/sockets issue.  These issues need to be
addressed at the common MPE layer rather than expecting a higher-level
fix at the language or application level.

On more general terms, I would refer back to one of the key points I
tried to make in the Proposition 3000 presentation at IPROF 96, forming
some common ground between GSY/CSY (and relatives).  Clearly HP has a
corporate focus with GSY and the 9000, followed by the NT/NetServer
groups, etc., with CSY/3000 groups lagging on somewhere behind.  If all
of these systems are "Open" as advertised, why are applications still
being developed/supported independently?  Obviously the OS groups are
necessarily unique, but applications?

One can argue the point that independent groups insures integrity and
maximum functionality on each platform, such as the 3000/CSY credo of
intensive integration testing and full support.  One can also argue the
point of platform dependencies making cross-platform development
impossible or complex.  I would point out the Gnu gcc and g++ compiler,
clearly platform dependent (it generates object code, can you get any
more unique?) ported by one individual from "cross-platform" source.
Similarly we have perl, python, csh, and other very dependent low-level
languages/shell ported from "cross-platform" source.  Then we have the
numerous higher-level applications like NCSA httpd, gnu utilities,
remsh, rcp, weblint, wusage, etc.; plus the commercial ports of Oracle,
MicroFocus COBOL, OpenMarket web server, etc.  If the rest of the world
can do it, why doesn't HP?  The more "proprietary" our beloved CSY
software remains, the less likely we are to see any progress due to the
high development/support expenses and low revenue from strictly
proprietary products.

I want CSY to focus on lower-level issues to make MPE more "open" along
with a concurrent corporate focus on cross-platform applications.  They
are making an effort with NT, and may very well have plans in place for
cross-platform UX/NT applications.  If we can add the 3000 to that
scenario we have a future, if only at worst being carried by the
coattails of UX/NT development/funding/R&D.  This is the "realistic"
future of the 3000, being more unix application friendly.  Note that
keyword "application" since that is what we've been flogged with in
recent years.  Software vendors are almost universally jumping on the
unix bandwagon as one would expect given the market share.  Similarly,
given the 3000 market share, they may or may not "attempt" a port to the
3000.  If they do (bear in mind they need a machine to port on and for
troubleshooting customer support issues, a nontrivial expense) the
porting process should be as trivial as possible.  Such is not the case
today.  Most ports were done with the help of Steve Elmer's libbsd.a and
includes or Mark Klein's gnu development environment port (or direct CSY
support as with OpenMarket).  The in-progress Samba and Java ports use
gnu.

In summary, I'm supportive and excited about developments in Image[/SQL]
in particular, and even VPLUS.  I'd love to see COBOL/iX advanced, but
skeptical about the level of committment available in the face of some
third-party appearances.  I'm concerned in general (as HP obviously is)
over the business strategy and budgetary justification of continued
proprietary application-level development/enhancement independent of
their primary focus on UX/NT.  This is not to say the 3000 is dead or
dying; but rather if it should retire or evolve.  The 3000 is (IMNSHO)
the hardware of choice if you have a selected application and are
evaluating possible platforms.  If the applications are there, it can
sell itself in an unbiased comparison (even for new customers; this
should be a no-brainer for the installed base).  Fix Posix and tear down
the wall first, deploy cross-platform development second, focus on the
remaining 3000-proprietary applications "actively deployed" third, and
leave the rest to Roseville.

Hope this doesn't sound negative (to the users) but rather than ask for
everything to be delivered yesterday, I thought I'd consider the big
picture and offer some realistic and productive suggestions to insure
the future of the 3000.  Maybe this will start some productive, positive
dialogue.

Jeff Kell <[log in to unmask]>