Alfredo and Cecile; and in there somewhere Steve D; and
from a couple months ago Wirt:
> > Well, there are sites using Transact all over. Transact
> > programming is so efficient that a lot of sites can't keep
> > someone busy full time, so they just get some temporary
> > help when they need it.
>
> This sounds like the ideal copy for a proactive marketing
> campaign involving Transact. I'm sure our mutual friend Ken
> Sletten will be very interested.
> ..... Your 6.5 (or maybe 6.0?) Communicator has an article
> that talks about Transact, and specifically about this capability,
> which is identified as "deferred database opening". It allows
> you to either defer the opening of a database until it is actually
> accessed by the Transact program, or to pass in the base ID
> of a database opened by the calling program for use by the
> called Transact program.
SIDEBAR: Steve Dirickson gets credit not only for being the
effective "squeaky wheel" in this case; he pretty much wrote
the complete detailed ES; that HP ended up implementing
essentially as they received it from him (with some tweaks
agreed on at subsequent SIGRAPID meetings & etc., IIRC).
Plus don't overlook the other major recent enhancement that I
expect a lot of Transact sites are still not aware of: Transact
now supports using *all* IMAGE find modes on the Transact
FIND verb; with the addition of the "; FINDMODE = dd" option;
including AFAIK all TPI modes. This was not the case prior to
the latest version; where you still needed to do PROC calls to
do anything except MODE = 1 on the Transact FIND verb.
I keep trying to catch up on what's left of the 2500-or-so emails
that stacked up while I was out in the woods all September; may
just have to give up on that and hit a few highlights as time and
circumstance allows.... so here's a few of my $0.02 on an old
thread:
Wirt graciously did the set up to allow users to easily bring all
the needed components to run BASIC/3000 to their 3000's...
and as Wirt essentially said (I'm paraphrasing) it's hard to beat
"bundled and free".... and I applaud Wirt's help in making
BASIC easily available to the world.... that is a "good thing"..
BUT (you probably sensed I was leading up to a "but"): For a
general-use HP 3000 TurboIMAGE database I/O language, it
seems to me that CM BASIC has some fairly serious limitations
for many if not most end-users (that are not commercial
developers intimately focused on one or two products):
(1) It's still CM.... I know, I know: Most well designed PROGs
spend most of their time in IMAGE or etc... but not nearly all
(probably hardly any) end-user programs are as well-designed
and meticulously constructed as QueryCalc. I've seen NM to
CM and CM to NM switches go nuts on our 959-400 a number
of times; plus while I'm certainly no expert in this area, there
are still a number of CM limits that my gut tells me will be more-
or-less constraining with a CM language (YMWV, of course);
especially for bigger, more complex systems.... In the long
run having a CM compiler as a critical link in the system
development chain as the 3000 moves forward to the "N" class
boxes and beyond does NOT give me a good, warm fuzzy
(sorry, Wirt.... :-) ).
Not-really-a-SIDEBAR: Since BASIC/3000 is AFAIK written
entirely in SPL, my specific above could I expect be alleviated
if "somebody" would undertake to SPLash! it.. from the couple
short conversations I've had on this in the last couple years, it
sounds like just the SPLash!ing of the existing compiler part
would *probably* be pretty straightforward... but going through
the code itself to take out the limits that are enforced by the
BASIC compiler and (I would guess) add code to take
advantage of being SPLash!ed might be a whole 'nother story
(I'm clearly not qualified to even guess).
(2) The two-character variable name limitation. As a practical
matter, for end-user programs I think that if you look at the
entire program code life-cycle this is more serious than many
people might think at first glance; i.e.: For a program of
anything more than trivial complexity, being limited to only two
characters for variables quickly leads to code readability
becoming not much better than assembly language to anyone
but the author (and after a few months off, probably for the
author as well). OTOH, with long variable names and high-level
access to IMAGE, well-written Transact code (yes: You can
write garbage in ANY language if you're sloppy) is essentially
English-readable; even for programs with HUNDREDS of
variables.
(3) Various stack, table, and etc. limitations (I don't recall off
the top what all they are).
OTOH:
NM Transact has that incredibly good NM Trandebug
debugger (yes: I've said that several times over the last few
years). NM Transact code performance is as good as COBOL
or close enough that the difference doesn't matter.... and in
most cases can be done with from 15 to 40 or so percent the
lines of code...
BUT (to my own comments, this time): Of course Transact
ONLY runs on the 3000. My *guess* (NOT from inside info)
is that right now there are may still be something like 900 sites
running Transact. Given current HP posture & directions, it is
unlikely to say the least that there will be large numbers of
Transact compilers sold to sites that do not already have it (but
HP certainly does sell compiler upgrades when existing users
move up to bigger HP 3000's).
Given all, of the above, after some reflection from time to time
over the last year or so, I have come to wish that sometime not
too far down the road HP would bundle Transact. We would
then (if you add the "coming soon on the Atmarian calendar"
fully-fleshed out version of QCTerm) have a complete, bundled,
fully NM development environment on the 3000; with Trandebug
being from my perspective almost the ideal debugger for a user
interface like QCTerm.
My guess is that it is unlikely that IMAGE will ever run to any
large extent (other than perhaps in R&D mode) on anything other
than MPE. If you buy that, the fact that Transact also only runs
on MPE adds no additional negatives.... and from the
performance, reliability, and simplicity point of view I believe
fully NM systems using TurboIMAGE - Transact - QCTerm
could blow the doors off any even semi-close-to-comparable
horsepower boxes running expensive bloatware (a.k.a. Oracle).
.... But to make the above a reality HP would of course have
to forgo that $50 per month from the remaining installed base;
and whatever compiler upgrade fees might still be collected...
In the famous words of Glenn Osaka way back at SIGRAPID-
89 in San Antonio: The zero-sum game again.. And even I will
admit it might not *quite* be time to bundle Transact yet: There
are just a "couple" more little enhancements we need to get HP
to implement; to bring Transact/iX to "final form".... Being able
to use variables for dataset and database names is my favorite;
I know Cecile has a couple; think Steve has a couple more....
will we ever get there ??.... don't know.... sigh....
SUMMARY: In the long run, it would be much, much better to
have a fully NM compiler / debugger like Transact / Trandebug
on every 3000 than CM BASIC/3000.... If we're never gonna
get that, then I hope "somebody" will SPLash! BASIC and do
what they can to remove CM limitations... If BASIC could be
made to accept longer variable names, just that would be a
huge step forward.. but for all I know that would require a
massive re-write of the whole compiler (the compiler gurus can
comment if they want; I am *way* out of my league here)...
Cecile just added:
> It's too bad HP isn't interested in marketing anything that
> might help sell more HP3000's.
To extend the life of Transact as much as reasonably possible,
one of two things seems to be required:
(1) Continue to enhance the Transact compiler on a long-
term basis; keeping it current with future IMAGE enhancements;
and do at least some marketing to a wider audience (I wish, but
like Cecile not holding my breath).
(2) (Hopefully) finish off at least a few more of the most useful
items on the SIGRAPID list..... and then bundle it.
If anyone thinks there are other positive avenues for Transact,
I'd like to hear them (don't both with listing the possible negative
outcomes: I already know what they are)...
Ken Sletten
|
