On 8/15/21 2:02 PM, Arne Vajhøj wrote:
> On 8/15/2021 1:28 PM, kemain.nospam@gmail.com wrote:
>>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of VAXman---- via
>>> Info-vax
>>> In article <sf3k2f$re3$1@gioia.aioe.org>,
>>> helbig@asclothestro.multivax.de
>>> (Phillip Helbig (undress to reply)) writes:
>>>> It is still used in the financial industry, for instance.  And, yes,
>>>> people are writing new COBOL code.
>>>
>>> I have two clients that are both writing COBOL for aerospace
>>> logistics and
>> on
>>> VMS too.
>>>
>>> --
>>> VAXman- A Bored Certified VMS Kernel Mode Hacker
>>> VAXman(at)TMESIS(dot)ORG
>>>
>>> I speak to machines with the voice of humanity.
>>
>> Yep, I know of one US-Canada Customs 24x7 critical environment that is
>> based
>> on OpenVMS Cobol and Oracle Rdb.
>>
>> If the App is down, trucks stop at the border.
>
> It is probably a general characteristics for Cobol
> applications today that:
> 1) they were created many decades ago

COBOL programs are still being created today.

> 2) they do something  really impotant

That part is definitely true. Like all of the DOD Payroll
(including retirees!). :-)

>
>> Mostly mainframe, but seems like lots of Cobol:
>> https://www.adzuna.ca/search?q=cobol&w=Canada
>
> 101 Cobol jobs in Canada.
>
> (but for comparison 6392 PHP, 6328 Python, 6146 Java,
> 3088 C#, 2856 C++, 341 Kotlin, 242 Groovy, 151 Rust,
> 71 VB.NET, 11 Fortran, 5 PL/I)
>

And, how many of those PHP, Python, Java, C++, C# are just modern
boilerplate? The job may require one or none of them. I have seen
jobs for web designers list dozens of languages some of which would
never be used on the web.

I still think the surge in COBOL job announcements has a lot to
do COVID work from home people who have decided they do not want
to go back to the office again. And the general belief about the
people doing COBOL has long been that they are all of retirement
age anyway.

bill

On 8/15/2021 3:58 PM, kemain.nospam@gmail.com wrote:
> Interesting article on COBOL from 2017:
> <https://www.eweek.com/it-management/why-new-ceo-will-keep-cobol-a-key-focus
> -of-micro-focus/>
> "“Forty years ago, Micro Focus had COBOL, predominately mainframe COBOL, and
> helped in the development of COBOL applications,” Hsu said. “Today, COBOL is
> still one of the largest assets in the portfolio, and it’s growing.
>
> “Mission-critical applications in COBOL still run most of the major at-scale
> transaction systems, such as credit-card processing, large travel logistics,
> and so on. What Micro Focus has done is innovate in COBOL to make it
> mobile-accessible, cloud deployable and deployable in a distributed model.”

Those with large mainframe COBOL environments can go 3 ways:
- keep the mainframe+COBOL and innovate on new applications
- keep the COBOL code but migrate it to Windows/Linux on x86-64
platform
- replace the entire solution likely candidates C++/Java on
Linux

Most go for the first dash.

But the other two happen.

MicroFocus provide COBOL for the second dash. Their compiler
supports native Windows, native Linux, .NET, JVM etc.

But there are other as well. Fujitsu, GT and RainCode has COBOL
for .NET as well.

Maybe slightly surprising but Windows and .NET seems pretty
popular with those moving their COBOL applications to
new platform.

Arne

On 8/15/2021 6:30 PM, Bill Gunshannon wrote:
> On 8/15/21 2:02 PM, Arne Vajhøj wrote:
>> On 8/15/2021 1:28 PM, kemain.nospam@gmail.com wrote:
>>> Yep, I know of one US-Canada Customs 24x7 critical environment that
>>> is based
>>> on OpenVMS Cobol and Oracle Rdb.
>>>
>>> If the App is down, trucks stop at the border.
>>
>> It is probably a general characteristics for Cobol
>> applications today that:
>> 1) they were created many decades ago
>
> COBOL programs are still being created today.

I don't think many brand new COBOL applications are created.

Existing applications get maintained and enhanced.

That may include creating new executables that interact
with existing COBOL stuff.

But if it is total from scratch, then practically
nobody will pick COBOL.

