On 1/12/2024 7:36 AM, Arne Vajhøj wrote:
> On 1/11/2024 8:56 PM, Lawrence D'Oliveiro wrote:
>> 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.
>
> Dynamically generating SQL strings is actually a big no no.
>
> That is the road to poor performance and big security holes.
>
> Traditional Cobol embedded SQL does much better than that.
>
> Arne
>

SQL is nice. It works. But, I consider it a square hole, and you better not
have a round peg.

For some operations, one must go through rather convoluted things to get the
desired result.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/12/2024 6:15 AM, Marc Van Dyck wrote:

> Amazing that in current programming languages discussions, PASCAL is
> never mentioned anymore. I understand that it has lost a lot of momentum
> and never was a big success outside of the academic field, which used to
> be a DEC stronghold way in the past. But in this case, why is VSI (and
> before that HPE) still supporting that language today ? It cannot be
> customer base, can it ? It is certainly not seen as a language of the
> future either... So why ? Just because John likes it, or what ?

You finally figured it out.

:-)

Pascal is John's baby, and if you have John running the compiler people, you
will always have Pascal. If you don't have John running things, you might be sorry.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/12/2024 3:04 PM, Dave Froble wrote:
> On 1/12/2024 7:36 AM, Arne Vajhøj wrote:
>> On 1/11/2024 8:56 PM, Lawrence D'Oliveiro wrote:
>>> 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.
>>
>> Dynamically generating SQL strings is actually a big no no.
>>
>> That is the road to poor performance and big security holes.
>>
>> Traditional Cobol embedded SQL does much better than that.
>
> SQL is nice.  It works.  But, I consider it a square hole, and you
> better not have a round peg.
>
> For some operations, one must go through rather convoluted things to get
> the desired result.

SQL as a language is a bit quirky.

But its support across databases, support i libraries,
available skills and flexibility makes it "the" database
thing.

The modern solution is an ORM where the the developer does
not write the SQL manually but it gets generated by a library, so the
developer can focus on an object model.

Arne

On Fri, 12 Jan 2024 12:15:24 +0100, Marc Van Dyck wrote:

> Amazing that in current programming languages discussions, PASCAL is
> never mentioned anymore.

Standard Pascal was little more than a toy, useful for teaching but not a
lot more.

To make it useful you needed some serious extensions. But that’s where
things diverged. Look at VAX Pascal (v2 or later) and you see things like
external symbols, structure layout control and arguments by keyword, which
made it great for system programming on VMS.

Outside the DEC world, there was UCSD Pascal, with an entirely different
(and incompatible, and less ambitious) set of extensions. That became kind
of a de facto standard in the PC world, with Turbo Pascal copying the same
set of extensions, for example.

One project that still lives on is Free Pascal
<https://www.freepascal.org/>, which aims to be compatible with UCSD/
Turbo.

On Fri, 12 Jan 2024 13:34:53 -0000 (UTC), Simon Clubley wrote:

> For security reasons, I would have preferred to see that as a prepared
> statement instead of as a concatenated SQL statement.

Feel free to show us how you would write it as same. Can your prepared-
statement system cope with variable numbers of fields? Variable field
names? Variable operator selections? All these were present in the
example.

On Fri, 12 Jan 2024 15:04:34 -0500, Dave Froble wrote:

> SQL is nice. It works. But, I consider it a square hole, and you
> better not have a round peg.
>
> For some operations, one must go through rather convoluted things to get
> the desired result.

Would some other language make things easier? Is this your idea of
“rather convoluted things”? It can display entries for all clients or
just a single specified client, and it can display only charged
entries, only uncharged entries, or both:

for entry in get_each_record \
(
table_name =
"clients inner join jobs on clients.client_id = jobs.client_id"
" inner join hours on jobs.job_id = hours.job_id",
fields =
[
"clients.client_id as client_id",
"jobs.job_id as job_id",
"clients.name as client_name",
"jobs.description as description",
"hours.from_time as from_time",
"hours.to_time as to_time",
"hours.notes as notes",
],
condition =
" and ".join
(
(
lambda : (),
lambda : ("clients.client_id = %u" % only_client,),
)[only_client != None]()
+
(
lambda : (),
lambda :
(
"hours.invoice_entry_id %s null"
%
(
"is",
"is not",
)[charged],
),
)[charged != None]()
+
(
"hours.from_time >= %u" % day_local_start(when_worked),
"hours.from_time < %u" % day_local_start(when_worked + 1),
"hours.to_time is not null",
)
),
extra = "order by hours.from_time, clients.name, jobs.description"
) \
:
... process entry ...
#end for

