=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> wrote:
>On Friday, August 20, 2021 at 1:31:54 PM UTC+12, Arne Vajh=C3=B8j wrote:
>
>> Fixed length strings are not a problem.=20
>
>I laugh at your pathetic fixed-length buffers.
>
>> Strings with no concept of length are a problem.=20

COBOL isn't a programming language. COBOL is a data description language that
has some programming features on the side. If you look at a well-written
typical COBOL program, the procedure division is a very small part of the total
length.

Silly arguments like this occur when people think of COBOL as a programming
language, and complain that it's not a good programming language. That's
not what it is at all. That's like complaining a tomato isn't good for ice
cream.

And yes, null-terminated strings are a disaster, I think we can all agree on
that. They are now available in many implementations of COBOL too, which I
think is a mistake.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

torsdag 5 augusti 2021 kl. 06:55:23 UTC+2 skrev Lawrence D’Oliveiro:
> I had a look at the original pakgen.c source from mirrors.pdp-11.ru. I get the impression somebody disassembled a bunch of VAX machine language, then did a straight transliteration into C code.
>
> So I thought I would clean it up a bit. And I managed to knock its size down by a couple hundred lines. I also wrote a Python version, which is less than half the size of the original, and also add a few features. For example, I was able to add the HARDWARE_ID, TOKEN and VERSION atttributes by guessing at their codes. So far I haven’t been able to figure out the RELEASE_DATE and TERMINATION_DATE attributes, most likely because I can’t get the right date-encoding format.

I think you are right, it easy to assume that the attributes are treated as pure ASCII strings i.e. "dd-MMM-yyyy" but I do not think that is the case.
If you you try to register a license like "license register BRYSK /release_date=14-APR-1996 /checksum=2-BFMB-KYKE-CPRA-ALRT" is say
"checksum is does not validate" but if you try to register it as "license register BRYSK /release_date=xxxxxxxx /checksum=2-BFMB-KYKE-CPRA-ALRT"
is says "invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC format" so there is reasons to believe that the time string is converted to a internal time.
The actual "invalid absolute time..." error message looks like it is derived from the lexical (!) function f$cvtime.

Also the notorious LMFGEN program takes the date arguments as "dd.mm.yyyy" according to the HELP documentation, but that is incorrect. The correct input should be "yyyy.mm.dd".
So a far out guess; the time is converted to numeric time elements (e.g $numtim) like yyyy,mm and dd. These are concatenated/summed up in some way and then CRC:ed as another license attribute.
But the error message could also be the result of an initial time string syntax check and the time value could be whatever. Good luck :-)

why did the people that created the pakgen.c did not do VERSION and RELEASE_DATE etc?
They put in a fair effort to crack everything (hard) so doing VERSION etc. must have been right at their fingers.

On Tuesday, September 21, 2021 at 7:30:42 PM UTC+12, PoBe wrote:
> So a far out guess; the time is converted to numeric time elements (e.g $numtim)
> like yyyy,mm and dd. These are concatenated/summed up in some way and then
> CRC:ed as another license attribute.
> But the error message could also be the result of an initial time string syntax check
> and the time value could be whatever. Good luck :-)

Thanks for the thoughts. Not to mention that I could have been making an off-by-one error in counting the days in my experiments. Too many variables, when all the LMFGEN oracle will tell me is “yes” or “no”. ;)

> why did the people that created the pakgen.c did not do VERSION and RELEASE_DATE etc?
> They put in a fair effort to crack everything (hard) so doing VERSION etc.. must have
> been right at their fingers.

My guess is they felt no need for time-limited or machine-limited licences. Myself, I am only trying to put these in for completeness. ;)

On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey wrote:
> COBOL isn't a programming language. COBOL is a data description language
> that has some programming features on the side. If you look at a well-written
> typical COBOL program, the procedure division is a very small part of the total
> length.

The specific question being considered here is interfacing from COBOL to SQL. COBOL was born back in the era of ISAM files, and never really adapted to the widespread adoption of SQL and relational databases. This in spite of the fact that COBOL was supposed to be a “business-oriented” language, and SQL has become rather essential to just about every kind of “business” need since the 1980s.

And yes, SQL is very much a “programming language”, whether or not you think COBOL is one.

Den 2021-09-22 kl. 10:15, skrev Lawrence D’Oliveiro:
> On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey wrote:
>> COBOL isn't a programming language. COBOL is a data description language
>> that has some programming features on the side. If you look at a well-written
>> typical COBOL program, the procedure division is a very small part of the total
>> length.
>