>> 2) they do something  really impotant
>
> That part is definitely true.  Like all of the DOD Payroll
> (including retirees!). :-)
>
>>
>>> Mostly mainframe, but seems like lots of Cobol:
>>> https://www.adzuna.ca/search?q=cobol&w=Canada
>>
>> 101 Cobol jobs in Canada.
>>
>> (but for comparison 6392 PHP, 6328 Python, 6146 Java,
>> 3088 C#, 2856 C++, 341 Kotlin, 242 Groovy, 151 Rust,
>> 71 VB.NET, 11 Fortran, 5 PL/I)
>>
>
> And, how many of those PHP, Python, Java, C++, C# are just modern
> boilerplate?  The job may require one or none of them.  I have seen
> jobs for web designers list dozens of languages some of which would
> never be used on the web.

There are probably some of that. But what if 33% of the
PHP/Python/Java/C# are just synonyms for "programming".
It does not change the overall picture.

If you think 95% of them are boilerplate, then you are
kidding yourself.

Arne

On 15/08/2021 20:28, kemain.nospam@gmail.com wrote:
>
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of VAXman---- via
>> Info-vax
>> Sent: August-12-21 2:10 PM
>> To: info-vax@rbnsn.com
>> Cc: VAXman-@SendSpamHere.ORG
>> Subject: Re: [Info-vax] Any stronger versions of the LMF planned ?, was:
> Re:
>> LMF Licence Generator Code
>>
>> In article <sf3k2f$re3$1@gioia.aioe.org>, helbig@asclothestro.multivax.de
>> (Phillip Helbig (undress to reply)) writes:
>>> In article <471ad39c-dbd2-401a-bf3f-9eb3ab213c77n@googlegroups.com>,
>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com>
>> writes:
>>>> On Thursday, August 12, 2021 at 2:58:11 AM UTC+12, Bill Gunshannon
>> wrote:
>>>>
>>>>> Here we are 30 years later and there is still=20 new COBOL being
>>>>> written every day.=20
>>>>
>>>> By whom, and for what?
>>>
>>> It is still used in the financial industry, for instance. And, yes,
>>> people are writing new COBOL code.
>>
>> I have two clients that are both writing COBOL for aerospace logistics and
> on
>> VMS too.
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker
>> VAXman(at)TMESIS(dot)ORG
>>
>> I speak to machines with the voice of humanity.
>
> Yep, I know of one US-Canada Customs 24x7 critical environment that is based
> on OpenVMS Cobol and Oracle Rdb.
>
> If the App is down, trucks stop at the border.
>
> Mostly mainframe, but seems like lots of Cobol:
> https://www.adzuna.ca/search?q=cobol&w=Canada
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>
>
>
>
>
Israeli Land Administration (one of the more computerised govornment departments) run several databasees on VMS running
on emulation. COBOL programs are still running, being updated and new programs written. A couple of ex-Digits a(I'm one)
for part-time maintainance, and it's been going for several decades...

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

>-----Original Message-----
>From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
>Info-vax
>Sent: August-15-21 8:36 PM
>To: info-vax@rbnsn.com
>Cc: Arne Vajhøj <arne@vajhoej.dk>
>Subject: Re: [Info-vax] Any stronger versions of the LMF planned ?, was: Re:
>LMF Licence Generator Code
>
>On 8/15/2021 6:30 PM, Bill Gunshannon wrote:
>> On 8/15/21 2:02 PM, Arne Vajhøj wrote:
>>> On 8/15/2021 1:28 PM, kemain.nospam@gmail.com wrote:
>>>> Yep, I know of one US-Canada Customs 24x7 critical environment that
>>>> is based on OpenVMS Cobol and Oracle Rdb.
>>>>
>>>> If the App is down, trucks stop at the border.
>>>
>>> It is probably a general characteristics for Cobol applications today
>>> that:
>>> 1) they were created many decades ago
>>
>> COBOL programs are still being created today.
>
>I don't think many brand new COBOL applications are created.
>
>Existing applications get maintained and enhanced.
>
>That may include creating new executables that interact with existing COBOL
>stuff.
>
>But if it is total from scratch, then practically nobody will pick COBOL.
>
>>> 2) they do something really impotant
>>
>> That part is definitely true. Like all of the DOD Payroll (including
>> retirees!). :-)
>>
>>>
>>>> Mostly mainframe, but seems like lots of Cobol:
>>>> https://www.adzuna.ca/search?q=cobol&w=Canada
>>>
>>> 101 Cobol jobs in Canada.
>>>
>>> (but for comparison 6392 PHP, 6328 Python, 6146 Java,
>>> 3088 C#, 2856 C++, 341 Kotlin, 242 Groovy, 151 Rust,
>>> 71 VB.NET, 11 Fortran, 5 PL/I)
>>>
>>
>> And, how many of those PHP, Python, Java, C++, C# are just modern
>> boilerplate? The job may require one or none of them. I have seen
>> jobs for web designers list dozens of languages some of which would
>> never be used on the web.
>
>There are probably some of that. But what if 33% of the PHP/Python/Java/C#
>are just synonyms for "programming".
>It does not change the overall picture.
>
>If you think 95% of them are boilerplate, then you are kidding yourself.
>
>Arne

