From: mathog@seqaxp.bio.caltech.edu
Sent: Thursday, July 13, 2000 4:09 PM
To: Info-VAX@Mvb.Saic.Com
Subject: got to remember to STOP trying to use OpenVMS...

I should know better by now.  I really need to put up a sign on top of my
monitor that says: 

   "STOP, are you insane?  Don't use OpenVMS for THAT!" 

Where "THAT" is pretty much everything I do.

Having neglected that rule this morning I wasted a couple of hours on the 
usual wild goose chase.   It all started when a user told me "I want
StackPack, can we get it?"  (It's a program that clusters EST sequences and
keeps track of the results.)  So I contacted the people who distribute it,
which in due course led to the following package dependencies: 

  StackPack (C++)
     autoconf 
     sql database which speaks odbc
     freeodbc++                   (http://wwww.orcane.net/freeodbc++)
        autoconf
        unixODBC (C and C++ and lots of .sh) (http://www.unixodbc.org/)   OR  libiodbc (below)  
           qt                     (http://www.saalhausen.de/lehrig/qt21_bck.zip)
           autoconf 
        libiodbc (C)              (http://www.iodbc.org/dist/libiodbc-2.50.3.tar.gz)

The good news - qt is available from the URL shown (but not from Compaq)
and some fellow from mimer.se had provided a .com to build libiodc, but 
apparently from 6.x, and I don't know if it works on 7.2-1 or with the 
current version of libiodbc.  That .com was a good thing for without it
there would have been an autoconf dependency on that package too. 
Ironically the README says: 

    As the iODBC driver manager uses autoconf/automake/libtool it should
    be portable to most modern UNIX platforms out of the box.

We all know that for platforms which don't support autoconf etc., most 
notably OpenVMS, it is a PITA to deal with these sorts of packages.  But 
what are you going to do - that's the way the Unix guys build packages 
these days.

Anyway, this is like far too many pieces of software I see.  The only way
to even start to build this sort of package for OpenVMS requires that I
first build it on a Unix box - and if I'm going to do that, why bother
doing it over again for OpenVMS?   Moreover, there's a fair chance that
that build will work the first time on Unix, whereas to make it work on
OpenVMS will almost certainly require weeks of work, with success not being
guaranteed in any case.  Especially if part of the port requires also 
porting an entire database.

Before Kerry or anybody else starts in with the DII-COE story, I just want
to point out how very high the bar is for that to make any real difference
in my (or anybody else's) ability to get software running on OpenVMS.  To
put OpenVMS back in the game that environment must be so Unix compatible
that all of these packages would have built with no more effort than a
minor tweak or two to the configuration files.  I don't know what the
DII-COE specs say, but the real acid test for the usefulness of this
product would be to see how many "unix" packages randomly selected from
freshmeat or any other Unixy software site build AND work with no or only
minor modifications.  Yes, that means that they must also fix the 32k and
64k limitations in RMS and elsewhere, as exposed by the C RTL, because
those don't exist anywhere else and they do break software, and also all of the 
X11 incompatibilities.  And they'll also have to fix the various
performance problems which have been beaten to death here already and make
OpenVMS a very unattractive option.   Such a tall order, and DII-COE has 
such a smell of "son of POSIX" about it - mere window dressing - a check
off on some capabilities list for a government bureaucracy. 

Ah what's the point?  Compaq management doesn't give a rat's ass about any
of this.  Or if they do, that's even sadder, because they're doing a pretty
poor job of dealing with any of it - on every level.  Renaissance?  No 
signs of it around here.  They're happy with $4B when they should be 
shooting for $40B.

Time to walk away, or real soon anyway - there's still that one package we
use that doesn't have a Linux/Alpha version or a suitable replacement. And
that is ALL that's keeping our one OpenVMS system from an immediate and
irreversable OS change. I'm going to miss having a nice secure OS, but if
that nice secure OS can't hardly be used for the work we need to do, it has
to go. 

Regards,

David Mathog
mathog@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech