Return to the top of
this page.
Tropical CAUCUS '96
Software AG College and University Users Group
University of Texas Medical Branch
Galveston, Texas
April 28 - May 1, 1996
In reporting on the high client/server labor costs, the June 26, 1995 issue ComputerWorld sites the Gartner Group on the breakdown of the 5 year costs in a large enterprise client/server application . This included 41 percent end-user labor, 15 percent end-user support labor, 8 percent Application development labor, and 8 percent server operation/other labor. Can we trim these by reusing existing resources, standardizing the client interface, and reducing the client side software development whenever possible? I think so.
If you are not yet prepared to reinvent every system currently in production but need to provide WWW access to real production data, then our answer will be of interest. This paper will examine a cost effective way of providing the desired access.
A hypertext version of this document with links to real time examples is available via the Web at http://www.udel.edu/ud/sag9604/caucus.html
For additional back ground please refer to http://www.mis.udel.edu/tcpintro.html
Return to the top of
this page.
Instead of generating query databases and extracts that need to be rebuilt and transferred to some server every time the data changes, we use Natural subprograms to generate the requested information directly from our MVS production ADABAS files. The power of HTML forms coupled with the frames, client pull, cookies, and Javascript features of Netscape v2.0 combine to allow meaningful applications to be delivered over the Web. Programmers writing MVS Natural routines can provide screens with embedded links, pull down windows, radio buttons, checkboxes, images, data validation, and edit table lookup as part of a growing list of GUI features.
The Netscape SSL server used to handle encryption and between the client and server runs on a Unix system. By routing through a Common Gateway Interface (cgi) we forward requests to one of the MVS servers, and then pass the response back to the Netscape server to be encrypted and sent to the client.
Return to the top of
this page.
HTTP has the capability to transfer complex data types using Multipurpose Internet Mail Extensions (MIME) headers and this allows us to do hypermedia. Communication between HTTP servers and other software is managed by the Common Gateway Interface (CGI) mechanism. CGI uses the Unix concept of Standard In (STDIN) and Standard Out (STDOUT) to pass the request data to a Practical Extraction and Report Language (PERL) or C program and receive the response.
MOSAIC (the original http browser), was created by the National Center for Supercomputer Applications (NCSA) located at the University of Illinois at Urbana-Champaign. This software provided an easy GUI interface to the HTTP world. Today many WWW viewers are commerically available. For the U of D, NETSCAPE with the Secure Socket Layer (SSL) handshaking and encryption has made client/server applications via the internet possible.
The ability to provide selected production database information to anyone with internet access opens a whole new level of service. The ability to mix multimedia with traditional data on the same device (PC,MAC,Worksation) gives a new look and feel to our new services. And if you believe the nightly news, providing services is the growth sector for the 1990's in the U.S.A.
Return to the top of
this page.
What we found out is that any application that depends on sending multiple requests across any network will not be very efficient. Many others have come to the same conclusion. The popular RDBMS concepts of stored procedures and triggers are an effort to reduce network traffic and associated delays.
Running the same Natural program against local Unix files and files on MVS revealed that when reading logically by a key the local read time was averaging about 4 milliseconds but the same read across the network took about 45 milliseconds on a good day.
This lead us to believe that we needed to create something that would work like a stored procedure and be available via TCP/IP. Natural routines could easily handle the database part, so what was really needed was a generalized Natural to TCP/IP interface to handle Gopher (and later HTTP) requests.
Return to the top of
this page.
To aid in testing, a Natural TCP/IP client interface was also developed. As a bonus this would allow the Natural server to also be a client to the Simple Mail Transport Protocol (SMTP) port and directly generate Email to any machine which could receive mail from the internet.
The routines NATSVAL (server) and NATCLI (client) were first developed on a Sun Unix box to take advantage of the FORK system call. This call clones the parent process and allows the child process to handle the request while the parent process goes back to listening to the master port. When the child is done servicing the request it terminates.
The code was migrated to MVS providing the same functionality on both platforms. The FORK function was not available on MVS so the code had to be modified slightly. Both NATSVAL and NATCLI have been kept as simple as possible to allow the application logic to be placed in the Natural code.
Return to the top of
this page.
|User's PC| --- TCP/IP ------- THE NETWORK ------ TCP/IP
|client | routines routines
|session | on client on Host
|
v
Natural ---------- Natural main ----- NATSVAL interface
service subprogram program in C
| | | | |
| v | | -------------------------------- |
| local |
| ADABAS |
V |
local |
Net-Work |
| V
| NATCLI ----- TCP/IP ------- "other"
| interface routines servers
v
remote Net-Work ---- remote ADABAS
"Normal" processing would be for the subprogram to return to the
main program and then main would send the reply. If the reply is
more than 4080 characters, the subprogram would make multiple calls
to NATSVAL until the last send was reached, then it returns to the
main program which does the last send. The service subprogram can also communicate with other servers via NATCLI. For example, MFU8006 generates a HTML form, receives POSTed data from our client, sends a response to the client, and acts as a client to SMTP as it mails the information.
Return to the top of
this page.
The Gopher clients were modified to look for certain queries to trigger a request for SSN and PIN. Once entered and encrypted, they are sent to the Natural server to be decrypted and checked against the SSN/PIN stored in the production database. The server routine then creates the requested data and passes it back to the client.
In 1995 we changed from modifying the client to using the setup features to invoke our YOU-VIEW module as a helper application for files with "ud1" as the last qualifier.
Even though our development has moved on to using HTML documents, the Gopher access is still used and supported. Some sample screens from the GOPHER SIS system:
Return to the top of
this page.
The use of Hyper Text Markup Language (HTML) to create documents with embedded images and links is the key attraction. With HTML pieces of a document can reside on several different servers with only the Uniform Resource Locators (URLs) references actually being in the main text. As long as the name and location remain unchanged, the pieces can be revised at will without any kind of total reconstruction or relinking required.
Is the inexpensive, universal client here now? By using the FORMS feature of HTML we have available a thin, cheap client that can do blinking fields, check boxes, horizonal rules, lists, radio buttons, pull down windows, text areas, images and merge the various sources at the client machine.
We don't even have to take a course or buy a book to learn about HTML and how CGI works. There are several online tutorials available at various WWW sites which will supply a good working knowledge. To name a few:
Prior to resolving the security issue only "unsecured" functions were in production at our site. A prime example is that anyone anywhere can, via the Web, fill out an admission's application to the University of Delaware. The data are transmitted to a Natural server capable of dealing with GET and POST commands from a http client. After the Natural routine extracts the data, it is recorded in the ADABAS database and notification Emailed to the appropriate person.
Return to the top of
this page.
When we have messages going between machines on the same TCP/IP subnet, then the messages should never leave that subnet. If a Netscape server and MVS were on the same subnet in a secure location, they could talk in clear text. The less expensive system could do handshakes, authentication, and decryption before forwarding a request to MVS or another server. On the return trip the data would be encrypted and sent to the client.
Netscape Communication Corp. produces web viewers and servers that incorporate a security protocol called SSL. This protocol involves multiple exchanges of authentication data and public encryption keys. Details are available via the internet at www.netscape.com/info/security-doc.html.
The SSL server receives a request and uses a CGI program containing a modified version of NATCLI to forward the request to one of the Natural based servers on MVS.
This offloads the CPU cycles for handshaking, encryption, and decryption to the less expensive machine without using extracts or replication of production data. To see some public demos just click here.
Return to the top of
this page.
When invoked from a Netscape client via a request like, "https://www.mvs.udel.edu/cgis/sslmvs.cgi/udmt1/mfu9001/x.html", the part after the "sslmvs.cgi/" is of greatest interest. This "PATH_INFO" is passed to sslmvs.cgi when it is invoked. Additional information may also be passed via Unix standard in (STDIN) read statements. The "udmt1" tells us which Natural server is to receive the request for subprogram "mfu9001" to be executed.
In the case of "udht1" and "udhp1" there are multiple servers available on MVS that are capable of producing a response. See the diagram on the next page for more on the rotary selection. A modified version of NATCLI is called to do the communication with the Natural server and a locally defined header is inserted to make it appear as a direct request from a WWW client. This includes a MIME header and information on the original source of the request. As the data is received, it is passed back to the Netscape server via Unix standard out (STDOUT) using printf statements.
This technique uses no intermediate files to pass data. This is much more efficient than having the CGI program invoke some other service that would create a file, and write to it. Since it would then be required to open the file, read, close, and finally delete it.
The use of STDOUT is a slight problem during the debugging of the routines because it forces us to direct our debug write statements to a disk file to avoid having the Netscape server intercept them as returned information.
Return to the top of
this page.
Netscape -- Netscape
Client SSL Server
|
lock process 1 M Natsval -- Main -- Response
file 1 sslmvs.cgi --- V -- server 1 Prog subprog
| S
lock process 2 Natsval -- Main -- Response
file 2 sslmvs.cgi --- T -- server 2 Prog subprog
. . C .
. . P .
. . / .
lock process n I Natsval -- Main -- Response
file n sslmvs.cgi --- P -- server n Prog subprog
When the Netscape server starts up it creates multiple processes each of which can handle a request. Each process can run a copy of sslmvs.cgi if it is referenced in the request. For example: http://www.mis.udel.edu/cgis/sslmvs.cgi/udht1/xxxxxx/x.html
There are multiple servers running on MVS with the logical name of udht1 but they are listening to different port numbers. The sslmvs.cgi routine is located in the cgis directory and uses lock files to keeps track of which servers are busy. Once an available server has been selected/locked and the TCP/IP connect has been successful, the request is forwarded to the target machine. If either the lock or the connect fails, we go on to the next server on the rotary and repeat the process.
When the response has been returned from MVS, the data is passed to the Netscape server and the locked file is released. The server encrypts the data and sends it to the client.
Return to the top of
this page.
Currently Java requires Windows 95, Windows NT, or a workstation and you will need a 16meg Pentium to get half-way decent response. A high speed connection will also be required to handle all the downloading required when the applet is invoked.
Currently I feel Javascript is better. It is simpler to code, can run on Windows v3.1, Mac, Windows 95, Windows NT, or a Workstation (still requires Netscape v2.0 or later), and is faster for most simple business type tasks. Since the Javascript can be sent along with the rest of your HTML, it will usually get there sooner. By examining the MFU8045 example we can see Javascript doing arithmetic and moving data between frames. The Javascript and part of the HTML is being read from PDS members that would be copied into production libraries when the Natural subprogram is turned over to Quality Assurance.
You may also view the MFU8045 screen without running the application.
The real guideline is DO NOT DO SOMETHING JUST BECAUSE YOU CAN DO IT, DO WHAT SHOULD BE DONE. If the business need justifies Java code create it and use it, otherwise stick with HTML forms and maybe a dash of Javascript.
Return to the top of
this page.
Frames are sub-windows within a single document. One key advantage is the definition of variables which can be used to exchanges information between the frames. In the MFU8045 example, we have defined two frames. The smaller frame is used to supply drill down information and as a table lookup area.
This example allows drill down by clicking on the employee name and will display the information in the smaller secondary frame. A more interesting feature is the ability to replace the employee's city field by selecting the replacement value from a table.
To do table lookup and field replacement, we first click on the city field in the primary frame. The Javascript code captures the index of our selection. We then go to the table lookup frame and click on the replacement city. The Javascript moves the city name into a variable. By returning to the primary frame and moving our focus to any other field, the saved city index allows us to replace the city entry we originally selected. This uses a combination of ONFOCUS and ONCHANGE options when defining the INPUT areas in the HTML form part of the document.
Return to the top of
this page.
SCRIPT LANGUAGE="JavaScript"
// **
// java subscripts start at zero not 1
// index1 and chngcity are global to multiple functions
index1 = 0 ;
chngcity = " " ;
//**
function window2x(form,index) {
var i = -1 ;
index1 = i + index ; (which line in frame1)
// alert (chngcity) ; (commented out display of the value)
if (chngcity != " ") {
form.cityy[index1].value = chngcity;
chngcity = " " ; }
form.cityy[index1].value = frame2.form.Ccity.value ;
}
The following Javascript and table definition are from the table lookup frame2.
SCRIPT LANGUAGE="JavaScript"
function window2(form,index2) {
var i = -1 ; (adjust for origin zero)
indexx = i + index2 ; (which line in city table)
parent.frame1.chngcity = (points back to primary frame)
form.cityc[indexx].value ;
} This is the table definition and the first row of the table.
FORM NAME="CityChange" TARGET=_parent TABLE border=2 cellpadding=2 cellspacing=2> TR TH width=35%>City Name /TH TH width=10%>State /TH TH width=20%>Country /TH TH width=20%>Code /TH /TR TR TD INPUT TYPE="BUTTON" NAME="cityc" VALUE="Newark" ONCLICK="window2(this.form,001)" /TD TD INPUT TYPE="BUTTON" NAME="statc" VALUE="DE" ONCLICK="window2(this.form,001)" /TD TD INPUT TYPE="BUTTON" NAME="counc" VALUE="USA" ONCLICK="window2(this.form,001)" /TD TD INPUT TYPE="BUTTON" NAME="codec" /TR /table
Return to the top of
this page.
In our example MFU8050, we generate tab delimited data for input to either NOTEPAD or an EXCEL spreadsheet. Prior to executing the download, the client must define a helper with the MIME type "application", a subtype of "x-tab-excel", an extension of "xls" and point at the executable for EXCEL. When the file is received, Netscape will start EXCEL and feed the data into it. This is very similar to the Entire Connection / SuperNatural interface we have used for years.
Tabs are placed between the data for each cell in a spreadsheet row. A carriage return followed by a line feed (EBCDIC hex '0D15' in MVS Natural) marks the end of the row. The cells may contain formulas, text, or numerical data. In the example, the last cell in each row contains a formula for the row total and the last cell in each column contains a formula for the column total.
The real application of this technique contains multiple selection criteria used in retrieving the ADABAS data which populates the tab delimited fields.
Return to the top of
this page.
Return to the top of
this page.
Do we need to totally re-engineer applications and expend resources converting Cobol and Natural programmers, if all we really want to do is provide additional access routes?
Do we need to write, debug, and maintain client code in C++ or Java to provide a workable client interface?
Do we need to use up resources running and rerunning extracts and downloads in an effort to keep them current?
Is intranet/internet computing a quick and inexpensive road into the presentation benefits of Client/Server?
More questions than answers? Maybe not. I think what we have presented is a way to get some more good mileage out of our existing resources. We do not have to choose between very large expenditures and winding up as road kill on the information superhighway.
Surely this is not an answer to all Client/Server needs, but with some ingenuity we have received a good return on the time and money invested.
Departmental data and standalone systems seldom stay that way in a large enterprise. It is very easy to say yes to many small solutions that may require major effort to integrate later. BE FORWARD THINKING, but as history repeats itself, do not repeat the mistakes of the past.
Return to the top of
this page.
Last Updated: Tuesday, 23-Apr-96 16:39:41
URL: http://www.udel.edu/ud/sag9604/caucus.html