On 1/12/2024 3:31 PM, Lawrence D'Oliveiro wrote:
> Outside the DEC world, there was UCSD Pascal, with an entirely different
> (and incompatible, and less ambitious) set of extensions. That became kind
> of a de facto standard in the PC world, with Turbo Pascal copying the same
> set of extensions, for example.
>
> One project that still lives on is Free Pascal
> <https://www.freepascal.org/>, which aims to be compatible with UCSD/
> Turbo.

TurboPascal 5.5 added OOP. FPC aims at being Delphi compatible.

Which means that the main flow of extensions must be:

Apple Object-Pascal -> TP 5.5+ -> Delphi -> FPC

Arne

On 1/12/2024 2:27 PM, John Reagan wrote:

>
> I wrote a lengthy reply to this to answer your (and others) questions. I
> don't see it online however.  If it doesn't show up at some point,
> I'll dig it out of some sent folder and resend.
>

2nd attempt:

- There are MANY customer applications written in VMS Pascal with
many of them in the millions of lines. Still an important legacy
language. Just like we aren't forgetting BASIC.

- Why so "early"? Partly that I know the compiler and RTL's build
system, test system, configuration scripts, etc. It was "easy" and it
didn't use any really sketchy coding practices (BASIC compiler, I'm
looking at you). I'll give credit to several former developers
(including myself). As a piece of trivia, the Pascal RTL was originally
developed by "Mr Fortran", Steve Lionel.

- VMS Pascal has many of the features from the Extended Pascal standard
from the late 1980s (that's where all the things like schema types came
from). Several of the features in EP came from Digital with slightly
different syntax (direct file access for example). Borland did
participate on the X3J9 committee but was more concerned with low level
concepts like wanting to "standardize" PEEK and POKE and ignored the
rest.

- There was an Object-Oriented Addendum to the Extended Pascal standard.
Pretty much matched the C++ of the day along with a little Oberon mixed
in for fun.

I think that the Prospero (now defunct) Extended Pascal compiler
actually implemented it
http://www.edm2.com/index.php/Prospero_Software

- I don't see the need to add OO to VMS Pascal. There are several other
languages to choose from these days. We have added a feature or two
over the years based on customer requests (the last "big" feature was
my addition of the SELECT/SELECTONE statements patterned after the
BLISS equivalents). With all the discussions around what it means to be
a 64-bit program, perhaps I should get the compiler to be more flexible
with its handling of 32-bit vs 64-bit descriptor forms.

- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual. [I've been doing
lots of doc review lately.]