A huge part of the value of a programmer is the understanding of custom business logic, company standards, culture etc.

You do not get this with off the street programmers that know all of the latest buzz words or latest "hot off the press" programming languages being touted by Universities.

Many (albeit not enough) companies want programmers that have experience and understand the company business policies and practices.

Hence, new programs do often get created in whatever language these experienced programmers are familiar with. In many cases, senior mgmt. will not ask "what language will you implement this new program in?", but rather "when will it be ready for testing?"

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On Sunday, August 15, 2021 at 12:46:16 PM UTC+12, Arne Vajhøj wrote:
>
> In Python something like:
>
> sqlstr = 'SELECT name1,name2 FROM pairs'
> param = []
> if any(activeconditions):
> sqlstr = sqlstr + ' WHERE ' + ' AND '.join(map(lambda item:
> item[0] + '=?', activeconditions))
> param = list(map(lambda item: item[1], activeconditions))
> c.execute(sqlstr, param)
> Single static SQL using the coalesce trick and sending over NULL
> for not used parameters means to use a fixed SQL string like:
>
> ... WHERE field1 = COLALESCE(?,field2) AND field2 = COLALESCE(?,field2) ...
>
> and send over values for all fields but NULL for those fields not to be
> used.
>
> In Python something like:
>
> sqlstr = 'SELECT name1,name2 FROM pairs WHERE name1 =
> COALESCE(?,name1) AND name2 = COALESCE(?,name2)'
> allfields = ['name1', 'name2']
> param = []
> for f in allfields:
> param.append(conditions[f])
> c.execute(sqlstr, param)
>
> In VMS COBOL something like:
>
> 01 NAME1 PIC X(32).
> 01 NAME2 PIC X(32).
> 01 NAME1PRES PIC S9.
> 01 FINDNAME1 PIC X(32).
> 01 NAME2PRES PIC S9.
> 01 FINDNAME2 PIC X(32).
> EXEC SQL DECLARE curs CURSOR FOR SELECT name1,name2 FROM pairs WHERE
> name1 = COALESCE(:findname1:name1pres,name1) AND name2 =
> COALESCE(:findname2:name2pres,name2) END-EXEC.
> ...
> EXEC SQL OPEN curs END-EXEC
> ...
> EXEC SQL CLOSE curs END-EXEC.

At least you get points for trying. Notice your code is already about an order of magnitude larger than mine, and liable to increase even more. Consider how you would add another search field: you have to add it in 3 places in the Python version, and is it actually 6 places in the COBOL one?!?

Remember Fred Brooks’ dictum about “10 lines of code per day”? No wonder COBOL programmers have such low productivity ...

On 2021-08-18, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>
> At least you get points for trying. Notice your code is already about an order of magnitude larger than mine, and liable to increase even more. Consider how you would add another search field: you have to add it in 3 places in the Python version, and is it actually 6 places in the COBOL one?!?
>
> Remember Fred Brooks? dictum about ?10 lines of code per day?? No wonder COBOL programmers have such low productivity ...

Lawrence, there are two things you might be missing that makes COBOL
much more suitable than your scripting languages in mission critical
production use.

1) Can you guarantee that you will be able to get your code running
on the compilers, operating systems and the versions of the scripting
languages available 10 or 20 years from now ?

Part of that is using languages that have international standards
for them so compilers are created against those standards. When
new versions of the standards are available, you can still compile
your code against the older versions of those standards if on the
rare occasion there have been incompatible changes.

COBOL can be considered to meet these tests. Can your scripting
languages ?

2) Can your scripting languages handle the hideously large transaction
rates that some COBOL code is currently required to work with ?

For the record, I use scripting languages for all kinds of things,
including the scripting languages you clearly like. However, using them
to replace COBOL code is not one of the things I would consider using
them for.

Managers don't give a damn about writing more compact code unless
it gives major new functionality, which your alternative code does not.

They do care however about making sure that code will still work in
the environments of tomorrow and that the code will run reliably in
high transaction rate mission critical environments today.

Simon.

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

On Wed, 18 Aug 2021 12:15:14 +0000, Simon Clubley wrote:

> 1) Can you guarantee that you will be able to get your code running on
> the compilers, operating systems and the versions of the scripting
> languages available 10 or 20 years from now ?

