At 07:24 AM 1/26/95, Glenn Cole wrote:
>Eric --
>Incidentally, regarding the 4k points of remote access: Is this via dial-up
>line? Campus-wide network to offices and dorm rooms? I believe your original
>post mentioned supporting Unix machines, PC-compatible, and Macs.
>
Glen,
 
  Hope you don't mind if I post this to HP3000-l.  I think a lot of people
are asking the same questions....
 
  Yes, we have an array of dial ups for off campus access, but we installed
a campus wide network using fiber backbone and routers to most buildings,
giving 4,000 network connected machines of all types (uses FDDI ring).  We
are installing 6,000 jacks in the dorms so that students can have access
from their PC's directly;  presently they must dial in from the dorm or off
campus, or visit a public campus computer cluster.
 
We have an internet license and high speed internet connection for off
campus traffic.
 
  Ok, how can you put HP corporate data on thousands of desktops of such a
diverse array of platforms?  and OS/2 coming on board?
 
  Before I answer, another thing is at stake here.  The design of our
client/server follows "smart server - dumb client" approach.  Think about
this, if you had business rules on the desk top and access through SQL, how
would you prevent someone from fudging and getting access to stuff you don't
want them to have access to?  Security passwords! how are these transmitted
? clear text!  not to mention a full time position to alter passwords on a
day to day basis.  to ugly to think about...
 
  What about version control?  think about servers needed to download all
these neat desktop apps when they change?  Ok, I have a Mac, a Next, etc..
Damn, another big headache.
 
  All desktops are not created equal.  How do you deliver to the lowest
common system?  What is your cut off line?  How much money for how long will
your investment return?
 
  The answer to that question is the primary reason we have high volume -
high access stuff in gopher.  Why?  Because gopher is simple.  Gopher was
first.  Gopher runs on trashy 286 DOS machines with 512K memory.  We are
phasing in the Web because a lot of stuff won't run the Web yet.  This stuff
takes a period of time.
 
  Speaking of the Web, Now, what if you stick a Web client on the desktop
that displays data in graphical form and looks nice, but all rules about how
the display is constructed are on the server (smart server)?  This is what
World Wide Web is all about.  The server can build screens and forms and the
client does nothing more than display and return data (the x window
concept)-- gee, like VPLUS but open to the world!
 
  But oh, no.  The Web is stateless.  This means a new way of looking at a
transaction. How do you do an update?
 
  When the server sends a form to fill in or change, you must include path
information on the form so you can re-establish file / data base position.
You can even go for chance and stick a record number of a detail set on the
form, parse the detail number on the return fields and check to see if
things match the path info.  If a match, then update.  Chances are that
99.9% of the time a record number to a detail will do it.  Masters are
simple, embed a search item.
 
Ok, what is gained and what is lost?
 
The minus:  You do 1 extra DBOPEN, 1 extra DBGET, when compared to a
stateful terminal transaction for the first transaction.  A second
transaction for the same user - well now you do 2 extra DBOPENS and DBGETS
(send a form / receive a form), because a stateful connection would still
have the stuff open.
 
Oh, yes.  I method to identify the user.  Web authentication can do that
with an environment variable.
 
If you think this method is new...how about this story?
---
If there are any older IBMer's out there, my wife programmed a system IMS-DC
that worked the same as this Web update (in theory).  IMS-DC in the early
70's scaled corporate transactions by stateless means:
 
 IMS app starts, sends screen to TN3270,
 IMS App terminates, small communication area saved by a manager.
 
Ok, at this point, nothing is taking up resources or memory on the
mainframe. The program that sent the screen is terminated - memory is freed.
But heck, the screen is sitting there, it looks like a stateful connection.
 
 Now, after the IBM data entry clerk pushed <enter> this happened:
 
 IMS app restarts, communication area sent to program,
 IMS app must re-establish the IMS data base position based on fields
delivered back in the communication area buffer,
 IMS app does update, or whatever - sends new screen with message.
 
Back to termination state again.  Nothing executing except that screen is
there waiting for the next transaction input.  But the communication manager
is keeping track of user logon and security access.  Same thing can be
programmed into Web updates (using Web authentication), over a network.
 
This stuff is OLD in concept, comes in a new wrapper.
 
 
The gains - how much elapsed time is there between the point you send a form
and the data returned?  that machine resources are free to do other stuff?
1 minute? 5 minutes? 1 hour?  You can see for casual use that the time will
be long.  Slam dunk terminal entry, nahhhh.  maybe too much.
 
I keep reading stuff in InterexPress that Client/server is costly and
such...yes, to replace data terminal entry.  But for read only and casual
update - we are doing it big scale for almost nothing (the campus network
hardware cost is not ours to worry about, just the delivery of data to the
network).
 
And speaking of cost, to be fair, internet software (gopher, WWW) is free to
use for educational and research gov on the internet.  I never looked into
the hoops that commercial vendors must jump through to gain access to this
stuff.  Maybe someone can shed some light?
 
This could be the rest of the story....
--------------------------------------------------------------------
Eric J. Schubert                 Administrative Information Services
Senior Data Base Analyst         University of Notre Dame, IN USA