On 1/12/2024 4:20 PM, John Reagan wrote:
> - And the online Pascal docs will be updated soon (I just finished the
> review of the Reference Manual and I'm about done with the User Manual).
> The revision adds x86 works AND incorporates a bunch of stuff from the
> release notes that have never made it to the manual.  [I've been doing
> lots of doc review lately.]

Can you reveal anything about how far out Basic for VMS x86-64 is?

1 day? 1 week? 1 month? 1 quarter?

Arne

On 1/12/2024 4:20 PM, John Reagan wrote:
> - I don't see the need to add OO to VMS Pascal.  There are several other
> languages to choose from these days.  We have added a feature or two
> over the years based on customer requests (the last "big" feature was
> my addition of the SELECT/SELECTONE statements patterned after the
> BLISS equivalents).  With all the discussions around what it means to be
> a 64-bit program, perhaps I should get the compiler to be more flexible
> with its handling of 32-bit vs 64-bit descriptor forms.

Right now the goal of VSI must be to get all the existing
VMS customer to port their existing applications to VMS x86-64.

But what is the plan when that is done?

(not urgent because it will take years)

What will new business applications for VMS be written in?

(we are hoping for such!)

Obviously all the non-native languages (Java, Python, PHP etc. - I
still recommend Groovy!) are going to grab the majority.

But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?

I would hate to see that.

I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.

Arne

On 1/12/2024 4:51 PM, Arne Vajhøj wrote:
> On 1/12/2024 4:20 PM, John Reagan wrote:
>> - I don't see the need to add OO to VMS Pascal.  There are several other
>> languages to choose from these days.  We have added a feature or two
>> over the years based on customer requests (the last "big" feature was
>> my addition of the SELECT/SELECTONE statements patterned after the
>> BLISS equivalents).  With all the discussions around what it means to be
>> a 64-bit program, perhaps I should get the compiler to be more flexible
>> with its handling of 32-bit vs 64-bit descriptor forms.
>
> Right now the goal of VSI must be to get all the existing
> VMS customer to port their existing applications to VMS x86-64.
>
> But what is the plan when that is done?
>
> (not urgent because it will take years)
>
> What will new business applications for VMS be written in?
>
> (we are hoping for such!)
Beats me, ask the people who want to write those business applications.
I just make the "hammers", I don't know if you'll use it to build a
house or break a window.

>
> Obviously all the non-native languages (Java, Python, PHP etc. - I
> still recommend Groovy!) are going to grab the majority.
>
> But for those wanting native code (and quite some will due
> to need to link with old legacy code) will C++ really be
> the only choice?
I don't understand your use of "native"? All of the compilers
generate real instructions and are not interpreted. Did you
forgot to say OO?

>
> I would hate to see that.
>
> I would love to see VMS Pascal and VMS Basic being beefed up
> with OO, generic and maybe a drizzle of functional.
>
Implementing an OO model is quite involved. The OO Pascal
addendum to the standard was limited (no multiple inheritance,
just "mixins") but would still be a beast to implement fully.

It isn't something we can hack over a weekend. People who want
such features will need to write that on the back of a large
stack of $100 bills and send that to VSI.

> Arne
>
>

On 1/12/2024 5:17 PM, John Reagan wrote:
> On 1/12/2024 4:51 PM, Arne Vajhøj wrote:
>> Obviously all the non-native languages (Java, Python, PHP etc. - I
>> still recommend Groovy!) are going to grab the majority.
>>
>> But for those wanting native code (and quite some will due
>> to need to link with old legacy code) will C++ really be
>> the only choice?
>
> I don't understand your use of "native"?  All of the compilers
> generate real instructions and are not interpreted.  Did you
> forgot to say OO?

With native I mean traditional EXE.

Yes - there were an implicit "with modern features:
object oriented, generic and functional".

>> I would hate to see that.
>>
>> I would love to see VMS Pascal and VMS Basic being beefed up
>> with OO, generic and maybe a drizzle of functional.
>>
> Implementing an OO model is quite involved.  The OO Pascal
> addendum to the standard was limited (no multiple inheritance,
> just "mixins") but would still be a beast to implement fully.
>
> It isn't something we can hack over a weekend.  People who want
> such features will need to write that on the back of a large
> stack of $100 bills and send that to VSI.

I know it is a big task.

But when the number of bug reports starts descending towards zero
and LLVM team releases new C/C++ and Fortran compilers and no Cobol
developers want OO, then what are you going to spend time on?

Arne

On 1/12/2024 5:36 PM, Arne Vajhøj wrote:
> On 1/12/2024 5:17 PM, John Reagan wrote:
>> On 1/12/2024 4:51 PM, Arne Vajhøj wrote:
>>> Obviously all the non-native languages (Java, Python, PHP etc. - I
>>> still recommend Groovy!) are going to grab the majority.
>>>
>>> But for those wanting native code (and quite some will due
>>> to need to link with old legacy code) will C++ really be
>>> the only choice?
>>
>> I don't understand your use of "native"? All of the compilers
>> generate real instructions and are not interpreted. Did you
>> forgot to say OO?
>
> With native I mean traditional EXE.
>
> Yes - there were an implicit "with modern features:
> object oriented, generic and functional".
>
>>> I would hate to see that.
>>>
>>> I would love to see VMS Pascal and VMS Basic being beefed up
>>> with OO, generic and maybe a drizzle of functional.
>>>
>> Implementing an OO model is quite involved. The OO Pascal
>> addendum to the standard was limited (no multiple inheritance,
>> just "mixins") but would still be a beast to implement fully.
>>
>> It isn't something we can hack over a weekend. People who want
>> such features will need to write that on the back of a large
>> stack of $100 bills and send that to VSI.
>
> I know it is a big task.

You forgot to ask how big of a stack ...

:-)

