[Info-vax] Accuweather new contract

[David Froble]

Jan-Erik Soderholm wrote:
> 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...

Not always ....

> 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.

I think so also.  What puzzles me is why more people aren't using the 
product.  One reason is the lack of support contracts for the product.

>> 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.

Jan-Erik, what am I to do with you ???

Perhaps YOU don't have to do any TCP/IP and socket work, but what do you 
think is at the bottom of WASD?  That's right, SOCKETS!  I've discussed 
some things with Mark Daniel, and he gave me some hints on how to pass a 
socket off to another process.  Something that I've yet to do, as other 
things got in the way.

As for using a bunch of "middleware", some of it I prefer to call 
"bloatware", making things much more complex, and slow.

What I've done is VERY fast.

It also allows us to do exactly what we want, without possibly having to 
jump through some hoops to get some middleware to fit our needs.

Perhaps the problems at AccuWeather is the use of such middleware and 
being able to get the desired through-put.  Don't know.  Would be 
interested in just what their problems are / were.

>> 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.

Your small attention span is showing.  We've had these discussions 
before, and I believe you're aware that we're not using a database with 
such capabilities.  Perhaps this is some of your sarcasm.

To directly answer your question, right now, losing all volumes of a 
shadow set (we use RAID 1) would cause us to lose data.  We're looking 
to make this more robust, and to implement being able to break out a 
shadow set for a BACKUP snapshot of the data without having applications 
down for an extended period of time.