This is a revision of the original freeware release read-this-first (version 3.1). Little has changed. I quote from that document:
`` This read this first is a quick ``throw-together'' providing an introduction and some guidance for support external to WASD. It does not pretend to be as exhaustive as is necessary, but hey I'm not getting paid for this :^) ''
This revision and it's associated documentation is still thrown-together, at the last minute and with even less time than before. If this sounds like an apology, it's not meant to ... well not exactly. I would still prefer that it be better packaged, but it's not, and it doesn't look like it's going to happen that way. So if you have to struggle a little with it then I'm sorry, because I don't like my jobs to be harder than they might be, but that's way this one is! Look on the optimistic side, it might (and has) worked the way you wanted (or at all) the first time!
These releases are derived from our working Web environment. I'm afraid
this is getting a little cluttered with ``junk'' files ... dead-end
software development, other Web-related freeware packages, Perl scripts, etc.
I have tried to cull this as best I can but suspect there are still some
lurking. Apologies!
Some Background
The implementation of the internal hypertext environment started off as a Divisional management action-item, ``make it easier to access information-systems-based documentation and other data in a multi-platform environment''. Gopher was a first and brief stop, just as the power of the WWW technologies was becoming obvious (mid 1994). Like many others, I became impressed with the potential to integrate disparate data formats and platforms with the ease of the point-and-click functionality of the browser.
After evaluating the CERN (live) and an early OSU DEC-threads (by documentation) servers I decided some of the limitations and other idiosyncracies of these warranted investing a little in our own (how's that for hubris!) The upshot was that although the Divison provided core time and justification for development and implementation of this environment, I spent considerable of my own time on the package as well. The HTTPd server's multi-threading is done using VMS ASTs, and this is by far the largest AST-driven system I have designed and built. In short, I found it a challenge, I learned a remarkable amount (particularly about VMS' ASTs), and gained a great deal of satisfaction from it. I hope its of some use to someone out there other than us.
Without apology, the server and its environment has been designed to
support an intra-organisational (the industry has now settled on the term
Intranet) hypertext environment and has been tailored to
the requirements of the Wide Area Surveillance Divison and its VMS environment.
Any other usefulness is purely coincidental! All this not-with-standing, it
should prove useful in the broader context. As mentioned above, it is not a
commercial-grade product so a little fiddling and experimentation may be
required (of course none of us have had to fiddle around commercial packages
either!)
Documentation
Some documentation is provided, but again this is mainly for internal, Divisional support purposes. If external readers find it useful then that's a bonus! It is basically unaltered from its original, internal purpose, apart from more extensive author contact information, the copyright notices, and some small disclaimers in the introductions.
See the [.DOC] directory. You should find HTML, Bookreader (and HyperReader), plain-text and PostScript versions (all generated from SDML sources using DEC Document and the SDM2HTM application found in this package).
The ``Proceedings of the Twenty-Fifth Annual DECUS Australia
Symposium, 1995'' contain a paper by the author summarising a presentation made
during that event, titled ``Introduction to World Wide Web Technologies
... what the surfboard is made from''. Even though now (1997)
every man and his dog can recite the Litany Of The Web I have taken the
liberty of including it for informational purposes, in PostScript format,
in the
[.DOC]
directory. It documents some of the uses WASD (HFRD) has made of the
hypertext environment from late 1994, and although the technology content
is now (mid 1997) definitely getting dated it could still be useful if only
for historical purposes!
WASD HTTPd Has Spread It's Wings!
The WASD server supports Digital TCP/IP Services (UCX) with a native image.
As of v4.3, and using the excellent MadGoat Software NETLIB package, this server can also (potentially) support
NETLIB requires VAX/VMS v5.2 or later, or OpenVMS Alpha v1.5 or later.
NETLIB must be obtained and installed separately. This is not a difficult job for there is an excellent VMSINSTAL-driven installation and configuration.
The WASD NETLIB support was developed using v2.1, which may be obtained from
http://www.madgoat.com/netlib.html
The NETLIB support within the WASD server is tested in-house using the
Digital TCP/IP Services package via NETLIB. Other TCP/IP packages may or may
not perform as tested.
Swan-Song ... Prospects
With the advent of good commercial HTTP servers for VMS the need for a package such as this diminishes somewhat.
My role with respect to VMS is currently undergoing some change, as is the role of VMS within IT. Certainly I will have much less to do with VMS in the future. Whether VMS has much less to do within IT seems likely but has not yet culminated.
In either case, this package will probably continue to undergo some further development. Bugs will still be addressed and there may be some tinkering around the edges, but more spare time must be spent elsewhere. The package has been good to me over the last three years, teaching a great deal more about VMS, and the C Programming Language, and multi-threaded code. The package has proved to be invaluable in our VMS environment, and continues providing the backbone of our Web environment.
A major revision and improvement under v4.2 was made to the DCL module.
This provides some SSI functionality but more importantly CGI scripting. The
scripting mechanism has been redesigned to support persistant-subprocesses.
This improves script response time (200-300%) and significantly reduces the
system impact. In addition, the development of CGIplus provides the capability
to enhance CGI scripting, and further improve response latency (another
200-300%). This is documented in the technical overview.
Feedback
It would be interesting to know who is using what parts of this package and where. If you find it of use could you please make a moment to drop an e-mail (or even snail-mail) listing:
This information will be confidential. I may use it to feedback to you any monumental changes in the package :^) With thanks.