Re: Banana Republic (was Re: OpenVMS Book Wins award)

Hi Mark,

"Mark Daniel" <mark.daniel@xxxxxxxxxx> wrote in message
news:0150d6c5$0$23675$c3e8da3@xxxxxxxxxxxxxxxxxxxx

The days of significant monolithic shops are well-and-truly over.

Yeah, I haven't seen or even heard of one in a long long time!

It *would* be interesting to know how many VMS shops are using any of
these middlewares in anger.

Interesting indeed! But such information, and other ROI metrics, are the
sole concern of the HP/VMS Ministry of Truth and Customer Feedback. Do rest
assured that the decisions being taken are the right ones, and do not
concern yourself with who gets to hold the conch on this pathetic Lord of
the Flies remake as it is none of your damned business. Honestly, your
obsessive interest in the size of the installed-base is no concern of
theirs :-)

But when it comes to middleware, one thing I expect we can all agree on
(and certainly you with your years of web-server work) is that *no one wants
to install more software on the client!!!* Look at what Adobe does with the
Flash-Player (also see the code automatically generated by FlexBuilder), and
now JAVA Applets can be deployed just like web-start applications, and
obviously the browsers spend much of their days downloading new versions
of themselves. (Let's also give a mention to Ajax and down the road HTML5
and, if you have to, that JDBC thin-client thing)

All of these technologies designed to facilitate the loading of the current
version of your application and its infrastructure-code at run-time. Yet
HP/VMS sees nothing wrong with prohibiting the run-time discovery of clients
and having to install/upgrade software the old-fashioned way? Maybe they
know best? Then again they also see nothing wrong in perpetuating the
bollocks <65KB ACMS workspace limit, which does appear strange in 2009.

But what's happening in the rest of the world, outside the isolated little
island that is VMS? Well: -
1) SUN/JAVA/Applets have supported Sockets for many years and have recently
introduced Policy File support for cross-domain access.
2) Adobe/Flex also with long-term TCP/IP Socket support is standardizing
policy-files and looking to support UDP.
3) Microsoft/Silverlight has just introduced Socket support
4) HTML5 is looking to introduce WebSocket support natively (if they ever
stop floundering)

So here we have the formidible line-up of SUN, Adobe, Microsoft, Tier3, and
the HTML5-people, all acknowledging the very real benefits of being able to
talk to your servers via standard and unbridled binary Socket interaction,
yet the DEC/Compaq/HP illumni, cognescente, and intellectual giants, that it
has been my great misfortune to converse with over the past 12 years,
maintain "No one would ever want to do that! They'd rather use my baby of a
pet project instead". And yes ladies and gentlemen, this was all before they
proceeded to waste a decade of opportunity, and millions of dollars on
BridgeWorks [to be replaced by] the Waste of Substantial Investment in
Technology (WSIT), [to be replaced (augmented?) by] gSOAP [to be replaced
by] . . .GlassFish? . . . VMS-Clouds?

Anyway, for those of you, and blind Freddy, who can see the sense in what
SUN, Adobe, Microsoft, and Tier3 are doing, let me remind you of what
infrastructure you may be looking for on your VMS servers once you start
hitting the wall with your INETd configuration: -

- Transparent Multi-Threading and Network interaction (TCP/IP or DECnet)
- Application-Based Tuning and configuration
- Persistent Network Connection
- Unbridled, full-duplex binary stream communication
- VMS Authentication and client persona availability
- Transactional Data Integrity.
- Server-affinity and transaction-duration under application control
- Execution Server Processes re-usable on a transactional basis
- Preservation of Existing Investment (All you need to provide is a
shareable image with just 6 routines)
- No need for Java and its Garbage Collector, Apache, WASD, OSU, WSIT,
BridgeWorks, SOAP/Toolkit, Axis2, PHP, Perl, Python, CGI. Just the raw VMS
grunt you know and love with your rich herritage of 3GLs, businees rules,
and data, opened up to *any* client interface (Web-based or not).

