Post by David FroblePost by Stephen HoffmanI'm talking about the large amount of NV memory being the storage, and
having multiple ports so multiple VMS systems can access it directly.
I think that could be called "next generation".
Which is where I'm headed, and where I'd like new APIs. Futzing
around with disk-based abstractions for data sharing Gets Old.
Not so sure that most of us will be working on full-blown multi-port
memory configurations, as building bigger shared-memory boxes gets much
more expensive. VSI isn't in the hardware market, either.
Some people aren't afraid to spend money on their VMS systems, or any
system, for that matter. It depends upon their needs. Look at how the
SAN vendors came about. Where there is a need, there is someone who
wants the business.
Perhaps a current SAN vendor would introduce such products. You know
once one does, the current SAN market is on death row.
The business of racks and racks of shelves of HDDs — what we all had to
use to get any sort of decent I/O bandwidth with what we had for
storage with HDDs, and with some very fancy controller firmware to
spread that I/O load — is gone. EMC branched out into products and
services beyond their classic SAN storage offerings, and has now been
acquired by Dell, for instance.
Post by David FroblePost by Stephen HoffmanRAIS / HBMS on the other hand... Support for local byte-addressable
non-volatile storage if (as?) that becomes available, and RDMA (or
whatever) for remote operations. Preferably with a reasonable-to-use
API, and a way to both allow the updates to free-run when eventual
consistency works for the particular app, and to be able to operate
within a transaction across the updates when consistency is required.
Still thinking about the concept.
Not sure what you mean by API. What I'm envisioning is a low level API
for accessing the storage. Then higher level API(s) for more specific
things, such as a particular database, and other uses.
As an example, the QIO(W) used to access disk files, and disks.
Actually, there is a lower level for the disks. And for locking.
Then a database, or anything else, can be looked at as a "file", and
used accordingly. At the higher level(s), applications would access
the memory similar to how it's done now.
One subject is how to allocate the NV memory. Now, you create a file,
and the disk space is allocated, and such. I'm thinking I'd like to
think a bit more on the subject before falling back to that example.
Not saying I can think of anything better. Hoping some good ideas
surface.
I'd much rather work with an API abstraction designed from the other
direction; from what the developer needs to do and presently has to
deal with to do that, rather than presenting the constituent components
piecemeal. Presenting up pieces and parts works — when you approach
all the pieces with some consistency, and this consistency was one of
the classic OpenVMS strengths — but presenting functions piecemeal with
a mixture of system services such as $qio[w] and $io_perform[w] — two
of the most arcane calls — and DLM calls — another round of very
powerful and very arcane calls – and a mixture of RTL calls and
not-RTL-calls like the TLS support and who-knows-what layered
products.... gets messy to deal with. There's no good way to drain
this existing mess, either. But there's no good foundation for new
applications to start with, either — there's no clear picture for new
developers, and damned little consistency between all the parts we now
need to integrate and use.
Take clustering, for instance. Great concept. The central
abstraction is the file. That's not the only way to share data, and
that data is not where I really want it — in memory — and I'd really
rather not have to make a round-trip through physical storage and
marshalling and unmarshalling to share that data, and I'd rather not
have to do my own change notifications (via DLM or multicast) when the
data changes. There's all sorts of stuff missing from even the
present-day file-based sharing abstraction underneath clustering, such
as data encryption and authentication and isolation. We're also
moving data around a lot more, particularly on the network. With a
cluster, we're supposedly inside a single security domain, which is an
assumption from the last millennium and one that is looking rather more
problematic now — I have no good way to isolate a file parser or a
network parser for instance, and I really don't entirely trust even
existing OpenVMS tools to be proof against malicious volumes or
malicious files. No good way to bridge clusters, and the LDAP
integration is... bad. Cluster management is most charitably called
an afterthought, too.
How this application sharing and replication all fits together and
where clusters might go, I don't know. But I do know that what we
have with clustering — file-based sharing — is not a particularly easy
product to really use, nor one that clearly sells all that well.
--
Pure Personal Opinion | HoffmanLabs LLC