Q & A Repository

Subject: Re: VS Web Server

Posted By: Thomas Junker
Date: 7/15/02 at 4:35 a.m.

In Response To: Re: VS Web Server (Thomas Junker)

Subject: Re: VS Web Server

Date: Mon, 27 Oct 1997 13:28:51 -0500

On 8 Oct 97 at 15:49, xxxx wrote:

> I would like to get more info on this.

I have no writeup yet. It is a WWW server written for and running on a Wang VS. The present version is a functional demo that supports a single TCP connection at a time. Since it is based on a state table mechanism it will move relatively easily into handling multiple connections.

Physical connection is by VS 802.3 LAN Controller. This is an IOC that occupies an IO slot in the VS cabinet. I'm using a 50V56B on a VS6230T. For large-cabinet VS systems you would use a 70V56 802.3 LAN IOC. Mine has a Thick/Thin Ethernet BNC connector right on the IOC. As far as I know the 70V56 has a 15-pin AUI connector for an AUI drop cable (the *original* fully standard 802.3). Connection to Ethernet is then by means of a transceiver for 10BaseT or 10Base5 or 10Base2. It's possible that newer 70V56s have a BNC -- I just don't know. In any case the connection of a VS to a LAN is quite simple.

The Wang system software required is VS TCP/IP 1.80, preferably *with* TCP/IP Services (ftp, inbound and outbound telnet, SMTP, echo server, etc.). WSN is a prerequisite for TCP/IP.

The VS Web Server is a set of VS programs that run in that environment to retrieve HTML, GIF, JPG and VS Print files at the request of desktop web browsers and to execute CGI programs on demand from those same desktops. More file types are on the way.

Security is provided by optional IP address filtering and by controlling how URLs map to VS volumes, libraries and files. This is pretty standard stuff for web servers regardless of platform.

For intranet service that's all you need. You provide the web pages and, if you wish, the CGI programs to provide application and database specific interface. CGI programs may be written in pretty much any high level language (as well as assembler, of course).

For public Internet connectivity it functions like any other server. The server sits on a LAN and the LAN provides routed access to and from the public Internet. This is exactly the way Internet Service Providers are configured.

My VS is connected through my PC to a dial connection to my ISP because the VS doesn't support dial PPP connections. My Win95 PC dials my ISP (where I do *not* yet have 24x7 service nor a dedicated IP address), gets its dynamic IP address, then automatically does IP mapping for services on Port 80 (WWW) to the private IP number of the VS on my LAN. For public access you would pipe your VS through to the Internet either through your own feed, if you have one, or through a dedicated ISDN or fractional T1 by means of something like an Ascend Pipeline 75 or better.

Retrieved files and executables all stored on the VS. There are no smoke or mirrors, no special tricks. I edit static HTML files on my PC and ftp them to the VS where they reside as 2024-char consecutive files. The server handles both 80-char Procedure format and vanilla 2024-char formats, allowing me to build HTML files directly by means of EDITOR, but it's really much more convenient to edit HTML on the PC.

I simply ftp the HTML and GIF files, in ASCII and binary modes respectively, from the PC to the VS, where they are retrieved by the VS Web Server just as would happen in a unix or NT server. This will probably change a bit before release due to the requirement of the server to know before reading a file how many bytes it contains. There will probably be a prep step to set up new files for retrieval, not unlike a file reorg.

Dynamic HTML is constructed by COBOL and/or BASIC programs (any VS language, really, that can use Common Language Environment calling conventions) called by the server when the URL syntax indicates that the target is an executable. Right now this is signified by the ".cgi" extension. In the future this will use the standard "cgi-bin" in the URL and be mapped that to the configured executable library by the server.

The PACE CGI program in the demo is a PACE HLI subroutine, presently 425 lines (it would be shorter but I like to lay things out vertically for source code readability). It receives a buffer from the server task, an index into the buffer, and its query string. It parses the query string, opens one or another PACE cursor and retrieves one or more data records, then STRINGs together the HTML and data to make the page you see on your screen..

The released product will contain an HTML interface layer that will allow the executable to pass its data fields and the name of an HTML template file to the interface layer, which will insert the data fields into the template. That way the PACE HLI or DMS COBOL that accesses the VS data will be completely free of HTML.

Come take a look at the demo. It's live, running on a genuine VS6230T. There are only two limitations: It's a single TCP connection demo, so you could conceivably collide with another visitor and have to try again, and it's not on line 24 hours a day.

The URL of the status page, the gateway to the demo, is:

[URL no longer valid]

If you have any questions please feel free to write me.

Regards,

Thomas Junker

Messages In This Thread

Q & A Repository is maintained by Thomas Junker with WebBBS 5.00.