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:
1. It's a VS program, and it connects through VS LAN IOC
hardware
2. It requires nothing more at the desktop than a functioning
Web browser, which costs cheap-to-nothing
3. 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
4. It allows the implementation of limited VS Web applications
immediately, such as small departmental access to VS data
5. 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. He may be reached by email at
. His well-known Unofficial VS Information Center website is at www.tjunker.com/.