Indeed. See 'Python'!

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On 8/18/2021 4:27 AM, Lawrence D’Oliveiro wrote:
> On Sunday, August 15, 2021 at 12:46:16 PM UTC+12, Arne Vajhøj wrote:
>> In Python something like:
>> sqlstr = 'SELECT name1,name2 FROM pairs'
>> param = []
>> if any(activeconditions):
>> sqlstr = sqlstr + ' WHERE ' + ' AND '.join(map(lambda item:
>> item[0] + '=?', activeconditions))
>> param = list(map(lambda item: item[1], activeconditions))
>> c.execute(sqlstr, param)
>> Single static SQL using the coalesce trick and sending over NULL
>> for not used parameters means to use a fixed SQL string like:
>>
>> ... WHERE field1 = COLALESCE(?,field2) AND field2 = COLALESCE(?,field2) ...
>>
>> and send over values for all fields but NULL for those fields not to be
>> used.
>>
>> In Python something like:
>>
>> sqlstr = 'SELECT name1,name2 FROM pairs WHERE name1 =
>> COALESCE(?,name1) AND name2 = COALESCE(?,name2)'
>> allfields = ['name1', 'name2']
>> param = []
>> for f in allfields:
>> param.append(conditions[f])
>> c.execute(sqlstr, param)
>>
>> In VMS COBOL something like:
>>
>> 01 NAME1 PIC X(32).
>> 01 NAME2 PIC X(32).
>> 01 NAME1PRES PIC S9.
>> 01 FINDNAME1 PIC X(32).
>> 01 NAME2PRES PIC S9.
>> 01 FINDNAME2 PIC X(32).
>> EXEC SQL DECLARE curs CURSOR FOR SELECT name1,name2 FROM pairs WHERE
>> name1 = COALESCE(:findname1:name1pres,name1) AND name2 =
>> COALESCE(:findname2:name2pres,name2) END-EXEC.
>> ...
>> EXEC SQL OPEN curs END-EXEC
>> ...
>> EXEC SQL CLOSE curs END-EXEC.
>
> At least you get points for trying. Notice your code is already about an order of magnitude larger than mine,

It is not.

The Python code is about the same (your code did not
show the SQL or execute, but that does not mean that
they are not needed).

The COBOL code is more lines. For one reason: everything need to be
declared with a type. You may not like that, but I think that the
COBOL programmers like that.

> Consider how you would add another search field: you have to add it in 3 places in the Python version, and is it actually 6 places in the COBOL one?!?

Not quite accurate.

The Python dynamic example does not use fieldnames in the code at all.

The Python static example will need an extra WHERE condition plus an
update of the list of field names - the list is not strictly necessary
but avoid the dependency on the order of fields, and when it is next to
the SQL then it should not be a problem.

The COBOL example will also need an extra WHERE condition and
will need both value and NULL indicator to be declared.

Arne

On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj wrote:

> The COBOL code is more lines. For one reason: everything need to be
> declared with a type. You may not like that, but I think that the
> COBOL programmers like that.

And it’s worse than that. COBOL’s fixed-length strings open up a whole new potential avenue of vulnerabilities, in the form of buffer-overflow attacks.

Another thing Fred Brooks said had to do with software systems that became so large and so complex that attempts to fix bugs would only introduce new ones. You managed to reach that point in just about a dozen lines of COBOL.

On Thu, 19 Aug 2021 15:33:09 -0700, Lawrence D’Oliveiro wrote:

> On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj wrote:
>
>> The COBOL code is more lines. For one reason: everything need to be
>> declared with a type. You may not like that, but I think that the COBOL
>> programmers like that.
>
> And it’s worse than that. COBOL’s fixed-length strings open up a whole
> new potential avenue of vulnerabilities, in the form of buffer-overflow
> attacks.

Nonsense. You think there aren't run time checks?

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On 8/19/21 6:33 PM, Lawrence D’Oliveiro wrote:
> On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj wrote:
>
>> The COBOL code is more lines. For one reason: everything need to be
>> declared with a type. You may not like that, but I think that the
>> COBOL programmers like that.
>
> And it’s worse than that. COBOL’s fixed-length strings open up a whole new potential avenue of vulnerabilities, in the form of buffer-overflow attacks.

Care to provide an example? Unlike C COBOL doesn't have null
terminated strings.

>
> Another thing Fred Brooks said had to do with software systems that became so large and so complex that attempts to fix bugs would only introduce new ones. You managed to reach that point in just about a dozen lines of COBOL.
>

I have worked on COBOL programs that were thousands of lines long and
they were easier to work on than a dozen lines of PHP.

bill

