HP3000-L Archives

October 1996, 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:
Ken Sletten B894 C312 x62525 <[log in to unmask]>
Reply To:
Ken Sletten B894 C312 x62525 <[log in to unmask]>
Date:
Mon, 28 Oct 1996 11:54:00 P
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
Someone replied to Kriss Rant:

>> My name is Kriss Rant, and I work in product marketing for the
>> HP 3000.
>>
>> We would like to understand your future business requirements
>> in the area of application and database environments.Kriss,


>I have been a consultant for a major manufacturer in the Detroit
>area for over 5 years.  I do the technical support of a HP3000
application.
>We have over 50 HP3000 Series 70s.  We have just started migrating to
>HP3000 928.
[....SNIP....]
>  I can visualize an HP3000 Image database with an ODBC
>middleware and a state of the art front end.  Can you?

Absolutely.  That is what we are in the process of implementing
at our site;  or rather adding on to our current system....

Putting on my SIGIMAGE Chair hat for a moment, you probably
already know that M.B. Foster's ODBC Link product has
provided an off-the-shelf 32-bit ODBC access solution for
Image, MPE, and KSAM file access for most of a year.  The
32-bit driver part of this product for Image access ONLY will be
bundled by HP and should be available in ~ a couple months.

>  So now how can we move our application's business rules
>from a closed environment (we use the programing lanuage
>called Transact and thats C-L-O-S-E-D) to an open
>middleware solution? Perhaps that can be provided.

Switching hats, and putting on my SIGRAPID Executive
Committee (SREC) hat for a bit:

We also use Transact;  we have perhaps 25+ work years in
native mode Transact/iX code.  But we are adding a 32-bit
client-server front end that in most cases preserves the huge
investment in business rules we have in our Transact code.
That is in fact what Transact/iX is good at:  High-performance
Image database I/O;  with the flexibility that SQL can never
deliver.  But for various reasons Transact does not "fit" the
TCP/IP-sockets-client-server paradigm very well (I can't
believe I used that word again.....).

The SREC (which I am on) is currently working with HP to
get them to implement another key Transact enhancement,
that would allow Transact/iX to efficiently interact with server
processes written in "C" or Java or whatever.  If HP does this,
you may find that Transact is not nearly as "CLOSED" as
you might think (even without the enhancement, we are
integrating our Transact systems with 32-bit client-server;
but it would be a lot easier with a little more help from HP).

I would be very interested in talking to whoever posted this (I
don't see the message headers by the time it gets to me).
Actually, because this person mentioned they have over 50 HP
3000's running Transact code in the Detroit area, I think I know
who it is... But I won't guess in public.  If you are willing to
contact me directly, see below for my info.

BTW, if you have been running compatibility mode Transact on
your Series 70's and have never seen native mode Transact/iX,
you won't believe how much better and more capable it is;
especially the native mode debugger.

thanks,

Ken Sletten

=====================================
email:     [log in to unmask]
smail:     Ken Sletten
                NUWC Division Keyport
                Code 312, Building 894
                Keyport, WA  98345-7610
tel:  360-396-2525    fax:  360-396-7861 / 2851
=====================================

ATOM RSS1 RSS2