As seen in Access to Wang, The Independent Magazine for Wang System users, January 1998
Article ©1998 New Media Productions
This manuscript ©1998 Thomas Junker
A Native VS Web Server
Thomas Junker
The thought of the Wang VS being a player in the TCP/IP world of the 1990s has only begun to get any real attention in the VS community. While Wang has had a native VS TCP/IP product in the field for years, many users are unaware of its existence, others are unsure how the VS may be connected to an IP network, while still others have been using VS TCP/IP but only in very limited scenarios such as a single daily file transfer or for a remote developer to log on using telnet. The fact that a full range of TCP/IP "socket" programming can be done in the VS environment has almost entirely escaped wide notice.
The appearance of the first native VS Web server, shown at InterACTION 97, ableit in demo form, has fired an interest in VS – TCP/IP connectivity that may have been brewing beneath the surface for some time, and for good reason. Almost everyone today understands at least something about the World Wide Web metaphor of accessing information on a host computer from a desktop running a widely-available "browser" program. Seeing a desktop computer retrieve Web pages from a VS system instantly collapses all the doubt and uncertainty about the ability of the VS to "play" on the intranet field. Seeing is believing, and the door opens to utilizing the VS in today’s network environments regardless of the details, because details are, after all, just details.
The point of a VS Web server is not, of course, to compete with off-the-shelf NT and unix servers in providing access to new databases. Managers of robust VS systems understand this immediately. Their challenges do not revolve around setting up new web servers but, rather, consist of solving the connectivity obstacles between their stable, existing VS databases and the rapidly evolving world of desktop PCs and networks. One of the points of a VS Web server is to overcome such obstacles by making it possible to communicate directly from the desktop to a generalized server running in the VS, and potentially thereby to any data resident in the VS.
Another point is the ability to achieve VS Web connectivity without having to surmount large purchasing obstacles in the face of uncertain results. VS managers continually grapple with the need to find ways to leverage the utility value of the VS in their environment while at the same time experiencing harsher scrutiny of VS-related expenditures, especially capital outlays, than almost any other part of the IT organization. While the network people may easily win approval for new gadgets and the client/server development people may have a blank check, the VS manager often must fight hard just to win approval for the basics to keep the system running, much less to add anything new to it.
Any promising technology that a VS manager can acquire or test drive without having to buy and set up additional boxes such as gateway PCs, without having to pay exorbitant license fees or contemplate high per-seat fees, is much more likely to be given a chance. A native VS Web server, then, offers several key benefits to the VS manager:
- It’s a VS program, and it connects through VS LAN IOC hardware
- It requires nothing more at the desktop than a functioning Web browser, which costs cheap-to-nothing
- It allows exploring the potential applications of VS Web service now, without regard to whether or not an ultimate application might be so large as to require a dedicated web server
- It allows the implementation of limited VS Web applications immediately, such as small departmental access to VS data
- It allows the VS manager to show upper management that the VS can make its data available to the desktop in a form that almost anyone can deal with using skills they already possess
There are several fundamental approaches to using a VS Web server to make VS data available. One is to develop programs that extract relatively static data and format Web pages in HTML, the language of Web documents. Users then retrieve the Web pages and view them at the desktop. No interaction takes place between users and existing VS applications or between users and live VS data.
Another approach is for users to view VS print files on the VS instead of printing them on paper. This has been pretty common practice in VS installations for years, but usually by means of DISPLAY or other utilities accessed via VS terminals or terminal emulation. It will now be possible to view print files directly from the desktop without logging on and without proprietary terminal emulation software.
A more robust approach is to write application-specific data access interface programs, called CGI (Common Gateway Interface) in the Web world. These programs piggy-back on the Web server infrastructure to extract application-specific data and format it for delivery by the server to the desktop. Data modification and update are also achievable by this means.
A less-obvious approach utilizes the Web server’s general facility of running specified VS programs on demand to create a client/server connection between a custom PC client program and VS programs designed to support the client. This enables a customer with good PC programming resources but limited VS programming resources to set up custom client/server applications that can be built without VS TCP/IP programming skills and can retain platform interoperability and portability because they utilize the same Web protocols that all Web servers use.
This is important: A VS Web server allows the creation of portable client/server applications using only application programming skills on the VS and current Winsock programming skills on the PC (largely pre-packaged these days in class libraries and OCXs). The PC client doesn’t care that it is a VS on the other end — tomorrow it could be something else and the client will function the same. The VS side is programmed using only application knowledge, because the Web server does all the TCP/IP work, so no extraordinary VS-specific throw-away programming is required there.
Further, in both of the last scenarios the VS application interface programs may be written without the burden of having to deal with extensive HTML formatting. In both the CGI and the custom client/server scenarios the VS customer code will make use of an HTML "merge" layer that merges the application data into predefined Web pages. The Web pages may be designed and maintained using conventional HTML tools such as Microsoft Front Page.
VS configuration issues are similarly straightforward. Large and small VS systems of the modern generations each accomodate a LAN IOC. The 70V56 is for large cabinets (VS300, 7000, 8000, 9000, 10000, 12000, 16000) while the 50V56 is for small cabinets (VS5000, 6000, 6230). Connection to an ethernet hub or router port is made by means of an inexpensive transceiver. Incidentally, the LAN IOC may also be used for WSN interconnection of VS systems over standard ethernet at the same time it is used for TCP/IP, providing an alternative and/or backup path for sites using CIUs.
The software required is VS TCP/IP and WSN. Most of today’s viable VS sites already use WSN and some already have LAN IOCs. Some also have TCP/IP. VS TCP/IP also supports X.25, which may be convenient for some sites.
Expect the Web server itself to be available in the first calendar quarter of 1998, with a possibility of beta and/or evaluation copies before final release.
—————
Thomas Junker is a VS software developer and consultant in Houston, Texas. His well-known Unofficial VS Information Center website is at www.tjunker.com/.