On Thursday, August 19, 2021 at 6:33:11 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj wrote:
>
> > The COBOL code is more lines. For one reason: everything need to be
> > declared with a type. You may not like that, but I think that the
> > COBOL programmers like that.
> And it’s worse than that. COBOL’s fixed-length strings open up a whole new potential avenue of vulnerabilities, in the form of buffer-overflow attacks.
>
> Another thing Fred Brooks said had to do with software systems that became so large and so complex that attempts to fix bugs would only introduce new ones. You managed to reach that point in just about a dozen lines of COBOL.

You seem to have something against Cobol for some reason. There are limitations to all languages. When used in the right environment, each language has its strengths.
Cobol by its very nature tends to be somewhat self documenting. This can be a pain as it often requires more typing, but that is a one time thing. Maintaining Cobol is probably the easiest when compared to many other languages most notably when comments are lacking.

Is Cobol the right language for all business applications, NO! Is it good for financial applications, YES. These tend to be batch oriented in many cases and this is where Cobol shines. Even with database access, Cobol applications are common backends for other language based front-ends. Even the recent issues in the states with the "lack" of Cobol programmers, it turns out that the majority of the issues were NOT with the backend processing but with the web facing interfaces.

Dan

On 8/19/2021 6:33 PM, Lawrence D’Oliveiro wrote:
> On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj
> wrote:
>> The COBOL code is more lines. For one reason: everything need to
>> be declared with a type. You may not like that, but I think that
>> the COBOL programmers like that.
>
> And it’s worse than that. COBOL’s fixed-length strings open up a
> whole new potential avenue of vulnerabilities, in the form of
> buffer-overflow attacks.

Nope.

Fixed length strings are not a problem.

Strings with no concept of length are a problem.

In VMS COBOL if you try to stuff more data into the
variable than there is space for, then data gets
truncated to what there is space for.

That applies to both assigning values to the search values
and for storing database data in output variables.

Tested with default compiler settings on VMS Alpha.

Arne

Den 2021-08-20 kl. 00:33, skrev Lawrence D’Oliveiro:
> On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj wrote:
>
>> The COBOL code is more lines. For one reason: everything need to be
>> declared with a type. You may not like that, but I think that the
>> COBOL programmers like that.
>
> And it’s worse than that. COBOL’s fixed-length strings open up a whole new potential avenue of vulnerabilities, in the form of buffer-overflow attacks.

You clearly doesn't have a clue. Cobols fixed lenght strings *prevents*
buffer overflow issues such as can bee seen in other languages that has
null-terminated "strings".

On 8/20/2021 2:41 AM, Jan-Erik Söderholm wrote:
> Den 2021-08-20 kl. 00:33, skrev Lawrence D’Oliveiro:
>> On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj wrote:
>>> The COBOL code is more lines. For one reason: everything need to be
>>> declared with a type. You may not like that, but I think that the
>>> COBOL programmers like that.
>>
>> And it’s worse than that. COBOL’s fixed-length strings open up a whole
>> new potential avenue of vulnerabilities, in the form of
>> buffer-overflow attacks.
>
> You clearly doesn't have a clue. Cobols fixed lenght strings *prevents*
> buffer overflow issues such as can bee seen in other languages that has
> null-terminated "strings".

I will claim that the determining factor is neither fixed length or
null termination - the determining factor is whether length are
always present together with the string.

In VMS calling standard: that strings are passed by descriptor
instead of by reference.

Fortran, Cobol, Pascal fixed length strings are passed
by descriptor. The language RTL can handle things.

Pascal, Basic variable length strings are passed by descriptor.
The language RTL can handle things.

C "strings" (char array using null termination) are passed by
reference. And unless length is passed as a separate argument
and programmer explicit use it properly then bad things can happen,

So there are no difference in definitions for normal code.

The difference only becomes relevant when changing the
default pass by descriptor to pass by reference. Then
a non-C non-null-terminated string becomes dangerous
as well.

Arne

