HP3000-L Archives

December 1998, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sletten Kenneth W <[log in to unmask]>
Reply To:
Sletten Kenneth W <[log in to unmask]>
Date:
Tue, 29 Dec 1998 15:03:24 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (99 lines)
A number of people have commented on this thread,
after Gary Jackson started it with:

> >I have a want (need?) for a Report Writer to use on our HP3000.
> >Does anyone have a reccomendation based on personal
> >experience?  Oh, and by the way, it needs to be cheap!
>
QueryCalc, ODBC with your favorite (or at least familiar)
front-end tool, Data Express, and Cognos products have
already been mentioned.  I will throw in a few miscellaneous
$0.02 worth:

(1)   At least at the level of a 959KS/200, I believe QueryCalc
and the full Data Express product are in the roughly the same
price range (I have not checked prices on Data Express for
awhile).  Once you get to this tier, I believe there are no upgrade
fees to move QueryCalc to any larger machine;  I don't recall
about Data Express in that regard.

(2)   As has been well-documented on this list over the last
few years, if you get the full Cognos product suite on a small
machine and then want to upgrade to a significantly bigger
machine, be prepared for *really* big upgrade fees.

(3)   The bundled ODBCLink/SE product appears to work
pretty well for basic stuff, for a relatively small number of
concurrent users.  *BUT*:  For those that might not be aware
yet:  The bundled product is single threaded, while the full
Data Express - ODBCLink product is multi-threaded (per M.B.
Foster in a phone-con I had with them awhile back).  That
means for large numbers of concurrent users performance
may become a problem with the bundled ODBCLink/SE.  We
have not tested ODBCLink/SE with a lot of concurrent users
at our site, so have no data on just where you might run into a
single-threaded performance wall;  and of course YMMV.

(4)   ODBC/32 from Minisoft and LINKWAY from CSI Business Solutions (in the
USA;  Computing Solutions Limited in the UK)
are less expensive for most if not all machines than the full Data
Express - ODBCLink product.  Data Express and ODBC/32 can
do the "direct to IMAGE and MPE files" thing without going through
IMAGESQL - ALLBASE;  which means they provide what amounts
to a proprietary "ALLBASE analog".  LINKWAY uses ALLBASE, as
does the bundled ODBCLink/SE.  Both ODBC/32 and LINKWAY
are multi-threaded (the engineer doing ODBC testing at our site
noticed that ODBC/32 default appears to be three threads;  don't
know if it can be set to support more than that).  CSI, M.B. Foster,
and Minisoft are all on the web;  and all have pointers from that
incredibly useful vendor list at  www.3k.com.    :-)

(5)   Our site (NUWC Division Keyport) has been involved in an
effort to get ASP (Active Server Pages) via ODBC working with
the latest Microsoft development environment for a few weeks
now;  i.e.:  Visual Studio 6.0 and InterDev;  i.e.:  ADO 2.0 (Active
Data Objects).  We have tried various things with three drivers:
LINKWAY, ODBC/32, and ODBCLink/SE.  Our testing is still in
process, so not ready to report results yet.  For now will just note
that:
   [a]   We think we have made considerable progress.
   [b]   With the current state of MS products and 3000 ODBC
          drivers, manual tweaking appears to be required to get
          ASP to work;  i.e.:  The MS wizard(s) alone don't cut it...

(6)  With respect to INFORM and BRW, and their "long/short
term fate" as wondered by Paul:  I don't know about BRW, but
INFORM was recently enhanced by HP.  It is somewhat limited
in what it can do, but it does what it does very well and very
efficiently:  I still use it often for some or other ad-hoc report.  It's
interesting to note that INFORM is the only end-user report writer
that a significant number of our end-users ever became really
familiar with;  I think because of its combination of query flexibility
with ease of use (there's a moral in there for Mickey$oft
somewhere, but I won't get into that).

As to Dictionary/3000 not being Y2K compliant:  Yikes !!!....
Paul is correct.  I just went and looked at the structure of the
DICT/3000 database (it is standard TurboIMAGE), and sure
enough:  DATE-CREATE and DATE-CHANGE are pervasive
in almost all the datasets in the DICT database;  they are both
YYMMDD X6....  oops....
Of course changing the database is easy, but don't know what
it would take for HP to "sanitize" all the DICT utilities.  Guess
SIGRAPID has one more question for HP - Roseville...  Note
that to the best of my knowledge the fact that these two items
in the DICT database are still YYMMDD will not cause any of the
DICT utilities to crash or mess up;  I *think* they are just date
stamps that are not operated on...  but I won't bet my ranch on
that either;  HP will have to say...


And now, having thrown out all of the above, I invite correction
of any errors and omissions I might have made from the three
"generic" HP 3000 ODBC third-party vendors (I say "generic"
because DISC also has an ODBC offering, but I believe that is
fairly tightly bundled with their OMNIDEX product, and is not
really useable as a stand-alone ODBC solution...

Ken Sletten

ATOM RSS1 RSS2