[Info-vax] PowerX Roadmap - Extended beyond 2020

[David Froble]

Jan-Erik Soderholm wrote:
> Den 2016-09-16 kl. 15:22, skrev Bob Koehler:
>> In article <nrfrgj$res$1 at dont-email.me>, David Froble 
>> <davef at tsoft-inc.com> writes:
>>>
>>> Don't know why you insist on RMS.  I haven't used it since before 
>>> 1984.  If I
>>> was working on something new, with perhaps special file I/O 
>>> requirements, then
>>> I'd consider how I might best do the job.
>>
>>    Done any file I/O on VMS lately?  If not via RMS, then how?
>>
>>    If you so much as accessed a file by name and path, you used RMS.
>>
> 
> For what we are talking about here (VMS as back-end for IoT
> generated data/transaction) RMS might not be an issue. Oracle
> Rdb doesn't use RMS for it's general DB I/O. Only for specific
> operations such as database backup, table load/unload, database
> export/import and similar. Not for anything done during regular
> operations.
> 
> Sometimes back in the early 90's someone on INFO-VAX wrote:
> 
>  > I have it from DEC that Rdb does NOT use RMS.  It calls QIO's
>  > directly to avoid the (minimal) overhead of RMS, since it
>  > doesn't need anything which RMS provides and QIOs do not.
> 
> 
> I do not now how other DB's such as MariaDB runs its DB I/O...
> 
> So, for what we are talkning about here, RMS might be a non-issue.
> 
> 
> Jan-Erik.

Well, storage I/O isn't rocket science ....

Ignoring things strictly on the storage devices, you might have:

1) device drivers to talk to the storage devices

2) low level tools to talk to the device drivers, such as QIO, IO$PERFORM

3) medium level tools using QIO, IO$PERFORM such as RMS, DB products, and such

4) high level tools such as databases, RMS, and such that most programmers use

Very brief description, and VMS specific, but that's most of the structure