Den 2021-08-20 kl. 15:20, skrev Arne Vajhøj:
> On 8/20/2021 2:41 AM, Jan-Erik Söderholm wrote:
>> Den 2021-08-20 kl. 00:33, skrev Lawrence D’Oliveiro:
>>> On Thursday, August 19, 2021 at 6:49:24 AM UTC+12, Arne Vajhøj wrote:
>>>> The COBOL code is more lines. For one reason: everything need to be
>>>> declared with a type. You may not like that, but I think that the
>>>> COBOL programmers like that.
>>>
>>> And it’s worse than that. COBOL’s fixed-length strings open up a whole
>>> new potential avenue of vulnerabilities, in the form of buffer-overflow
>>> attacks.
>>
>> You clearly doesn't have a clue. Cobols fixed lenght strings *prevents*
>> buffer overflow issues such as can bee seen in other languages that has
>> null-terminated "strings".
>
> I will claim that the determining factor is neither fixed length or
> null termination - the determining factor is whether length are
> always present together with the string.
>
> In VMS calling standard: that strings are passed by descriptor
> instead of by reference.
>
> Fortran, Cobol, Pascal fixed length strings are passed
> by descriptor. The language RTL can handle things.
>
> Pascal, Basic variable length strings are passed by descriptor.
> The language RTL can handle things.
>
> C "strings" (char array using null termination) are passed by
> reference. And unless length is passed as a separate argument
> and programmer explicit use it properly then bad things can happen,
>
> So there are no difference in definitions for normal code.
>
> The difference only becomes relevant when changing the
> default pass by descriptor to pass by reference. Then
> a non-C non-null-terminated string becomes dangerous
> as well.
>
> Arne
>
>

Still, it is very hard to "overwrite" a PIC X(nnn) variable using
pure Cobol code.

On 8/20/2021 9:38 AM, Jan-Erik Söderholm wrote:
> Den 2021-08-20 kl. 15:20, skrev Arne Vajhøj:
>> I will claim that the determining factor is neither fixed length or
>> null termination - the determining factor is whether length are
>> always present together with the string.
>>
>> In VMS calling standard: that strings are passed by descriptor
>> instead of by reference.
>>
>> Fortran, Cobol, Pascal fixed length strings are passed
>> by descriptor. The language RTL can handle things.
>>
>> Pascal, Basic variable length strings are passed by descriptor.
>> The language RTL can handle things.
>>
>> C "strings" (char array using null termination) are passed by
>> reference. And unless length is passed as a separate argument
>> and programmer explicit use it properly then bad things can happen,
>>
>> So there are no difference in definitions for normal code.
>>
>> The difference only becomes relevant when changing the
>> default pass by descriptor to pass by reference. Then
>> a non-C non-null-terminated string becomes dangerous
>> as well.
>
> Still, it is very hard to "overwrite" a PIC X(nnn) variable using
> pure Cobol code.

Yes.

Passing strings by reference is probably mostly a calling
C or Macro-32 problem.

I know that Pascal only allows it for external routines.

Example:

$ type s1.pas
program s1(input, output);

procedure gets(var s : packed array [$u1..$u2:integer] of char);

begin
readln(s);
end;

var
s : packed array [1..32] of char;

begin
s := ' ';
gets(s);
writeln(s);
end.
$ pas s1
$ link s1
$ run s1
1234567890
1234567890
$ run s1
12345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012
$ type s2.pas
program s2(input, output);

[external('decc$gets')]
procedure gets(%REF s : packed array [$u1..$u2:integer] of char); external;

var
s : packed array [1..32] of char;

begin
s := ' ';
gets(s);
writeln(s);
end.
$ pas s2
$ link s2
$ run s2
1234567890
1234567890
$ run s2
12345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=3039383736353430, PC=3039383736353430, PS=0000001B

Improperly handled condition, image exit forced by last chance handler.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
3039383736353430
3039383736353430
000000000000001B

Register dump:
R0 = 0000000000000001 R1 = 000000000458D021 R2 = 3837363534333231
R3 = 000000007AFC522A R4 = 000000007FFCF814 R5 = 000000007FFCF934
R6 = 000000007FFA0ED0 R7 = 000000007FFA0ED0 R8 = 000000007FF9CDE8
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
R12 = 000000007FFCDA98 R13 = FFFFFFFF81952110 R14 = 0000000000000000
R15 = 000000007AF0C9E0 R16 = FFFFFFFFFFFEFFFF R17 = 0000000000054070
R18 = 0000000000000000 R19 = 000000007FFD0010 R20 = 00000000000187BC
R21 = 0000000000000000 R22 = 0000000000000001 R23 = 0000000000010001
R24 = 0000000000010001 R25 = 0000000000000001 R26 = 3039383736353433
R27 = FFFFFFFF818011E0 R28 = FFFFFFFF802BD06C R29 = 3635343332313039
SP = 000000007AE27AF0 PC = 3039383736353430 PS = 300000000000001B

Arne

On Wednesday, August 11, 2021 at 8:13:45 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Wednesday, August 11, 2021 at 11:31:29 PM UTC+12, Joukj wrote:
> > Ever tried to buy a laptop for home use without Windows installed in order to
> > run Linux? I never succeeded.
> I have one, from System76. You can get “white box” laptops (with no OS installed) from companies like Clevo. That’s what System76 does; they then add their own hardware/BIOS tweaks (like disabling that Intel system management engine thingie), and even provide their own “Pop!OS” spin of Ubuntu as a preinstallation option.
>
> Me, I find Debian Unstable runs on it fine. ;)