I think that Scott tried to make a joke there. It very much depends
on the actual application, of course, what the ratio between data
definition and procedure code is.

> The specific question being considered here is interfacing from COBOL to SQL.

VMS Cobol has the same "embedded SQL" support just as any other compiled
VMS language such C, Fortran, Basic. No difference at all.

And VMS Cobol can of course call SQLMOD routines and functions just as
any other VMS compiled language that follows the VMS Calling Standard.

So there is nothing special about "interfacing from COBOL to SQL"
that makes it stand out compared to other (compiled) languages.

If you compare with scripting languages (Python and such) there is an
differnce in that the SQL has to be compiled at runtime. A bit less
efficient then having the SQL compilation done at compile time.

> COBOL was born back in the era of ISAM files, and never really adapted to
> the widespread adoption of SQL and relational databases.

That is a complete BS, of course. As anyone really understanding
these matters understand.

> This in spite of the fact that COBOL was supposed to be a “business-oriented”
> language, and SQL has become rather essential to just about every kind of
> “business” need since the 1980s.

Yes. So? So IBM System/z Cobol code can't use DB2?

>
> And yes, SQL is very much a “programming language”, whether or not you
> think COBOL is one.
>

True. An in particular if you are into SQLMOD programming, where the
complete sorce code is just pure SQL.

In article <sietii$qmo$2@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
writes:

> Den 2021-09-22 kl. 10:15, skrev Lawrence D’Oliveiro:
> > On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey wrote:
> >> COBOL isn't a programming language. COBOL is a data description language
> >> that has some programming features on the side. If you look at a well-written
> >> typical COBOL program, the procedure division is a very small part of the total
> >> length.
> >
>
> I think that Scott tried to make a joke there. It very much depends
> on the actual application, of course, what the ratio between data
> definition and procedure code is.

Indeed. There is a huge amount of code using COBOL and SQL (much of it
with Rdb).

=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> wrote:
>On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey wrote:
>> COBOL isn't a programming language. COBOL is a data description language
>> that has some programming features on the side. If you look at a well-wri=
>tten=20
>> typical COBOL program, the procedure division is a very small part of the=
> total=20
>> length.=20
>
>The specific question being considered here is interfacing from COBOL to SQ=
>L. COBOL was born back in the era of ISAM files, and never really adapted t=
>o the widespread adoption of SQL and relational databases. This in spite of=
> the fact that COBOL was supposed to be a =E2=80=9Cbusiness-oriented=E2=80=
>=9D language, and SQL has become rather essential to just about every kind =
>of =E2=80=9Cbusiness=E2=80=9D need since the 1980s.

In the IBM/360 world, SQL code can be embedded within COBOL programs using
EXEC-SQL. There's no "interface" per se, they are all mixed up together.

If VMS does not allow this, it's a thing that should probably be added
because IBM has had it for many decades and it's very convenient.

>And yes, SQL is very much a =E2=80=9Cprogramming language=E2=80=9D, whether=
> or not you think COBOL is one.

Yes, although it's certainly not a general purpose one.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com> wrote:
>Den 2021-09-22 kl. 10:15, skrev Lawrence D’Oliveiro:
>> On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey wrote:
>>> COBOL isn't a programming language. COBOL is a data description language
>>> that has some programming features on the side. If you look at a well-written
>>> typical COBOL program, the procedure division is a very small part of the total
>>> length.
>>
>
>I think that Scott tried to make a joke there. It very much depends
>on the actual application, of course, what the ratio between data
>definition and procedure code is.

Slightly, but there is an important grain of truth in there. People need
to get their head around it because if they come from the C/fortran/perl/python
world where programs are just procedures, they will find the COBOL/RPG world
where the procedure is only a minor part of the program to be incomprehensible.
COBOL is for moving data around.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2021-09-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2021-09-22 kl. 10:15, skrev Lawrence D?Oliveiro:
>> COBOL was born back in the era of ISAM files, and never really adapted to
>> the widespread adoption of SQL and relational databases.
>
> That is a complete BS, of course. As anyone really understanding
> these matters understand.
>

Lawrence seems to like COBOL about as much as Phillip likes Linux
and non-DEC keyboards. :-)

Simon.

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