I'm guessing the top of the stack might lack enough oxygen ...

> But when the number of bug reports starts descending towards zero
> and LLVM team releases new C/C++ and Fortran compilers and no Cobol
> developers want OO, then what are you going to spend time on?
>
> Arne
>
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
> On 1/12/2024 4:20 PM, John Reagan wrote:
>> - And the online Pascal docs will be updated soon (I just finished the
>> review of the Reference Manual and I'm about done with the User Manual).
>> The revision adds x86 works AND incorporates a bunch of stuff from the
>> release notes that have never made it to the manual.  [I've been doing
>> lots of doc review lately.]
>
> Can you reveal anything about how far out Basic for VMS x86-64 is?
>
> 1 day? 1 week? 1 month? 1 quarter?

Closer to 1 quarter than one month.

--

--- Rob

On 13/01/2024 16:52, Robert A. Brooks wrote:
> On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
>> On 1/12/2024 4:20 PM, John Reagan wrote:
>>> - And the online Pascal docs will be updated soon (I just finished the
>>> review of the Reference Manual and I'm about done with the User Manual).
>>> The revision adds x86 works AND incorporates a bunch of stuff from the
>>> release notes that have never made it to the manual.  [I've been doing
>>> lots of doc review lately.]
>>
>> Can you reveal anything about how far out Basic for VMS x86-64 is?
>>
>> 1 day? 1 week? 1 month? 1 quarter?
>
> Closer to 1 quarter than one month.
>

Oh Goody! Will it come with LSE?

--
Chris

On 1/13/2024 7:05 PM, Chris Townley wrote:
> On 13/01/2024 16:52, Robert A. Brooks wrote:
>> On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
>>> On 1/12/2024 4:20 PM, John Reagan wrote:
>>>> - And the online Pascal docs will be updated soon (I just finished the
>>>> review of the Reference Manual and I'm about done with the User Manual).
>>>> The revision adds x86 works AND incorporates a bunch of stuff from the
>>>> release notes that have never made it to the manual.  [I've been doing
>>>> lots of doc review lately.]
>>>
>>> Can you reveal anything about how far out Basic for VMS x86-64 is?
>>>
>>> 1 day? 1 week? 1 month? 1 quarter?
>>
>> Closer to 1 quarter than one month.
>>
>
> Oh Goody! Will it come with LSE?

They are unrelated.

LSE still has some issues with exception handling. The problems are
somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.

It's on my to-do list, but it's not at the top right now, although
it's close.

--

--- Rob

On 14/01/2024 05:47, Robert A. Brooks wrote:
> On 1/13/2024 7:05 PM, Chris Townley wrote:
>> On 13/01/2024 16:52, Robert A. Brooks wrote:
>>> On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
>>>> On 1/12/2024 4:20 PM, John Reagan wrote:
>>>>> - And the online Pascal docs will be updated soon (I just finished the
>>>>> review of the Reference Manual and I'm about done with the User
>>>>> Manual).
>>>>> The revision adds x86 works AND incorporates a bunch of stuff from the
>>>>> release notes that have never made it to the manual.  [I've been doing
>>>>> lots of doc review lately.]
>>>>
>>>> Can you reveal anything about how far out Basic for VMS x86-64 is?
>>>>
>>>> 1 day? 1 week? 1 month? 1 quarter?
>>>
>>> Closer to 1 quarter than one month.
>>>
>>
>> Oh Goody! Will it come with LSE?
>
> They are unrelated.
>
> LSE still has some issues with exception handling.  The problems are
> somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.
>
> It's on my to-do list, but it's not at the top right now, although
> it's close.
>

Thanks, I will await it

--
Chris

Robert A. Brooks submitted this idea :
> On 1/13/2024 7:05 PM, Chris Townley wrote:
>> On 13/01/2024 16:52, Robert A. Brooks wrote:
>>> On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
>>>> On 1/12/2024 4:20 PM, John Reagan wrote:
>>>>> - And the online Pascal docs will be updated soon (I just finished the
>>>>> review of the Reference Manual and I'm about done with the User Manual).
>>>>> The revision adds x86 works AND incorporates a bunch of stuff from the
>>>>> release notes that have never made it to the manual.  [I've been doing
>>>>> lots of doc review lately.]
>>>>
>>>> Can you reveal anything about how far out Basic for VMS x86-64 is?
>>>>
>>>> 1 day? 1 week? 1 month? 1 quarter?
>>>
>>> Closer to 1 quarter than one month.
>>>
>>
>> Oh Goody! Will it come with LSE?
>
> They are unrelated.
>
> LSE still has some issues with exception handling. The problems are
> somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.
>
> It's on my to-do list, but it's not at the top right now, although
> it's close.

Oh, if we speak about DECset, what about the other products ? PCA being
essentially an alternate debugger, it might cause some issues too,
right ?

--
Marc Van Dyck

On 2024-01-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 12 Jan 2024 13:34:53 -0000 (UTC), Simon Clubley wrote:
>
>> For security reasons, I would have preferred to see that as a prepared
>> statement instead of as a concatenated SQL statement.
>
> Feel free to show us how you would write it as same. Can your prepared-
> statement system cope with variable numbers of fields? Variable field
> names? Variable operator selections? All these were present in the
> example.

I have _never_ had the need to do that. In the real world, you know what
data you want to read or update, and with what selection criteria, at the
point you write such code.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/15/2024 3:13 AM, Marc Van Dyck wrote:
> Robert A. Brooks submitted this idea :

>> LSE still has some issues with exception handling.  The problems are
>> somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.
>>
>> It's on my to-do list, but it's not at the top right now, although
>> it's close.
>
> Oh, if we speak about DECset, what about the other products ? PCA being
> essentially an alternate debugger, it might cause some issues too,
> right ?

PCA will be a bit of a challenge, unrelated to LSE.

--

--- Rob

On 1/15/2024 8:21 AM, Simon Clubley wrote:
> On 2024-01-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Fri, 12 Jan 2024 13:34:53 -0000 (UTC), Simon Clubley wrote:
>>
>>> For security reasons, I would have preferred to see that as a prepared
>>> statement instead of as a concatenated SQL statement.
>>
>> Feel free to show us how you would write it as same. Can your prepared-
>> statement system cope with variable numbers of fields? Variable field
>> names? Variable operator selections? All these were present in the
>> example.
>
> I have _never_ had the need to do that. In the real world, you know what
> data you want to read or update, and with what selection criteria, at the
> point you write such code.

Typical criteria are static.

But if if one need dynamic criteria then there are also ways.

The COALESCE trick is quite common.

But as a fallback then it is still possible to build a
SQL string with placeholder markers dynamically, prepare
that and specify parameters.

The extendable string template mechanism added
to Java in version 21 (preview) can be used pretty
nifty.

Code snippet:

private static void test(Connection con, String f2) throws
SQLException {
PreparedStatementFormatter pstmtfmt = new
PreparedStatementFormatter(con);
try(PreparedStatement pstmt = pstmtfmt."SELECT COUNT(*) FROM t1
WHERE f2 = \{f2}") {
try(ResultSet rs = pstmt.executeQuery()) {
rs.next();
System.out.println(rs.getInt(1));
}
}
}

Arne

On Mon, 15 Jan 2024 13:21:25 -0000 (UTC), Simon Clubley wrote:

> On 2024-01-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Fri, 12 Jan 2024 13:34:53 -0000 (UTC), Simon Clubley wrote:
>>
>>> For security reasons, I would have preferred to see that as a prepared
>>> statement instead of as a concatenated SQL statement.
>>
>> Feel free to show us how you would write it as same. Can your prepared-
>> statement system cope with variable numbers of fields? Variable field
>> names? Variable operator selections? All these were present in the
>> example.
>
> I have _never_ had the need to do that.

That was a real-world example. You must never have had the need to create
interactive query functions, then. That’s not the only example of that
kind of code I have written for clients. Did you note the ability to
choose what kind of comparison (less than, equals, greater than) to
perform against date fields? Try doing that with your “prepared
statements”.

business apps use DIBOL - Synegy DBL ...

On 2/20/2024 6:15 PM, smartbuck wrote:
> business apps use DIBOL - Synegy DBL ...

Business apps on VMS are pretty diverse language wise.

Cobol, Basic, Pascal, Dibol/DBL, PL/I. I suspect even some
Fortran despite the language not being a super obvious
choice for that purpose.

Newer business apps: C. Even newer: C++. Only 20 years
old: maybe Java.

Arne