Dell also sells linux laptops without the MS license cost associated with them. Commercially.

https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/linux-ubuntu?appliedRefinements=10673&gacd=9646510-1029-5761040-266791111-0&dgc=st&gclid=CjwKCAjwyIKJBhBPEiwAu7zll4jXAXSAXIZvKU4VrwJjhdG06NosOim1RBxhLEFq6Zk_X85-FQOkiRoCFTsQAvD_BwE&gclsrc=aw.ds&nclid=7-RNJphffOpQNUYMUJntlBv-NqV-da2sZiTsnfYMyeoe8IsrPyn--hjaDaVvPNIG

And has for almost 10 years at this point...... It's stupid easy to get a commercial laptop that ships with linux....

Den 2021-08-21 kl. 13:14, skrev Gary Sparkes:
> On Wednesday, August 11, 2021 at 8:13:45 PM UTC-4, Lawrence D’Oliveiro wrote:
>> On Wednesday, August 11, 2021 at 11:31:29 PM UTC+12, Joukj wrote:
>>> Ever tried to buy a laptop for home use without Windows installed in order to
>>> run Linux? I never succeeded.
>> I have one, from System76. You can get “white box” laptops (with no OS installed) from companies like Clevo. That’s what System76 does; they then add their own hardware/BIOS tweaks (like disabling that Intel system management engine thingie), and even provide their own “Pop!OS” spin of Ubuntu as a preinstallation option.
>>
>> Me, I find Debian Unstable runs on it fine. ;)
>
>
> Dell also sells linux laptops without the MS license cost associated with them. Commercially.
>
> https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/linux-ubuntu?appliedRefinements=10673&gacd=9646510-1029-5761040-266791111-0&dgc=st&gclid=CjwKCAjwyIKJBhBPEiwAu7zll4jXAXSAXIZvKU4VrwJjhdG06NosOim1RBxhLEFq6Zk_X85-FQOkiRoCFTsQAvD_BwE&gclsrc=aw.ds&nclid=7-RNJphffOpQNUYMUJntlBv-NqV-da2sZiTsnfYMyeoe8IsrPyn--hjaDaVvPNIG
>
> And has for almost 10 years at this point...... It's stupid easy to get a commercial laptop that ships with linux....
>

It would be interesting to see some sale statistics.
They tried this in Sweden some years ago, but after half
a year or so they was gone due to close to no sales at all.

On 21/08/2021 12:14, Gary Sparkes wrote:
> On Wednesday, August 11, 2021 at 8:13:45 PM UTC-4, Lawrence D’Oliveiro wrote:
>> On Wednesday, August 11, 2021 at 11:31:29 PM UTC+12, Joukj wrote:
>>> Ever tried to buy a laptop for home use without Windows installed in order to
>>> run Linux? I never succeeded.
>> I have one, from System76. You can get “white box” laptops (with no OS installed) from companies like Clevo. That’s what System76 does; they then add their own hardware/BIOS tweaks (like disabling that Intel system management engine thingie), and even provide their own “Pop!OS” spin of Ubuntu as a preinstallation option.
>>
>> Me, I find Debian Unstable runs on it fine. ;)
>
>
> Dell also sells linux laptops without the MS license cost associated with them. Commercially.
>
> https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/linux-ubuntu?appliedRefinements=10673&gacd=9646510-1029-5761040-266791111-0&dgc=st&gclid=CjwKCAjwyIKJBhBPEiwAu7zll4jXAXSAXIZvKU4VrwJjhdG06NosOim1RBxhLEFq6Zk_X85-FQOkiRoCFTsQAvD_BwE&gclsrc=aw.ds&nclid=7-RNJphffOpQNUYMUJntlBv-NqV-da2sZiTsnfYMyeoe8IsrPyn--hjaDaVvPNIG
>
> And has for almost 10 years at this point...... It's stupid easy to get a commercial laptop that ships with linux....
>
Well it looks like there are three, so not really a lot of choice
compared to Dells range.

Well I am not sure you get the real value of the saving. From what I can
see its $130 cheaper than the windows version. This retail price of
Windows/10 pro in the UK is nearer $300.

.... and whilst DELL might offer Linux laptops in the USA they don't in
the UK. As far as I can tell neither do Lenovo, HP or Acer.....

Dave

