[Info-vax] Accuweather new contract

[Jan-Erik Soderholm]

David Froble skrev den 2015-03-28 19:52:
> Jess Goodman wrote:
>
>> "...bottlenecks and performance problems that were introduced when
>> the data had to be replicated..."  The obvious but unanswered
>> question is:  Why did this data have to be replicated in the first
>> place?  The answer: because there was no webserver for VMS that could
>> scale to anywhere near the performance capacity that AccuWeather
>> required.
>
> I see this as a problem resulting from the absurd idea of "free software".
> Once someone gets the idea of such, then the next step is "the price is
> right, make it work", and now you're limited to whatever someone will
> choose to implement, without pay, on their own time.
>
> Needless to say, that "free application" just might not be available in
> every environment.  Or when ported to another environment, might not work
> so well.
>
> I'd also wonder at just what "performance capacity" is required, or
> currently in use at for instance AccuWeather?  Why would the WASD web
> server not satisfy that demand?  Not saying it should, just asking where it
> might not.
>
> I don't use a web server.  One of my shortcomings, perhaps, perhaps not.
>   To me a web server is just a listener socket, accepting connection
> requests, with some capability to do something with some of the data sent
> by a client.  Perhaps over-simplified, but, that's what it does.

The big different is the way you present data to the user. Much better
ways to do that on a web browesr then on a VT-screen...

Then you have all the FORM processing going in within the webserver
before the applications sees the call. And other stuff...

>
> With sufficient specifications, I cannot see why a web server could not be
> implemented on VMS to satisfy any requirements.  Even a large cluster
> running multiple copies of the web server to meet the volume of connection
> requests.  (No, I haven't volunteered to write such.)

Why write another web server to do what WASD already does (well) ?
WASD is fully cluster-ready, as far as I know.

>
> Also, you cannot solve a problem, unless you know what the problem is. I'd
> be curious as to where and why VMS based web servers do not satisfy the
> requirements?
>
> The subject interests me because a cousin of the web server, a web service,
> has greatly influenced the applications he's working with.
>
> In the old days, people would sit at terminals, with phones, and takes
> customer orders over the phone.  (Dave shows his extreme age.)  We have
> implemented "web services" and a protocol to enable customers to submit
> orders computer-to-computer.  Again, basically a listener socket, with code
> to process specific requests from clients.

This is a simple implementation using WASD and a CGI app having WS/SOAP
interface. All networking from and to the clients goes through WASD.
I did this 5-6 years ago using WASD, gSOAP, some small C-stubs and
the usual Cobol application code to process the requests.

By using WASD, there is no TCPIP programming, all networking is
already handled by the standard WASD server. No sockets. Just
config an URL that points to the application. Standard port 80.

>
> We've been discussing how to set up things with more disaster tolerance.
>   There have been few problems in the past, but, things can always be made
> better.  Now, I was a bit confused with the "sudden" interest in disaster
> tolerance.  The question was, "what happens if we lose a day's work
> (orders)?"  I wondered what the problem was.  After all, we're selling a
> few lawn mower parts, how much could be lost?  A couple thousand dollars
> worth of orders?
>

What, more specificaly, could make you lose any transactions at all?
Doesn't your database has the actual data and the transaction log on
separate disks at least? Can a single disk volume failure make you
lose data? I hope not.