[Info-vax] DCL's flaws (both scripting and UI)

[Paul Sture]

On 2015-01-21, Simon Clubley
<clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2015-01-21, David Froble <davef at tsoft-inc.com> wrote:
>>
>> I think it's reasonable for "if it ain't broke, don't fix it", and 
>> breaking someone's (however disgusting) DCL procedures will not leave 
>> them very happy.
>>
>
> I'm not seeing why adding the kind of functionality I would like to
> see added is going to break existing code. I've already posted example
> syntax which shows how I see existing code operating alongside a future
> OO based DCL.

Taking about upwards compatibility, I've just come across a method which
sets the API version at the beginning of a program.

<https://foundationdb.com/key-value-store/documentation/class-scheduling.html#appendix-schedulingtutorial-py>

Open a Python interactive interpreter and import the FoundationDB API module:

$ python
>>> import fdb

Before using the API, we need to specify the API version. This allows
programs to maintain compatibility even if the API is modified in future
versions:

>>> fdb.api_version(300)

And what am I doing looking at FoundationDB?  I thought I'd take a look
at some of the open source newer databases out there.

Perhaps NewSQL (traditional SQL with ACID meets NoSQL) would be relevant
to VSI's customer base.

<http://www.opensourceforu.com/2012/01/newsql-handle-big-data/>

-- 
Of dates and times:
%S - Second as decimal number (00–61), allowing for up to two leap-seconds
(but POSIX-compliant implementations will ignore leap seconds)