On 21/08/2021 20:27, David Wade wrote:
> On 21/08/2021 12:14, Gary Sparkes wrote:
>> On Wednesday, August 11, 2021 at 8:13:45 PM UTC-4, Lawrence D’Oliveiro
>> wrote:
>>> On Wednesday, August 11, 2021 at 11:31:29 PM UTC+12, Joukj wrote:
>>>> Ever tried to buy a laptop for home use without Windows installed in
>>>> order to
>>>> run Linux? I never succeeded.
>>> I have one, from System76. You can get “white box” laptops (with no
>>> OS installed) from companies like Clevo. That’s what System76 does;
>>> they then add their own hardware/BIOS tweaks (like disabling that
>>> Intel system management engine thingie), and even provide their own
>>> “Pop!OS” spin of Ubuntu as a preinstallation option.
>>>
>>> Me, I find Debian Unstable runs on it fine. ;)
>>
>>
>> Dell also sells linux laptops without the MS license cost associated
>> with them. Commercially.
>>
>> https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/linux-ubuntu?appliedRefinements=10673&gacd=9646510-1029-5761040-266791111-0&dgc=st&gclid=CjwKCAjwyIKJBhBPEiwAu7zll4jXAXSAXIZvKU4VrwJjhdG06NosOim1RBxhLEFq6Zk_X85-FQOkiRoCFTsQAvD_BwE&gclsrc=aw.ds&nclid=7-RNJphffOpQNUYMUJntlBv-NqV-da2sZiTsnfYMyeoe8IsrPyn--hjaDaVvPNIG
>>
>>
>> And has for almost 10 years at this point...... It's stupid easy to
>> get a commercial laptop that ships with linux....
>>
> Well it looks like there are three, so not really a lot of choice
> compared to Dells range.
>
> Well I am not sure you get the real value of the saving. From what I can
> see its $130 cheaper than the windows version. This retail price of
> Windows/10 pro in the UK is nearer $300.
>
> ... and whilst DELL might offer Linux laptops in the USA they don't in
> the UK. As far as I can tell neither do Lenovo, HP or Acer.....
>
> Dave

But Dell wouldn't pay anything like $300 for an OEM install...

--
Chris

On 8/21/2021 3:58 PM, Chris Townley wrote:
> On 21/08/2021 20:27, David Wade wrote:
>> On 21/08/2021 12:14, Gary Sparkes wrote:
>>> Dell also sells linux laptops without the MS license cost associated
>>> with them. Commercially.
>>>
>>> https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/linux-ubuntu?appliedRefinements=10673&gacd=9646510-1029-5761040-266791111-0&dgc=st&gclid=CjwKCAjwyIKJBhBPEiwAu7zll4jXAXSAXIZvKU4VrwJjhdG06NosOim1RBxhLEFq6Zk_X85-FQOkiRoCFTsQAvD_BwE&gclsrc=aw.ds&nclid=7-RNJphffOpQNUYMUJntlBv-NqV-da2sZiTsnfYMyeoe8IsrPyn--hjaDaVvPNIG
>>>
>>> And has for almost 10 years at this point...... It's stupid easy to
>>> get a commercial laptop that ships with linux....
>>>
>> Well it looks like there are three, so not really a lot of choice
>> compared to Dells range.
>>
>> Well I am not sure you get the real value of the saving. From what I
>> can see its $130 cheaper than the windows version. This retail price
>> of Windows/10 pro in the UK is nearer $300.
>>
>> ... and whilst DELL might offer Linux laptops in the USA they don't in
>> the UK. As far as I can tell neither do Lenovo, HP or Acer.....
>
> But Dell wouldn't pay anything like $300 for an OEM install...

Per internet rumors PC producers pay 15-25 dollar for
OEM licenses.

Arne

On Sat, 21 Aug 2021 20:27:12 +0100, David Wade wrote:

> Well I am not sure you get the real value of the saving. From what I can
> see its $130 cheaper than the windows version. This retail price of
> Windows/10 pro in the UK is nearer $300.

Well, if you're looking at buying an OEM version (comparing apples with
apples) it's more like $180.

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On Friday, August 20, 2021 at 1:31:54 PM UTC+12, Arne Vajhøj wrote:

> Fixed length strings are not a problem.

I laugh at your pathetic fixed-length buffers.

> Strings with no concept of length are a problem.

I laugh at your ignorance of dynamic languages like Python. And I’d like to see you stuff something like this

cu.execute \
(
"insert into font_features(filename, fileindex, tag) values "
+
", ".join(("(?, ?, ?)",) * len(feature_tags)),
sum
(
(
(
fontfilename,
faceindex,
HB.UNTAG(tag, True).decode(),
)
for tag in feature_tags
),
()
)
)

in your COBOL pipe, and smoke it.

(Taken from <https://github.com/ldo/python_fontconfig_examples/blob/master/collect_opentype_fonts>.)