On 9/22/2021 4:15 AM, Lawrence D’Oliveiro wrote:
> On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey
> wrote:
>> COBOL isn't a programming language. COBOL is a data description
>> language that has some programming features on the side. If you
>> look at a well-written typical COBOL program, the procedure
>> division is a very small part of the total length.
>
> The specific question being considered here is interfacing from COBOL
> to SQL. COBOL was born back in the era of ISAM files, and never
> really adapted to the widespread adoption of SQL and relational
> databases. This in spite of the fact that COBOL was supposed to be a
> “business-oriented” language, and SQL has become rather essential to
> just about every kind of “business” need since the 1980s.

That does not really match reality.

SQL is very much used in Cobol.

Cobol and embedded SQL to either Oracle Rdb or Oracle DB
(Oracle Classic in traditional VMS terminology) may very well
be the most widely used RDBMS and programming language combination
on VMS.

Arne

On 9/22/2021 5:38 AM, Jan-Erik Söderholm wrote:
>> The specific question being considered here is interfacing from COBOL
>> to SQL.
>
> VMS Cobol has the same "embedded SQL" support just as any other compiled
> VMS language such C, Fortran, Basic. No difference at all.
>
> And VMS Cobol can of course call SQLMOD routines and functions just as
> any other VMS compiled language that follows the VMS Calling Standard.
>
> So there is nothing special about "interfacing from COBOL to SQL"
> that makes it stand out compared to other (compiled) languages.
>
> If you compare with scripting languages (Python and such) there is an
> differnce in that the SQL has to be compiled at runtime. A bit less
> efficient then having the SQL compilation done at compile time.

VMS Cobol and Rdb are very well covered with embedded SQL
and SQLMOD.

Other databases are not as well covered. SQLMOD is Rdb specific. And
the number of supported combinations of languages and databases
for embedded SQL is not that big compared to what is out there.

But that is not an indication that embedded SQL would not work
for those combinations. It just reflects that the IT world
in general has moved from embedded SQL towards database
independent call API's and ORM's. And people live with the
overhead (I don't think that the overhead of a call API is
significant, but with ORM a lot happens under the hood).

Arne

On 9/22/2021 8:01 AM, Scott Dorsey wrote:
> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> wrote:
>> On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey wrote:
>>> COBOL isn't a programming language. COBOL is a data description language
>>> that has some programming features on the side. If you look at a well-written
>>> typical COBOL program, the procedure division is a very small part of thetotal
>>> length.
>>
>> The specific question being considered here is interfacing from COBOL to SQL.
>> COBOL was born back in the era of ISAM files, and never really adapted to the
>> widespread adoption of SQL and relational databases. This in spite of the
>> fact that COBOL was supposed to be a =E2=80=9Cbusiness-oriented=E2=80=
>> =9D language, and SQL has become rather essential to just about every kind
>> of =E2=80=9Cbusiness=E2=80=9D need since the 1980s.
>
> In the IBM/360 world, SQL code can be embedded within COBOL programs using
> EXEC-SQL. There's no "interface" per se, they are all mixed up together.
>
> If VMS does not allow this, it's a thing that should probably be added
> because IBM has had it for many decades and it's very convenient.

It is worth noting that embedded SQL is database specific.

IBM supports embedded SQL for DB2.

Oracle supports embedded SQL for Oracle DB.

On VMS there is support for embedded SQL by at least:
- Rdb
- Oracle DB (Oracle Classic) [pending Oracle drop of any support]
- Mimer

And it is also language specific. Rdb has support for all the
traditional VMS languages, but many embedded SQL only supports
Cobol and C.

Arne

In article <sif841$1b6j$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> That does not really match reality.
>
> SQL is very much used in Cobol.
>
> Cobol and embedded SQL to either Oracle Rdb or Oracle DB
> (Oracle Classic in traditional VMS terminology) may very well
> be the most widely used RDBMS and programming language combination
> on VMS.

It is probably also the combination which generates the most profit for
those running such applications, and those are some of the biggest VMS
customers.

