[Info-vax] Desperately Seeking OpenVMS ecosystem

[Subcommandante XDelta]

BillPedersen:

> I think there are way enough techies and system managers here and on the SIG list to move the information to the right levels.  But I also believe there are other forums where information needs to be posted to keep people informed and involved.

I think there may be a sustainable basis for an VMS ECOsystem to fund
its own maintenance, research and development of VMS.

>From the various conversation strands, there are circa 2000 VMS shops
paying maintenance fees to HP, there are circa 1000 hobbyist licences
being renewed annually. And the sake of the argument, let us assume,
pending any evidence to the contrary, that there are an additional 2000
or so VMS shops, going it alone, having no relationship with HP.

That might be a self-sustaining matrix for a VMS Ecology, so long as
information "integration circuitry" of both a push and a pull nature can
be made known and available to all elements (vendor or end-user) in the
matrix. (matrix in the sense of nourising womb, rather than mathematical)

"Push" being an email notification mechanism, for example, and "Pull"
being a website, for example. A push information vector requires no
further effort on the elements part than initial registration, whereas
with a pull information vector, the element (vendor or end-user) needs
to pro-actively reference the resource for fresh information.

Terminology happily corrected/refined.

> Now, that said, my concern, with the idea of getting information from the Partners is that there is overlap.  We do not know how much overlap.  But I know that I tend to share clients with other Partners. So, if we look at it as in following:
> 
>     Partner A  :   X VMS customers
>     Partner B  :   Y VMS customers
>     Partner C  :   Z VMS customers
>     Partner D  :   N VMS customers
>     Partner E  :   O VMS customers
> 
> The actual number of VMS customers is not the SUM of these.  We can say that at the "minimum" the number of VMS customers is the MAX(O, N, X, Y, Z).  That is about all we can say reliably without more information.  I would like to figure out a way to get that information.  That is the measure of the ECOsystem.
> 
> Bill.

Well, with clients on a client list, I suppose permission should be
sought for the sharing of any data.

Yes for a Vendor V(k) with a client list (set) C(k), <V(k),C(k)> for all
vendors 1 <= k <= K, the best estimate of known size of the VMS ECOlogy
is the cardinality of the union of all the client lists.

#{ U(k) C(k) } 1..k..K (yes, terrible ASCII rendition!)

Anyway, moving right along...

Consider these three VMS Software developers, to cite but three:

http://www.process.com/
http://www.raxco.com/products/openvms-performance-suite
http://www.nls.com/home/home.html

All have excellent VMS applications that would ease the burden of any
VMS system manager in any VMS shop, however is every end-user and every
other vendor in the VMS ECOlogy aware of these resources? - probably not.

There may be myriad VMS system managers out there in the wilds, living
lives of quiet desperation, not having a functional map of the VMS
vendors ECOlogy.

def(Vendor) = OEM, VAR, ISV, COTS, Software Developers, Service
Providers, ETC.

These seven statements I think could generally be agreed to be
axiomatically self-evident and true:

1. There is no competitive business advantage for a VMS vendor to be
ignorant of the full extent of the other vendor elements in the VMS ECOlogy

2. There is no competitive advantage for any VMS vendor to be unknown by
the full extent of the other vendor elements in the VMS ECOlogy.

(Some vendors might be direct competition with each other, however
vendors can be customers of other vendors and can also strike up
strategic alliances with other vendors, etcetera).

3. There may be competitive advantage for a VMS vendor not to share
their client lists with the full extent of the other vendors in the VMS
ECOlogy.

4. There is no competitive advantage or business rationality in a VMS
End-user being ignorant of the full extent of the vendor elements in the
VMS ECOlogy.

5. There may be some competitive advantage and business rationality in a
VMS End-user not being known by the full extent of the vendor elements
in the VMS ECOlogy.

(Axiom #5 in a nutshell, is that some VMS end-users might like their
privacy.)

6. End-users may not trust all other end-users nor any or all vendors
and vendors may not trust any or all other vendors.

7. It is in the best interest of all end-users and vendors in the VMS
ECOlogy to maximise it's self-informing nature, within the constraints
imposed by the previous six axioms.

So, how do you design the best possible push and pull information
vectors given those seven axioms?

Well the vendors have a clear interest in rapidly developing information
infrastructure to map and inform the VMS ECOlogy, since it is doubtful
that any of them has a client list so extensive, that it qualifies as a
de-facto map of the entire VMS ECOlogy.

However, no doubt, every vendor would like such an extensive client list!

In these early bootstrap days of the VMS ECOlogy where there is little
knowledge and perhaps little trust, how to get started?

Perhaps the simplest way is to establish an HBICH (Honest Broker
Information Clearing House) - a universally well-known, particularly
amongst all vendors, VMS person, runs the push and pull information
vectors from subdomains of one their own known domains.

Thus one known person in control, and no others.

