From: rpcfod@nimbus.worldbank.org (Robert Patt-Corner)
Subject: Driving a Terminal Session from Desktop
Followup-To: comp.sys.mac.programmer
Organization: The World Bank
Date: Sun, 3 Jan 1993 03:44:45 GMT

We've got an interesting application coming up, and I'd be grateful for any
thoughts by folks who have done or approached it...

There's a garden-variety VMS ORACLE database driven by an ugly VMS
SQL*FORMS application and a truly convoluted VMS SQL*MENUing system.  All
access is by Mac terminal emulation using Reflection 2+ by WRQ.  In due
time as decent tools become available we'll break out everything from the
forms on down in some sort of cross-platformable product on the Mac, but
for now waiting seems wise.

We would, however, like to break out those twisty menus in the short term. 
It's easy to hit a database from the Mac, but controlling VMS programs is
another matter.  Since Apple in its wisdom has not embraced DCE or any
other remote procedure call, we've written some homemade code that drives
DCL (and invokes programs and receives values) by means of the
ADSP<=>DECNet tool and a DECNet object, so controlling VMS programs is
feasible if ugly.

Given that, we can build a menu system on the Mac using Hypercard or most
anything else (let's assume Hypercard for simplicity), and we can fire up
the appropriate SQL*FORMS program.  Here comes the question now ...

How to best move the user to an interactive SQL*FORMS session and back to
the menu when done.  Our normal terminal emulator is Reflection2+.  So far,
ideas are:

1. Write some roll-your-own frontware, opening a terminal window from HC,
letting the user interact and closing it when done.  Who knows if you can
even do terminal stuff over AppleTalk/DECNet with our object, but we could
always fire up another connection under LAT.  Ugly and hard to maintain
tho, and I don't like the security implications.

2.	Fire up R2+ with AppleEvents (if it understands them) and drive it by
invoking R2 scripts with AppleEvents.  We've put this one out to WRQ for
contemplation.  They're not listed in the AERegistry though ...  I like
this one, but wonder about returning control.  Guess it could be in each
script.

3. Fire up R2+ and drive it from the VMS end ... the Menu program would
talk to a server we'd write on VMS who would control a child process
connected to the R2+ session.  Is it feasible?  How to communicate ... can
VMS mailboxes do this?  Is it wise?

4. Invest in some frontware tools like MacWorkstation or MitemView and
simply drive a hidden terminal session until it is needed.  We're missing
any kind of user experience with these tools, and would love to hear what's
out there, particularly regarding capability building a menu system. 
Philosophically I don't like frontware, but as a menu and not a forms
driver it might do ...

5.  Drive MacX by means of the HC program but from the VMS side.  This is
relatively easy ... an X-server is kind of designed to do the display work
needed here.  But we'd prefer not to give the users yet another terminal
learning experience, and there would be significant memory upgrade costs
... MacX is a hog.

Anyway, feedback on any or all of these approaches as well as relevant
experiences and opinions are gratefully solicited.  Probably mail is best
... unless there is more general interest in the subject than seems likely.

Thanks --

R.