In article <[log in to unmask]> Ken Sletten - Code 331A
<[log in to unmask]> writes:
>Sender: HP-3000 Systems Discussion <[log in to unmask]>
>From: Ken Sletten - Code 331A <[log in to unmask]>
>Subject: HP Support of Strategic Stepchildren: [~200 lines]
 
<snip>
 
>Plus if HP would incorporate the above KUWP features and perhaps a few other
>requested enhancements to Transact, maybe HP could shock and pleasantly
>surprise hard-core RAPID users by at least suggesting Transact to new
>customers as a cost-effective host-based interface to ...<snip>
               ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
Warning:  Opinions expressed are my own!
 
The major Technical problem with Transact is...well... Transact.  The major
design strength and downfall of Transact is that Transact assumes it is top
dog, the "do-all" solution.
 
Well, to implement a "do-all" design means HP must create a transact
function for every new OS feature or product - such as the enhancement list
you wanted Ken.  To do so means you must lift tons of functionality from
other packages, 'c' code and Unix concepts;  then repackage them into
"Transact" functions.  Yahhh, right on!?
 
Wait a minute:  a business equation must kick in...cost .vs. benefit.  Can
HP maintain a fleet of Rapid programmers lifting features and writing
"transact functions" for every new piece of software (client/server, SQL,
OODB's, etc., etc.) that comes along and model this world under a "do-all"
Transact package??
 
No, _unless_ they can make money doing it.  Is the installed base of
Transact users large enough to continue this kind of development cycle and
still make money?  If this process continues, how long would it be before
you drag a Transact manual around with a fork lift?  What does third party
competition offer (i.e., why should HP bust their buns?)
 
When the HP 3000 was small and limited in product pickings
(IMAGE/VPLS/MPEF/KSAM) and all terminal based applications, the answer was
yes.  As the HP 3000 supported more and more open software features and
networking methods, the answer is No.  This a natural conclusion derived
from the Transact "do-all" design - not from mean old' HP executives who
won't cough up money.
 
I think HP concluded "No" to Rapid when they made the decision to open up
the 3k (and maybe taken a bath on the competition).  I speculate that they
knew it was fruitless to pursue Rapid enhancements in light of an open
systems direction, thus marking Rapid as a "mature" product.  But hey, HP is
sensitive to their users (much more than any other company) and has strung
Rapid stuff along as much as possible, targeting enhancements for "existing
core" items - but not new bold ventures.
 
 ***
 
I can suggest one possible solution to the Transact problem - turn the darn
thing into a REAL language - i.e., one that can link into another languages'
outer block.
 
Don't be fooled about Transact's "XL" library routines.  If you want to call
a transact "subprogram" from Pascal, C, COBOL, etc. you must pass through a
kludge transact processor interface, executed as a separate process, with
parameters passed through global extra data segments.  What a treat!
 
In short, make Transact follow universal code conventions and be linkable
into other standard language object code.  Then REAL progress can be started
on the future of Transact.
 
Ken, you are not going to get anywhere bringing up lists of new Transact
features unless Transact becomes a new breed of software, i.e., one that can
LINK in new features from other language sources.  If transact was
compatible with other standard languages or had header libraries like C, you
could actually write your own Transact interfaces or make use of all the new
vogue products (however, a little revamp of transact's data structures are
needed.)
 
Another possibility...??
 
Maybe HP could create a "Transact" roll-your-own-verb kit for diehards (a
generic transact verb hook.)  Define a generic verb description language
within the transact compiler and an area to link the generic interface
object code written in C, Pascal or COBOL.  Then, have the SIGRAPID group
swap transact verbs between themselves.  If you think this sounds stupid,
the internet community creates software this way.
 
The roll-your-own transact verb interfaces could actually be implemented
under the present transact compiler.  Let the users take transact for a
ride, it is certainly parked in HP's garage now.
--------------------------------------------------------------------
Eric J. Schubert                 Administrative Information Services
Senior Data Base Analyst         University of Notre Dame, IN USA
 
Email:            [log in to unmask]
World Wide Web:   http://www.nd.edu/~eschuber