I don't know how many 3000 users are in a position to benefit from our
experience at Capilano College, but fwiw here it is:

As longtime (since '75) users of the 3000, our applications were a mixture
of Image based C programs (originally SPL) running on terminal emulators and
ODBC Image/SQL Windows programs developed with Power Builder.  For some
time, we have wanted to become more platform independent.

We chose MS SQLServer (runs on Windows 2000).  Porting the Windows apps was
the easy part.  The hard part was the C programs with the many Image calls.
What we came up for them was a 4-tier solution:

1. Ttermpro - a VT100 type secure socket terminal emulator.  Since we didn't
use too many HP-specific terminal functions, the client part wasn't
difficult.  Fortunately, we had stopped using VPlus earlier.

2. We created an API for the C programs, with functions closely matching the
Image calls.  Image doesn't fit exactly with SQL, but we were able to come
pretty close.  The C programs used structs matching the layout of each
dataset; we were able to make these work for SQL.  As an example to give the
flavour:

In C, we had our own functions wrapping the Image calls.  A common
construction looked like

if (dbfind(base, "dsetname", "search itemname", (void *)value)) dberr(n);
while (1) {
   if (dbget(base, "destname", 5, "@ ", &structname))
   if (status.retval != EOCHAIN) dberr(n+1); else break;
   ------    processing here ---
}

This ported to:

if (SQLFind(base, "destname", "search itemname", (void*)value, "*",
"order-by field", &q))
 dberr(n);
while (1) {
   if (SQLGet(&q, &structname))
   if (status.retval != EOCHAIN) dberr(n+1); else break;
   ------    processing here ---
}

Ignoring some details, you can see how this can be done "blind".


The API passes the SQL to tier 3 via TCP/IP.  Actually, both tiers 2 and 3
run on the same Linux machine, but they could be on different machines.

3. A Java program accepts connections from tier 2 processes and communicates
with the database via JDBC.

4. the SQL Server database.

This sounds elaborate, but the C programs could be ported quite quickly and
almost mindlessly.  Performance was respectable, sometimes better than on
the 3000!  The performance could often be improved by using more intelligent
SQL (also possible in the C programs).

Users are now running this, apparently successfully.

Let me know if there are questions.

                              - Mike Freeman -

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *