[Info-vax] Is there currently a functioning link for hobbyist licenses?

[Jan-Erik Soderholm]

Bill Gunshannon skrev den 2015-03-11 15:21:
> In article <mdphhj$5p7$1 at news.albasani.net>,
> 	Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
>> Bill Gunshannon skrev den 2015-03-11 13:47:
>>> In article <00AF3F52.533B5650 at sendspamhere.org>,
>>> 	VAXman-  @SendSpamHere.ORG writes:
>>>> In article <cb904ca3-911e-4384-8e73-4a17e13efcaa at googlegroups.com>, seasoned_geek <roland at logikalsolutions.com> writes:
>>>>> I did a quick search in here when I found openvms.org was off-line.  Tried =
>>>>> the other link with misspelled registration and it tossed up a 404 error.
>>>>>
>>>>> Is there a functioning link for hobbyist licenses or has that program gone =
>>>>> belly up?  I haven't turned my DS-10 on in a couple of years, but, now that=
>>>>> I finished yet another death march embedded development project I wanted t=
>>>>> o come up for air doing some DIBOL and BASIC and COBOL. Basically relive a =
>>>>> time when things actually worked.
>>>>
>>>> http://plato.ccsscorp.com/hobbyist_registration.php
>>>>
>>>
>>> On a semi-related subject, has SQLite3 been ported to VMS?  I have
>>> been interested in doing SQL Precompilers for some of the OS database
>>> packages and doing some for VMS might be fun.  And, because of some
>>> of the anachroistic facets of SQLite VMS is probably a prime candidate.
>>>
>>> bill
>>>
>>
>> OK, I have read up a bit on SQLite. I have a hard time seeing why
>> VMS would be a prime candidate for SQLite.
>
> Wellllll.....  That comment was a little tongue-in-cheek. :-)
> I tried it out for the first time yesterday.  It was unable
> to write anything into a file.  In Memory works, but not on
> disk.  Couldn't do backups either.  "Why?" you ask.  Don't know
> for sure, but apparently it won't work with NFS mounted disks.
> Well, all of our user disks are served from a central server
> using, you guessed it, NFS.  How anyone could write program
> today that, for whatever reason, can't work with NFS mounted
> disks is beyond me.  However, NFS not being the common way
> of doing things on VMS, I figured it must work there.  :-)
>
>
>>                                             Might work OK for Firefox
>> to keep track of the setup things in the local browser, but that
>> is a single user environment. OK, they say that SQLite is the most
>> widely deployed database product in the world. Right, hard to beat
>> 500 Miljon Firefox "users". But how many of them has actively
>> selected SQLite? :-)
>
> Gee.  I thought taht was the clainm being made by MondoDB.  Guess
> all of them are the "most widely deployed database product in ther
>   world".
>
>>
>>
>> B.t.w, the product is called SQLite. SQLite3 is a specific
>> command line tool to do some DBA things. It is also the prefix
>> of some of the API calls.
>
> I also specified SQLite3 as that is the current version and the
> changes from Version 2 are enough to make them totally incompatable.
>
>>
>> The architecture of SQLite is using what is usualy called
>> "Dynamic SQL". The SQL statements are sent to the API's in
>> clear text even in runtime. It is just a function call from C
>> with the SQL statement as a paramater.
>>
>> Now, what would this precompiler actualy do? Convert a EXEC SQL...
>> END EXEC structure to the sqlite3_open(), sqlite3_prepare() (and so
>> on) calls?
>
> Yep.  that's what I had in mind.  EXEC SQL is how the world does it
> and if any of this Open Source stuff is going stand a chance, it will
> have to do things the way the industry does.  Programmers don't want
> to have to learn a dozen obtuse C-targeted API's in order to use the
> product.
>
>>
>> Very little will be gained. A true embedded SQL precompiler would
>> actualy "compile" the SQL into the actual database operations to
>> performe the operations asked for. Since there is no other API
>> than the dynamic SQL one, there is no way to do that. The SQL
>> will be syntax checked and evaluated at every call to the API.
>
> Well, while that may be true, isn't that what happens with any of the
> commercial database programs?  I am merely rtying to implement for OS
> what the real world is doing.  (And as a side note, there is something
> in the SQLite docs about a call that "precompiles" the SQL statements
> into some kind of byte code eliminating this,...

Yes, that is what the "prepare" operation does in any dynamic
SQL interface. But it is temporay, and only in the actual
running local process. Each process (user) doing the same
SQL has to perform the same "prepare" operation.

A precompiler (well, some at least :-) ) does the "prepare"
at compile time and only "executes" at run time.

But, OK, I understand... :-)


> but considering that it
> is unlikely that most programs repeatedly use the same SQL statement
> I don't see it as a problem either way.)

On the other hand, it is *very* likely that most programs only
uses a small set of the same SQL statement! It is only the values
that changes, but they are using paramater markers anyway, and
the values are not part of the SQL that is "prepared".

You prepare stmt1 = prepare("SELECT f2, f2, f3 from t1 where f4=?")

And then execute stmt1(1234) and that value is used for the SELECT.

Not that exact syntax, but you get the general idea... :-)

Jan-Erik.