For example, purely as an example, the HB could be Stephen Hoffman.

Unless they have been living under a rock for the last two decades or
more, the principals of any VMS vendor should know who he is.

So what would the nature of the HBICH (Honest Broker Information
Clearing House) that needs to be designed?

A VMS system with a RDB database. The system has two classes of user
accounts (besides system admin ones) end-user and vendor.

1. The full extent (size) of the end-user population needs to be mapped
and determined and the full extent of the end-user population needs to
be informed, depending on the wishes of the end-user, but all end-users
would be encouraged to declare their unique existence without having to
define their specific identity.

For end-user accounts, there are only four data-fields in the HBICH
RDBMS, one is for an email address, that is mandatory, the second
toggles whether they want to receive email or not, the third is an
optional field (optional to define a non-default value) which is the
numbers of VMS systems that they run; the fourth is an (optional)
defintion of a principal country of operation.

If they wish to not identify themselves by their email address, they can
be advised to use the resources of professional, quality, e-mail
resources such as:

http://www.pobox.com
http://www.fastmail.fm
http://www.runbox.com

All of which IIRC (well, particularly the first) allow e-mail redirects;
all cost circa $20 USD P/A; cheap as chips for the requisite privacy.

That way all end-users have full control of their privacy, yet at the
same time can document the fact of unique existence to the VMS ECOlogy
HBICH and, optionally, the numbers of VMS systems that they have and
their principal international jurisdiction. They also have full control
over whether or not their receive push e-mail notification.

The vendor accounts, and related database structures, would perforce be
more complex, since they should have neither reservation nor inhibition
about any end-user or other vendor knowing the relevant particulars of
their VMS business.

So there would be fields for the usual contact details, business name,
website, email contact address, postal address, business address,
etcetera. Fields for  list of keywords from a defined table and a field
for the business type from a defined table (COTS, VAR, ISV, OEM, S/w
developer, service provider, etc) and well as a free form text field for
a complete description of their business, services and products.

All the fields would be indexed and searchable with ad hoc SQL queries
and well as pre-defined ones.

VMS Account logins and database access, both definition and queries, can
be done by X-Windows, terminal or web-interface, the latter allowing for
Tor-ified web-access for those end-users really concerned about their
privacy (not the VLF!!).

There would be a periodic, monthly, email circular that provides summary
statistics on the end-user populations and vendor populations registered
in the systems. Such reports are compiled and e-mailed by a system account.

Even though truly minimal contextual information is requested of the
end-user population, still some might have reservations that the
information could be abused.

Obviously using e-mail indirection as described above would obviate much
of such fears, but the VMS and HBICH RDBMS, could be carefully designed,
using ACL structures and whatnot, that any end-user can fully examine
the RDBMS access logs for their database record, and if field level
access logging is possible, then that is logged too.

The system is built so that no end-user or vendor account can access and
read any other database record for any end-user, however all end-users
can access the logging files for their database record and fields.

All they should ever see is the defined system account accessing their
e-mail field when the monthly report is generated and sent...

By such means, trust is established; building on the trust of the
nominated HB (Honest Broker) himself.

For the purpose of privacy, no vendor account can read any logging
records of who is accessing their database records, end-user privacy is
maintained.

Now end-users may or may not register themselves in the HBICH database,
should they become aware of its existence, however they may be on one or
more client lists with VMS vendors.

Any periodic HBICH bulletins emailed out, would be sent, of course, to
all vendors, registered in the system. It is then the responsibility of
the vendor to on-send all the HBICH bulletins to all on their client list.

So no VMS Vendor has to cough up their client list to the HBICH
database, but it is incumbent on each and every vendor to onsend the
bulletins to their clients to maximise the self-informing quality and
efficacy of the VMS ECOlogy and hence business that may be curried their
way.

For some clients, who do business with multiple VMS vendors, they may
get multiple copies of the bulletins, but at least they can be assured,
that they have multiple-path failsafe redundancy and are always in the
information loop...

(And of course all bulletins, would also be archived on the
corresponding HBICH website as the "pull" information vector)

Thus the VMS vendors need to co-operatively boot-strap this, communally
putting their shingle outs, sticking their oars in, declaring to the VMS
ECOlogy that they are ready for business and open to business, as they
always have been, but unfortunately not all end-users have been aware...

I am sure there are many on comp.os.vms that could knock up a working
database prototpe over the course of a week-end or two.

I may have had a lemonade stand as a kid, but that would be all I know
about business matters.

By such a VMS ECOlogy HBICH, it may be possible that the VMS ECOlogy can
become maximally self-informing and as a consequence, can co-operatively
co-ordinate self-determination of the fate and future of the VMS
ECOlogy, with or without the co-operation of the HP Corporation.

Any way, some rough clay for conversation purposes, tear it all down,
build on it further, think of something better, feel welcome.