[Info-vax] Databases, LDAP and the limitations of RMS-file-based authentication

[Stephen Hoffman]

On 2015-01-05 15:57:38 +0000, Bob Gezelter said:

> On Tuesday, December 23, 2014 11:15:53 PM UTC-5, David Froble wrote:
>> Stephen Hoffman wrote:
>> 
>>> As opposed to the VMS guy who spends a whole lot of time working on Unix
>>> and C, and with C on VMS?  (Having a more robust C environment would be
>>> useful on VMS -- working on a list of the local snags with C99 and C11 to
>>> send along to Mr Reagan as part of that -- and maybe access to some newer
>>> tools like, maybe, Rust would be nice.  The versions of Fortran or BASIC
>>> available for VMS, alas, tend to be non-starters for the sort of work I
>>> usually use C for.   If not C on VMS, it'd be Bliss or Macro32, but then
>>> more folks are familiar with C than with either Bliss or Macro32.)
>> 
>> Gee, and just why are some of the legacy (stuff that works) non-starters?
>> 
>> I mean, I just figured there is / was this thing called the VMS calling
>> standard, that every language (except for C) seems to respect, and so
>> one should be able call code from any VMS language.
>> 
>> How naive could I be?
>> 
>> It's crap such as this that makes me thing that VMS is good and *ix and
>> C are bad.
>> 
>> I still cannot understand why I could not call the SSL routines from
>> Basic, and I still cannot understand how VMS development could have
>> stooped so low as to throw things out there that could only be called
>> from C.
> 
> Insofar as I know, there is no reason that you cannot call SSL routines 
> from BASIC (I have been invoking C routines from BASIC for decades, 
> literally).
> 
> If the data structure definitions provided as C header files are not 
> supplied in forms compatible with BASIC, one may have to translate the 
> data structure/record definitions, but that is not a major job, just 
> tedious...

What David is likely grumbling about is the lack of VMS 
descriptor-based interfaces for these and other calls.

Making the SSL calls directly from BASIC is certainly entirely 
possible, it's just more work than creating a jacket with a 
descriptor-friendly interface.

The current OpenSSL interface leaves folks the choice of either a more 
complex API scattered around within the BASIC code (and the OpenSSL 
interface is pretty ugly to start with), or creating a set of jackets 
written in BASIC or in C to isolate the OpenSSL calls.  Pushing the C 
API incantations including the ASCIZ support and the pointers up into 
some BASIC-based jacket code does make for somewhat more work and it 
can mean having to translate the symbolic constants, which means 
somewhat more complex code and more effort.  Using C-based jackets 
<http://labs.hoffmanlabs.com/node/1853> keeps the BASIC code simpler 
and much more consistent, and it avoids having to generate BASIC 
versions of the C definitions, where those BASIC definitions don't 
already exist.

For OpenSSL, David would have preferred something closer to the 
DECwindows APIs where there are C native bindings 
<http://h71000.www7.hp.com/doc/73final/5642/5642pro.html> and 
VMS-native bindings 
<http://h71000.www7.hp.com/doc/732final/documentation/pdf/dw_guide_nonc_bindings.pdf>, 
and not having needed to create the C jackets at all.

When compared with David, I'm more interested in looking at languages 
past BASIC, Fortran and C, for that matter.   Having worked in each, 
each of these languages has various issues.  I'd prefer to find a 
language that means less source code and more reliable and robust code, 
and preferably with support and tools for easier code creation and 
debugging and related tasks.   Which is the comment that started this 
off.     I'd also prefer to see better and more capable and more 
current APIs, which ties back into (part of) what David is looking at 
with OpenSSL and the jackets.

-- 
Pure Personal Opinion | HoffmanLabs LLC