Look, my contention has been that the most common middleware in use on VMS
is FTP and ODBC. Not necessarily out of choice, but due the historical and
woeful lack of viable *integration* options. Customers have simply been
forced to serve-up their VMS data to more usable platforms, as projects to
modernize or integrate existing VMS applications, using HP/VMS recommended
technology, commonly suffer from cost blow-out and/or catastrophic failure.
Again, I am happy to be proved wrong.

But where are the VMS Web Development Tutorials? Where are the hands-on
examples on the WEB, or TestDrive Cluster? We've had two examples on the web
for some time, you've got one ready to go, JFP also has a pearler, and I'm
just wondering what our combined budget is? Is HP/VMS really waiting for the
first dozen or so guinea-pig customers before they can work out what they
should be doing? 15 years into the web, they're still flipped over on the
beach, their wee flippers flailing maddly in the air with green-screens and
FTP :-( Go look at the Adobe or SUN websites if you want to see examples of
companies that are really trying to get you to use their products!

Having said that, I am reluctant to ask for more examples, or anything more
from HP/VMS, as I fear the work will simply be doled out to one of the many
cynical, self-serving, barrow-pushing, bastards that have, for the last 20
years, managed to hide from the real-world in the sheltered workshop that
has been HP/VMS.

but what did happen to Bob?

Raptured?

Harsh.


Anyway, at the time IIRC the exchange over SoyMAIL *was* pretty intense
:-)

I discovered S&M was not one of my fetishes.

It was unusual when the more unremunarated work you seemed to do for him,
the more he'd seek to wack you over the head.


[MONDESI] It's now out there:

http://wasd.vsm.com.au/wasd/


Well done! Maybe some public/hobbyist VMS site might be interested in
putting it up? Does it need privileges?

Thank you.

It's fairly innocuous; perhaps ~deathrow~?

Graham Burley probably won't thank me for dobbing him in but he was
incredibly helpful to me in getting Tier3 up and running on MANSON and
ironing out several bugs in my code and Multinet. They're running WASD and
I'm sure he'd be interested if he has the available time. (But don't tell
him I told you. He thinks yours is "push" technology too :-)

Or is it already there and you're winding me up?

The browser disconnects the TCP (by having JavaScript remove the DOM
element that held the link).

Which DOM element? Is this the xhr.abort() method? Does that actually tell
the server something useful? Wow, there's a turn up!

The server detecting this closure shuts
the data collection application down.

Does it have to wait for the server("collection application") to quiesce? So
unlike your nano-second stuff, if the server was locked on a database or
looping away madly then would we just have to wait?

When the client wishes to
reestablish a new or changed interval data collection it restablishes
the data feed request (by JavaScript creating a new DOM element to
maintain the link). That is; changing the collection characteristics
requires a fresh data feed.

There's that word "bollocks!" again. Why are people so blind to this crap?
Talk about fencing-wrire and duct-tape.

There's no asynchronous, bidirectional
communication. Perhaps in the next major version it might be possible
to use more of the HTML5 of Gecko and MSIE8!


Well Tier3 has had this functionality for over eight years! This is achieved
by effectively suppling your remote procedure with a full-duplex pipe as
it's only parameter. While the ratio of messages received:sent for a given
transaction is often 1:1 there is no restriction on how many messages are
sent back to the client (eg: a result set) or whether the server needs to go
back to the client for additional information/messages *while retaining
server affinity and transaction context*. Add to this Tier3's implementation
of the io$m_interrupt/OOB functionality available in the underlying network

transport, and you can also deliver an unsolicited interrupt/message to your
remote procedure. Examples of Tier3's "Hot Abort" capability can be found
at: -

http://manson.vistech.net/t3$examples/demo_client_flex.html and
http://manson.vistech.net/t3$examples/demo_client_web.html

Username: TIER3_DEMO
Password: QUEUE

BTW, how do you get around the mandated or recommended RFC restrictions on
the number of Ajax socket connections that can be active at one time? Was it
two or three? Just make sure you don't have more than 2 (plus the original
http) going at once?

Cheers Richard Maher



.