On 9/22/2021 8:49 AM, Arne Vajhøj wrote:
> On 9/22/2021 5:38 AM, Jan-Erik Söderholm wrote:
>>> The specific question being considered here is interfacing from COBOL
>>> to SQL.
>>
>> VMS Cobol has the same "embedded SQL" support just as any other compiled
>> VMS language such C, Fortran, Basic. No difference at all.
>>
>> And VMS Cobol can of course call SQLMOD routines and functions just as
>> any other VMS compiled language that follows the VMS Calling Standard.
>>
>> So there is nothing special about "interfacing from COBOL to SQL"
>> that makes it stand out compared to other (compiled) languages.
>>
>> If you compare with scripting languages (Python and such) there is an
>> differnce in that the SQL has to be compiled at runtime. A bit less
>> efficient then having the SQL compilation done at compile time.
>
> VMS Cobol and Rdb are very well covered with embedded SQL
> and SQLMOD.
>
> Other databases are not as well covered. SQLMOD is Rdb specific. And
> the number of supported combinations of languages and databases
> for embedded SQL is not that big compared to what is out there.
>
> But that is not an indication that embedded SQL would not work
> for those combinations. It just reflects that the IT world
> in general has moved from embedded SQL towards database
> independent call API's and ORM's. And people live with the
> overhead (I don't think that the overhead of a call API is
> significant, but with ORM a lot happens under the hood).

https://www.vajhoej.dk/arne/articles/vmsdb.html

