During a symposium in San Francisco I met some developers from a Canadian non-profit conservation organization who taught me how to connect Natural programs to the web without using middleware.
Their story began about 5 years ago. Their users were pressuring them across Canada for a GUI interface - no one wanted the 3270 "green" screen. Also they had written DOS application that was distributed to volunteers and now the volunteers were asking for a Windows version. What they did have was a VM/ESA mainframe and a lot of Natural and Construct expertise. Their solution was to adhere to a basic principle of not allowing fracturing of the database. They had been playing with writing some Natural programs that read their ADABAS database and produced work files containing HTML. They ran these jobs nightly and downloaded them to their NT Web server. When they upgraded their VM/ESA operating system they had heard about a "shareware" mainframe based Web server (WebShare for VM). They installed this Web server and have since upgraded to a commercial product EnterpriseWeb from Beyond Software (recently bought by Neon Systems). Now, their Web server and database are on the same platform (they got rid of the NT Web server). After a lot of work and growing pains they now have a very productive tool set to develop browser-based applications.
Surprisingly for me, the developers pointed out a way to connect to the web without using middleware and without using a TP monitor. We discussed in detail their solution, and back in Los Angeles I had to try this solution, of course. And the results met all my expectations. For me the starting point was Natural version 2.2.8 and ADABAS version 5.2. It works with other versions too, because the solution is version independent. The question came up, how can a Natural program receive requests from the web and return ADABAS data. Since the solution should work without using a TP monitor, a web browser replaced its function. This is very inexpensive, needs very little maintenance, and the newest software (Netscape or Internet Explorer) can be downloaded from the web.
Natural cannot communicate directly with a web browser. Therefore, I had to create a common gateway interface (CGI). I used a REXX procedure because the programs run on a mainframe platform. I found some CGI examples in the IBM Redbooks and it took a while to figure out the necessary job control statements for OS/390. Users from the Internet List Server SAG-L supported me with helpful examples.
Basically it works like this: A single CGI (the REXX procedure) receives a request from the web via a web server. Fortunately, for my solution on the mainframe a web server already was available, WebSphere from IBM. Check your system to see if you have it installed. Originally, it was bundled with other products.
Then the CGI writes parameter to work file 1 (for example Natural program and start value) and invokes a batch session in Natural. Natural starts up and reads work file 1 containing parameters from the HTML post. Natural executes the requested program to get ADABAS data and writes it together with HTML code to a second work file. After that, Natural terminates and then the CGI passes the HTML work file back to the users browser session. At this time, I had a good understanding about the CGI and the Natural programs.
Let’s return back to the communication with the web. How do you call the CGI from the web and how does it send back information? In HTML code a 'form' command includes the address (URL) of the CGI script that will process the form; describes the method how to pass information (GET or POST); includes the form elements, like fields and menus; and the submit button which sends the data to the CGI script on the server.
If the form receives the fields 'selection type' (type), 'first name' (first), 'last name' (last), and 'e-mail address' (email) then the HTML code with the GET method looks like this, for example:
The CGI receives the parameters and parses the single fields.
PARSE VAR TYPE FIRST LAST EMAIL
Now, all of the development of the Canadian organization is browser based. Most of their applications are for staff only and run in their Intranet. A few applications are written for the general public and delivered over the Internet. Their applications have a GUI front-end and are very intuitive to use. Like you, they have new staff who understand windows applications and need little training since they are already used to drop down menus, radio buttons, etc. As a developer, the applications you can deliver are very different from the 3270 interface you are used to. You now have color, sound, and pictures available. Since a Natural program is writing the HTML, you can change the look of the "screen" depending on the user - much easier then trying to play with control variables. You can (and will) make extensive uses of hyperlinks.
For example, you show the user an expense total. Create a hyperlink on it and with one click the user can see the details that made up the total.
Let me point out some remarkable facts.
The applications are all written in Natural on the mainframe. Need to make a program change? Change the program, re-stow and move into production. Next person to access the program gets the new version. There is no client side code (other than a copy of Internet Explorer or Netscape). Using Web browsers as your user interface frees you from the software distribution problems and drastically reduces the reliability and performance issues.
The mainframe Web server is fast and handles hundreds of users with no problem.
All of the data is stored in ADABAS but I see no reason why this would not work with DB2 and Natural. Yes, it is Natural, a 4th generation language. Also you keep and exploit your own Natural experience and expertise.
Robustness is a very important point and one many people underestimated. And at this time, you cannot beat the mainframe.
Just another way to connect Natural and Adabas to the web?
Try it and figure out how simple it can be!