[Info-vax] Better languages than BASIC

[Arne Vajhøj]

On 1/12/2024 8:22 AM, Jan-Erik Söderholm wrote:
> Den 2024-01-12 kl. 02:56, skrev Lawrence D'Oliveiro:
>> On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
>>
>>> On 1/11/2024 1:30 PM, Simon Clubley wrote:
>>>
>>>> If you want to write business applications, then either Java or a
>>>> subset of C++. C++ subset to be chosen based on programmer skillsets
>>>> and the problem to be solved.
>>>
>>> Or COBOL which was actually designed for the task.
>>
>> Supposedly. But a couple of decades after the COBOL spec was first
>> published, these things called “relational databases” appeared on the
>> scene, and they soon became essential for “business applications”. And 
>> the
>> best way to access them turned out to require generating SQL query
>> strings. But good string handling had not been considered a necessity for
>> “business applications” in COBOL. So it had to resort to nonstandard
>> kludges tacked to the side to cope with SQL queries.
> 
> Well, that is written by someone without a clue.
> 
> Building SQL queries using string operations is a no-no
> for any professional database development.

Yes.

>                                            It does mean that
> the whole SQL syntax check and compilation has to be done by
> the run time environment. And if some parameter changes (like
> an order number), the whole query is concidered to be "new" and
> the full syntax check and compilation is done again each time.

And besides that there is the potential for SQL injection.

> For applications developed on, and running on, VMS there are two
> main options:
> 
> Embedded SQL.
> Supported by most common languages. When building an application here,
> a pre-compiler is first run. That one extracts all SQL statements and
> compiles the SQL into object/machine code. When the main compiler is
> then run, this object code is automaticaly included in the main object
> file.
> 
> SQL Modular Language.
> This is a bit similar to Embedded SQL, but the SQL code is kept in
> a separate file by itself. And the SQLMOD compiler only reads this
> file and creates a stand-alone object file. This object file is then
> just included in the build of the main application. The main application
> just calls some functions with any name (like "GetOrder") and it
> (the main code) has no idea that there is any SQL or database or how
> that order data is fetched. So it can be used from any compiled language
> no matter if that specific language have any specific SQL support.

Embedded SQL is not bad. Not at all.

The biggest problem is the support for it.

Not that many databases comes with SQL precompilers today.

And if they do then the number of languages supported are often
limited. Rdb has great language support. But most other databases
only support Cobol and C.

I have a list of supported combinations on VMS in:
    https://www.vajhoej.dk/arne/articles/vmsdbx.html#embsql
(scroll down a few pages until the "Support" section)

SQL modules are even more rare.

> For Cobol both these options exists. They can be mixed anyway in the same
> application, if needed. We had some common queries (like "FetchOrder") as
> SQLMOD files and then added the specific application queries into the
> application code as Embedded SQL for easier maintenance of the code.
> 
> So, the bottom line is, that there is absolutely no need for any
> string operations to use SQL from Cobol applications.

Not for the common cases. In the rare cases people work around
it with coalesce trick or other.

> And, as Arne also mentioned, there is a huge security issue with
> bulding SQL queries using string operations, if you include any
> dynamic parameters into that.

Yes.

> If you need to use dynamically built SQL queries, at least use what
> is commonly called "parameter markers", where the main SQL code and
> the values of any parameters are separated from each other. That way
> you cannot include any non-wanted SQL code in the actual values of
> the paramaters.

Yes.

And practically all database API's support it today. I can only
remember two that did not - the old MySQL pre-4.1 C API and the
old Sybase DB API - both from the 90's.

Arne