has examples of how to access Rdb/MySQL/SQLite/Mimer on
VMS from C/Pascal/Fortran/Cobol/Java/C#/Python/PHP on
VMS/Windows/*nix (for the subset of possible combinations).

Arne

On 9/22/2021 8:11 AM, Simon Clubley wrote:
> On 2021-09-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> Den 2021-09-22 kl. 10:15, skrev Lawrence D?Oliveiro:
>>> COBOL was born back in the era of ISAM files, and never really adapted to
>>> the widespread adoption of SQL and relational databases.
>>
>> That is a complete BS, of course. As anyone really understanding
>> these matters understand.
>>
>
> Lawrence seems to like COBOL about as much as Phillip likes Linux
> and non-DEC keyboards. :-)
>
> Simon.
>

I'm not a fan of Cobol, mostly because of all the required typing. So
verbose. But once done, it does a decent job.

--
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 9/22/2021 8:49 AM, Arne Vajhøj wrote:
> And people live with the
> overhead (I don't think that the overhead of a call API is
> significant, but with ORM a lot happens under the hood).

As with so much today, the work is not decreased, it is just hidden.

--
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 9/22/21 7:44 AM, Phillip Helbig (undress to reply) wrote:
> In article <sietii$qmo$2@dont-email.me>,
> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
> writes:
>
>> Den 2021-09-22 kl. 10:15, skrev Lawrence D’Oliveiro:
>>> On Saturday, September 18, 2021 at 12:14:00 AM UTC+12, Scott Dorsey wrote:
>>>> COBOL isn't a programming language. COBOL is a data description language
>>>> that has some programming features on the side. If you look at a well-written
>>>> typical COBOL program, the procedure division is a very small part of the total
>>>> length.
>>>
>>
>> I think that Scott tried to make a joke there. It very much depends
>> on the actual application, of course, what the ratio between data
>> definition and procedure code is.
>
> Indeed. There is a huge amount of code using COBOL and SQL (much of it
> with Rdb).
>

I was doing COBOL with database access (I won't say SQL, it was
different originally) using DMS-11 on a Univac 1100 back in 1980.
It has advanced considerably since then. GnuCOBOL and OCESQL even
let you do it for free if you want to learn how it works.

bill

On 9/22/2021 11:50 AM, Dave Froble wrote:
> On 9/22/2021 8:49 AM, Arne Vajhøj wrote:
>>  And people live with the
>> overhead (I don't think that the overhead of a call API is
>> significant, but with ORM a lot happens under the hood).
>
> As with so much today, the work is not decreased, it is just hidden.

The business application developer need to write much less code,
but a lot of things may happen inside the frameworks used.

For ORM frameworks it is common if lazy loading is
specified to generate a sub class of the developer
provided class on the fly.

Arne

On 2021-09-22, Dave Froble <davef@tsoft-inc.com> wrote:
>
> I'm not a fan of Cobol, mostly because of all the required typing. So
> verbose. But once done, it does a decent job.
>

You write the code once, but read it many times.

Code should be written to be readable, not to save you a bit of
typing time.

Simon.

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

On 9/22/21 1:09 PM, Arne Vajhøj wrote:
> On 9/22/2021 11:50 AM, Dave Froble wrote:
>> On 9/22/2021 8:49 AM, Arne Vajhøj wrote:
>>>  And people live with the
>>> overhead (I don't think that the overhead of a call API is
>>> significant, but with ORM a lot happens under the hood).
>>
>> As with so much today, the work is not decreased, it is just hidden.
>
> The business application developer need to write much less code,
> but a lot of things may happen inside the frameworks used.
>

That was tried ages ago, too. There was SCORE, a COBOL generator from
the 80's. It generated unmaintainable COBOL so any modifications had
to be done to the SCORE source code. That was great until you ran into
something that you could not define using SCORE.

The same was true with COBOL generator sold by Tandy in their computer
stores. It generated Ryan-MCFarland COBOL for the compiler they sold.
If you think COBOL written by real programmers is verbose you should
have seen the output from this. Too big to edit in any editor on the
machines it ran on so, same problem. Changes had to be made from the
original source and sometimes you needed to do things it was not able to do.

Nothing beats a real programer working with a real language.

bill

On 9/22/2021 1:27 PM, Simon Clubley wrote:
> On 2021-09-22, Dave Froble <davef@tsoft-inc.com> wrote:
>> I'm not a fan of Cobol, mostly because of all the required typing. So
>> verbose. But once done, it does a decent job.
>
> You write the code once, but read it many times.
>
> Code should be written to be readable, not to save you a bit of
> typing time.

True.

But readability and verbosity does not always follow.

Some times verbosity help explain what the code does.

But other times verbosity just distracts from what the
code does by forcing the reader to find the relevant
info among a lot of boilerplate stuff.

Arne

On 9/22/2021 1:27 PM, Bill Gunshannon wrote:
> On 9/22/21 1:09 PM, Arne Vajhøj wrote:
>> On 9/22/2021 11:50 AM, Dave Froble wrote:
>>> On 9/22/2021 8:49 AM, Arne Vajhøj wrote:
>>>>  And people live with the
>>>> overhead (I don't think that the overhead of a call API is
>>>> significant, but with ORM a lot happens under the hood).
>>>
>>> As with so much today, the work is not decreased, it is just hidden.
>>
>> The business application developer need to write much less code,
>> but a lot of things may happen inside the frameworks used.
>
> That was tried ages ago, too.  There was SCORE, a COBOL generator from
> the 80's.  It generated unmaintainable COBOL so any modifications had
> to be done to the SCORE source code.  That was great until you ran into
> something that you could not define using SCORE.
>
> The same was true with COBOL generator sold by Tandy in their computer
> stores.  It generated Ryan-MCFarland COBOL for the compiler they sold.
> If you think COBOL written by real programmers is verbose you should
> have seen the output from this.  Too big to edit in any editor on the
> machines it ran on so, same problem.  Changes had to be made from the
> original source and sometimes you needed to do things it was not able to
> do.
>
> Nothing beats a real programer working with a real language.

That which I would label as "compiling 4GL to 3GL" has a somewhat
mixed history of success and was also mostly dropped just to
pop up again recently as "low code platforms".

But it does not really relate much to what I was describing. I was
talking about libraries that handle a lot of the "how" and let
the developer focus more on the "what". I will claim that the concept
of powerful libraries has proven itself to be a good thing
over the last half century.

Arne

On 2021-09-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> That which I would label as "compiling 4GL to 3GL" has a somewhat
> mixed history of success and was also mostly dropped just to
> pop up again recently as "low code platforms".
>

:-)

Anyone else from the UK remember The Last One from the early 1980s
and some of the marketing hype surrounding it ?

Simon.

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

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> …
>
> Anyone else from the UK remember The Last One from the early 1980s
> and some of the marketing hype surrounding it ?
> Simon.

I do!
And several subsequent efforts at programmerless programming.

--
Paul at the paulhardy.net domain

On 9/16/2021 10:08 PM, Lawrence D’Oliveiro wrote:
> 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>.)

That program seems to be reading from some files and inserting
some information into a database.

That is a pretty standard task for Cobol. Of course it can be done.

It will undoubtedly require more lines of code. Cobol data
declarations are huge and the executable statements are also
on the verbose side. Typical estimates says Cobol 100 loc/FP
and Python 20 loc/FP, so a guess would be 5 times as many lines.

For the specific case there is also some needed libraries
that will have to be found: scanning dirs, accessing SQLite
and the HarfBuzz stuff.

For the specific task then I don't think Cobol will make
top 20 of language candidates. The only thing Cobol would
be good at for that task is doing the SQL.

Arne