On Tuesday, October 19, 2021 at 2:33:00 AM UTC+13, Arne Vajhøj wrote:
> I can only think of one case where I will prefer GOTO
> over alternatives: in a language without exceptions to
> jump to cleanup code in case of problems.

That sounds wrong. Don’t do that. Why? Because cleanup is something you always have to do, problems or no problems. So you never want to jump *to* it or *around* it, you always want to go *through* it.

On 2021-10-18 00:18:05 +0000, Simon Clubley said:

> And Sector 7 (and others IIRC) have done various pieces of this, yet
> there's still a market for real VMS systems.

FreeVMS, as well.

By the time VSI could get all the APIs across to Linux, it's a ~decade
added to the VSI schedule, and with ~little forward progress elsewhere
within OpenVMS.

The existing (and mostly-working) x86-64 port will already be a ~decade
arriving with the V9.2-1 schedule, starting from when VSI decloaked.

Porting specific apps to Linux with or without wrappers can be and
usually an incremental process.

A vendor kernel swap—or more likely a wholesale kernel fork—doesn't
have the luxury of supporting a subset of the APIs.

And who knows where Linux and server platforms will be in a decade,
given the increasingly integrated and increasingly heterogeneous system
designs already available.

Trade-offs here shift, too.

Current-generation vendor-integrated SSD storage is now running ~at
DDR3-1066 / PC3-8500 RAM (unregistered) speeds.

That's approximately the speed of main memory on Integrity rx2800,
which runs DDR3-1066R registered...

Swapping for L4 / OKL4 / newer / around the time of the OpenVMS Arm
port is another discussion.

But now? Kernel swaps? With V9.1-A available? Nope.

--
Pure Personal Opinion | HoffmanLabs LLC

On Tuesday, October 19, 2021 at 12:07:06 PM UTC+13, Stephen Hoffman wrote:
> And who knows where Linux and server platforms will be in a decade,
> given the increasingly integrated and increasingly heterogeneous system
> designs already available.

Even further ahead, with ARM and RISC-V likely having a greater presence. And VMS being left even further behind, with yet more hills to climb.

On 10/18/2021 1:28 PM, Simon Clubley wrote:
> On 2021-10-18, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> That's funny... The academic world did that decades ago. That's
>> why we keep hearing that COBOL is dead and OOP and Agile are the
>> best thing since sliced bread.
>
> There's still a place for COBOL. Sometimes the practical language
> instead of the fashionable language is required.

If companies started with no code at all, then I suspect that
very few would pick Cobol today.

But the reality is that a lot of companies got a lot of Cobol
code. And moving away from Cobol may be a huge and risky task.

> OOP allows you to very nicely implement abstraction layers provided
> you don't go overboard and have 10 layers of abstraction to write
> out a single character (for example). :-)
>
> Agile OTOH seems way too often to be used as an excuse to not to do
> the hard and real work of designing and laying out the overall
> architecture before implementing the design.

I think that is mostly a myth that thrives among non-agile
developers.

Agile does not mean no architecture. Agile means the
right amount of architecture depending on project
size, criticality and volatility.

There has been written a ton about it the last decade.
Leading authors include Scott Ambler and Martin Fowler.
Some agile methodologies even use TOGAF.

Arne

On Tuesday, October 19, 2021 at 3:07:25 PM UTC+13, Arne Vajhøj wrote:
> But the reality is that a lot of companies got a lot of Cobol
> code. And moving away from Cobol may be a huge and risky task.

Companies with the albatross of legacy code around their necks will inevitably be less able to adapt to changing business circumstances than those who are more flexible.

In other words, free-market competition means that problem will solve itself.

In other, other words, the sunk-cost fallacy is real, after all.

On 10/18/2021 6:18 PM, Lawrence D’Oliveiro wrote:
> On Tuesday, October 19, 2021 at 2:33:00 AM UTC+13, Arne Vajhøj
> wrote:
>> I can only think of one case where I will prefer GOTO over
>> alternatives: in a language without exceptions to jump to cleanup
>> code in case of problems.
>
> That sounds wrong. Don’t do that. Why? Because cleanup is something
> you always have to do, problems or no problems. So you never want to
> jump *to* it or *around* it, you always want to go *through* it.

The crystal ball where you saw that the cleanup code was not executed
in the happy case does not work any more and need to be replaced.

Arne

On 2021-10-18, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Tuesday, October 19, 2021 at 1:27:51 AM UTC+13, Simon Clubley wrote:
>>
>> These people have been around for decades and all that time they
>> have been helping move systems away from VMS, at least those systems
>> which a) can be moved and b) those which the customer wants to move
>> away from VMS.
>
> Which is exactly the kind of thing a management type would say. You know, the type who describes themself as a ?big picture? type of person, who leaves the troublesome details of actually getting things working to some hapless underling.
>
> In other words, the type that is easily taken in by a slick advertising campaign.

Really Lawrence ? That's the best you can come up with ? :-)

In fairness to you however, I probably couldn't have done any better
if I had backed myself into the kind of corner that you are now in
and was looking for a way out. One difference however is that I would
NOT be willing to unfairly and wrongly put down a major vendor just
so I could find an escape route.

For the record however, I am a seriously technical type, not a management
type and I sincerely hope that certain people around here were not eating
or drinking anything when you described me in the above words. :-)

Simon.

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

On 10/18/21 10:07 PM, Arne Vajhøj wrote:
> On 10/18/2021 1:28 PM, Simon Clubley wrote:
>> On 2021-10-18, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> That's funny...  The academic world did that decades ago.  That's
>>> why we keep hearing that COBOL is dead  and OOP and Agile are the
>>> best thing since sliced bread.
>>
>> There's still a place for COBOL. Sometimes the practical language
>> instead of the fashionable language is required.
>
> If companies started with no code at all, then I suspect that
> very few would pick Cobol today.

And why is that? Is it because the newer languages are better
for the tasks COBOL was designed for or is is it because academia
stopped teaching it and chose to attack it vehemently.

>
> But the reality is that a lot of companies got a lot of Cobol
> code. And moving away from Cobol may be a huge and risky task.

And totally unnecessary. Modernization doesn't have to mean
using the language du jour.

>
>> OOP allows you to very nicely implement abstraction layers provided
>> you don't go overboard and have 10 layers of abstraction to write
>> out a single character (for example). :-)
>>
>> Agile OTOH seems way too often to be used as an excuse to not to do
>> the hard and real work of designing and laying out the overall
>> architecture before implementing the design.
>
> I think that is mostly a myth that thrives among non-agile
> developers.

Nope, it's accurate.

>
> Agile does not mean no architecture. Agile means the
> right amount of architecture depending on project
> size, criticality and volatility.
>
> There has been written a ton about it the last decade.
> Leading authors include Scott Ambler and Martin Fowler.
> Some agile methodologies even use TOGAF.
>

One of the places I worked at made us all take Agile clases.
I still have my book from the course and I break it out when
I need a good laugh. It talks about what is now called
"waterfall" (we didn't call it that when we were doing it)
as something totally foreign to what was actually done.
And then sets itself up as the answer for a problem that
exists only in the minds of Agile supporters.

bill

On Wednesday, October 20, 2021 at 1:11:10 AM UTC+13, Simon Clubley wrote:
> For the record however, I am a seriously technical type, not a management
> type ...

Prove it. Look seriously into the technicalities of what that company offers.

For example, looking more deeply into their case studies, it’s clear that they don’t expect to move any serious amount of code, even just user-mode code, across unchanged. There’s always some serious rewriting involved. For instance, in one case study, the customer is using DECnet, yet in the description of how that port was done, mention of DECnet mysteriously disappears.

For another example, look how they blandly claim that a whole bunch of VMS system calls can be carried across, including all the SYS$ calls. Really?? Including, say, $CMEXEC or $CMKRNL? Do you really expect those to work without an authentic VMS kernel behind them?

Those are just some examples of the sorts of gaps you might not notice if you are not a technical type.

On Tuesday, October 19, 2021 at 12:38:09 AM UTC+13, chris wrote:
> I would stop digging if I were you :-).

Says the one still in the hole over the pfSense/systemd issue.

If you want to contribute something useful to this discussion, go have a look at the site and see if you can answer some basic questions about how their VMS emulation really works.

For example, how do they emulate terminal driver behaviour? Say, something basic like being able to hit CTRL/Y to suspend a user-mode program, then type CONTINUE to resume it? How do they emulate that under Linux?

(I have some ideas on how to do that. I’d get into those, but I get the feeling people here don’t really want to discuss such things.)

On Wednesday, October 20, 2021 at 5:34:36 AM UTC+13, Bill Gunshannon wrote:
> On 10/18/21 10:07 PM, Arne Vajhøj wrote:
>>
>> If companies started with no code at all, then I suspect that
>> very few would pick Cobol today.
>>
> And why is that? Is it because the newer languages are better
> for the tasks COBOL was designed for or is is it because academia
> stopped teaching it and chose to attack it vehemently.

Did it ever occur to you both might be aspects of the same reason?

I mentioned previously how COBOL was supposedly designed for “business” needs, yet it didn’t take long to become apparent that it had become woefully out of step with actual “business” needs, when businesses became more dependent on SQL databases instead of ISAM files; COBOL was born in the era of ISAM files, and never really adapted to be being able to cope in a very flexible way with SQL.

On Tuesday, October 19, 2021 at 3:19:20 PM UTC+13, Arne Vajhøj wrote:
>
> On 10/18/2021 6:18 PM, Lawrence D’Oliveiro wrote:
>
>> On Tuesday, October 19, 2021 at 2:33:00 AM UTC+13, Arne Vajhøj
>> wrote:
>>
>>> I can only think of one case where I will prefer GOTO over
>>> alternatives: in a language without exceptions to jump to cleanup
>>> code in case of problems.
>>
>> That sounds wrong. Don’t do that. Why? Because cleanup is something
>> you always have to do, problems or no problems. So you never want to
>> jump *to* it or *around* it, you always want to go *through* it.
>
> The crystal ball where you saw that the cleanup code was not executed
> in the happy case does not work any more and need to be replaced.

You wouldn’t need a goto for that. That’s why your code sounds wrong.

Den 2021-10-23 kl. 09:57, skrev Lawrence D’Oliveiro:
> On Wednesday, October 20, 2021 at 5:34:36 AM UTC+13, Bill Gunshannon wrote:
>> On 10/18/21 10:07 PM, Arne Vajhøj wrote:
>>>
>>> If companies started with no code at all, then I suspect that
>>> very few would pick Cobol today.
>>>
>> And why is that? Is it because the newer languages are better
>> for the tasks COBOL was designed for or is is it because academia
>> stopped teaching it and chose to attack it vehemently.
>
> Did it ever occur to you both might be aspects of the same reason?
>
> I mentioned previously how COBOL was supposedly designed for “business” needs, yet it didn’t take long to become apparent that it had become woefully out of step with actual “business” needs, when businesses became more dependent on SQL databases instead of ISAM files; COBOL was born in the era of ISAM files, and never really adapted to be being able to cope in a very flexible way with SQL.
>

Again, there is no major difference in how SQL is handled in Cobol
than in any other compiled language. Scripting languages might have
some other run-time mangling of SQL commands, but that can be done
from Cobol also using a dynamic-SQL interface. But that has worse
performance since the SQL has to be processed and "compiled" at each
call. Embedded SQL using a SQL-precompiler does that at compile-time.
At run-time you do not analyse, compile and execute any SQL at all.

And there is no major difference in Cobol between ISAM and SQL.
I'd say that in most cases the SQL coding is cleaner and easier.
At least if ISAM=RMS and SQL=Rdb.

In article <e4874d12-6965-4172-b41d-18bce3fe3839n@googlegroups.com>,
=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:

> I mentioned previously how COBOL was supposedly designed for =E2=80=9Cbusin=
> ess=E2=80=9D needs, yet it didn=E2=80=99t take long to become apparent that=
> it had become woefully out of step with actual =E2=80=9Cbusiness=E2=80=9D =
> needs, when businesses became more dependent on SQL databases instead of IS=
> AM files; COBOL was born in the era of ISAM files, and never really adapted=
> to be being able to cope in a very flexible way with SQL.

There is a huge amount of COBOL using embedded SQL, compiled with help
of the Rdb precompiler, interacting with Rdb databases. Works well and
makes the companies which run it hundreds of millions in profit. COBOL
is fine with RMS files and fine with the Rdb SQL database.

Is it colder in the winter or in the country?

On 10/23/2021 3:57 AM, Lawrence D’Oliveiro wrote:
> On Wednesday, October 20, 2021 at 5:34:36 AM UTC+13, Bill Gunshannon
> wrote:
>> On 10/18/21 10:07 PM, Arne Vajhøj wrote:
>>>
>>> If companies started with no code at all, then I suspect that
>>> very few would pick Cobol today.
>>>
>> And why is that? Is it because the newer languages are better for
>> the tasks COBOL was designed for or is is it because academia
>> stopped teaching it and chose to attack it vehemently.
>
> Did it ever occur to you both might be aspects of the same reason?
>
> I mentioned previously how COBOL was supposedly designed for
> “business” needs, yet it didn’t take long to become apparent that it
> had become woefully out of step with actual “business” needs, when
> businesses became more dependent on SQL databases instead of ISAM
> files; COBOL was born in the era of ISAM files, and never really
> adapted to be being able to cope in a very flexible way with SQL.

As explained to you many times already, then Cobol does
SQL fine via embedded SQL. And this is not just a theoretical
capability - a huge portion of all Cobol programs actually do
so - they access relational databases like Oracle, DB2, Rdb etc..

Arne

On 10/23/2021 4:24 AM, Jan-Erik Söderholm wrote:
> Den 2021-10-23 kl. 09:57, skrev Lawrence D’Oliveiro:
>> I mentioned previously how COBOL was supposedly designed for
>> “business” needs, yet it didn’t take long to become apparent that it
>> had become woefully out of step with actual “business” needs, when
>> businesses became more dependent on SQL databases instead of ISAM
>> files; COBOL was born in the era of ISAM files, and never really
>> adapted to be being able to cope in a very flexible way with SQL.
>>
>
> Again, there is no major difference in how SQL is handled in Cobol
> than in any other compiled language.

Cobol is special because almost all RDBMS access is via embedded SQL
and that is not the case in other languages, but embedded SQL is
available for other languages as well. Embedded SQL for C is seen
in real life.

> Scripting languages might have
> some other run-time mangling of SQL commands, but that can be done
> from Cobol also using a dynamic-SQL interface. But that has worse
> performance since the SQL has to be processed and "compiled" at each
> call.

Many database servers today cache execution plans mitigating the cost of
more dynamic SQL.

> Embedded SQL using a SQL-precompiler does that at compile-time.
> At run-time you do not analyse, compile and execute any SQL at all.

I think that depends on the implementation.

Some embedded SQL simply generate code that calls a regular database
library and pass the SQL as argument to a function that end up sending
the SQL over the netwo0rk to the database server.

One database embedded SQL that does not do that is DB2. It does
a lot during prep and bind.

> And there is no major difference in Cobol between ISAM and SQL.
> I'd say that in most cases the SQL coding is cleaner and easier.
> At least if ISAM=RMS and SQL=Rdb.

Both file IO to ISAM files and embedded SQL are pretty standard
in Cobol, so I would expect that top be true for any ISAM
and RDBMS.

Arne

On 2021-10-23, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Wednesday, October 20, 2021 at 1:11:10 AM UTC+13, Simon Clubley wrote:
>> For the record however, I am a seriously technical type, not a management
>> type ...
>
> Prove it. Look seriously into the technicalities of what that company offers.
>

I don't have to prove anything to you Lawrence and those people around
here who I _do_ care about already know what kinds of skills and
knowledge I do possess.

> For example, looking more deeply into their case studies, it?s clear that they don?t expect to move any serious amount of code, even just user-mode code, across unchanged. There?s always some serious rewriting involved. For instance, in one case study, the customer is using DECnet, yet in the description of how that port was done, mention of DECnet mysteriously disappears.
>
> For another example, look how they blandly claim that a whole bunch of VMS system calls can be carried across, including all the SYS$ calls. Really?? Including, say, $CMEXEC or $CMKRNL? Do you really expect those to work without an authentic VMS kernel behind them?
>
> Those are just some examples of the sorts of gaps you might not notice if you are not a technical type.

Congratulations Lawrence, you have just made my point for me.

As I and others have told you from the beginning, getting VMS code
running on another operating system is not easy.

Yet you come riding into town as if you are the Messiah and proclaiming
that porting from VMS to Linux will be easy if we follow your glorious
path.

Here are very skilled professionals who have done this move away from VMS
for multiple customers, yet even so, VMS is still being ported to x86-64.
The reason for that is not all applications can be moved away from VMS
and there is still a requirement for real VMS systems.

You dismiss Sector 7's multi-decade efforts and then claim that you can
somehow do better than them and claim it can be done in a relatively
short period of time ? Yeah, right.

The problem with you Lawrence is that you are so clueless about what
is needed to achieve this, you don't actually realise just how clueless
you are.

That's why I pointed you to their website so you could privately
see just how much effort was involved in doing what you claim can
be done easily, without me having to ram that message home in public
to you.

Unfortunately, you come across as the kind of person who really is
arrogant enough to think they can somehow do better than what everyone
else has done before them, so here I am telling you in public what
I was hoping you would realise privately by yourself.

You want people, including me, to take you seriously ? You need to
deliver on your claims or at least lay out a detailed path that shows
why it's better than what people before you have achieved.

Handwaving is not laying out a detailed path, BTW.

Simon.

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

On 2021-10-23, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Tuesday, October 19, 2021 at 12:38:09 AM UTC+13, chris wrote:
>> I would stop digging if I were you :-).
>
> Says the one still in the hole over the pfSense/systemd issue.
>
> If you want to contribute something useful to this discussion, go have a look at the site and see if you can answer some basic questions about how their VMS emulation really works.
>
> For example, how do they emulate terminal driver behaviour? Say, something basic like being able to hit CTRL/Y to suspend a user-mode program, then type CONTINUE to resume it? How do they emulate that under Linux?
>

If they don't support it (and I don't know if they do) why would they
need to ? A typical customer might simply not care about that if
they can get the rest of their application running on Linux.

The remaining terminal driver stuff that doesn't need DCL interaction
can be emulated within the porting libraries the customer links their
application against.

There are also ways to emulate the sys$cli() functions as Stephen pointed
out recently.

BTW, many applications run inside a menu system for as long as the user
is logged in and the user never sees the DCL prompt.

> (I have some ideas on how to do that. I?d get into those, but I get the feeling people here don?t really want to discuss such things.)

Perhaps it's because this isn't a real issue that most end-user
customers are likely to need to support on Linux.

Do you have any business knowledge Lawrence ?

Simon.

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

On 2021-10-24 14:34:35 +0000, Simon Clubley said:

> As I and others have told you from the beginning, getting VMS code
> running on another operating system is not easy.

If OpenVMS app were uniformly easy to port, VSI itself wouldn't exist.
Many of the easier-to-port apps have already been ported, too.

BTW, for those following along at home, including those considering
porting OpenVMS or other apps to Windows, the 26† drive letter "limit"
mentioned else-thread recently hasn't been an issue for a while; not
since somewhere around Microsoft Windows 2000.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938934(v=technet.10)

Windows picked up hardlinks support back then, something OpenVMS has
also seen added.

The whole of the device name abstraction with the device driver
"prefix" that's used on OpenVMS is another artifact of RSX-11 and
VAX-11 era I/O bus configuration processes. It likely wouldn't be used
in a newer operating system design, and OpenVMS itself mostly moved on
from the whole construct with the advent of file-based configuration.
And then there's the whole host name and allocation class cluster
"prefix" ($) that got added a while back. This device-naming stuff is
also indirectly tied into the logical name processing hiding in the
lower realms of the OpenVMS I/O subsystem, too. Parsing the resulting
device names—something I'd prefer to never have to do—within
filenames—something else I'd rather not have to do—as part of scanning
I/O configurations or devices or clusters—yet more I'd rather not
contend with—got ugly, too. And this gnarliness also all gets more
interesting to port, too. But I digress.

As for SSIO, the "fun" with that was always that first pesky S; around
corruptions during shared file access.

And looking at SSD speeds now at DDR3-1066 RAM speeds and at main
memory running at on-die LLC cache speeds from ~five years ago make me
wonder how long many existing app assumptions around memory hierarchies
and memory latencies will continue to be useful.

Fun times.

†Technically, it's arguably 24 devices and not 26, as A and B
reportedly cannot reference HDD/SSD storage. Not that I've ever needed
or tried or considered remapping A and B, given that links can and do
work.

--
Pure Personal Opinion | HoffmanLabs LLC

On Saturday, October 23, 2021 at 9:24:27 PM UTC+13, Jan-Erik Söderholm wrote:
>
> Again, there is no major difference in how SQL is handled in Cobol
> than in any other compiled language. Scripting languages might have
> some other run-time mangling of SQL commands, but that can be done
> from Cobol also using a dynamic-SQL interface. But that has worse
> performance since the SQL has to be processed and "compiled" at each
> call.

The overhead of “compiling” SQL at runtime is not a concern on modern hardware. The bulk of the overhead lies very much in the actual database I/O.

And modern dynamic languages make a lot of things easy to do that are difficult, or just about impossible on COBOL. I have given some examples of this; I can repeat them if you like.

On Monday, October 25, 2021 at 3:34:38 AM UTC+13, Simon Clubley wrote:
> You dismiss Sector 7's multi-decade efforts ...

You were the one who tried to point them out to me. But you seem unable to look beyond the surface.

For example, if they really do have their finger on the pulse of the VMS community, then they would have a presence right here on comp.os.vms. So where are they?

> The problem with you Lawrence is that you are so clueless about what
> is needed to achieve this ...

I have already raised many of the points that are precisely needed to achieve this. It is you, and others like you, who seem to want to just shut the discussion down.

On Monday, October 25, 2021 at 3:45:24 AM UTC+13, Simon Clubley wrote:
> On 2021-10-23, Lawrence D?Oliveiro <lawren...@gmail.com> wrote:
>
>> For example, how do they emulate terminal driver behaviour?
>> Say, something basic like being able to hit CTRL/Y to suspend a
>> user-mode program, then type CONTINUE to resume it? How
>> do they emulate that under Linux?
>>
> If they don't support it (and I don't know if they do) why would they
> need to ?

Because it can be done. And it is part of the VMS experience, after all.

This is actually an easy one: POSIX job control can already deal with it. Slightly more complicated is, say, handling CTRL/T and read-with-prompt. Remember that CTRL/T is implemented as an out-of-band AST that triggers a terminal broadcast, so to handle that correctly, I think you would need to implement terminal driver handling in the DCL compatibility process I previously mentioned.

> A typical customer might simply not care about that if
> they can get the rest of their application running on Linux.

There is a key thing they teach you in customer-support courses, that “delighting the customer” involves going a little bit beyond what they expect.

With Linux, we have the technology!

On 10/19/2021 12:34 PM, Bill Gunshannon wrote:
> On 10/18/21 10:07 PM, Arne Vajhøj wrote:
>> On 10/18/2021 1:28 PM, Simon Clubley wrote:
>>> On 2021-10-18, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> That's funny...  The academic world did that decades ago.  That's
>>>> why we keep hearing that COBOL is dead  and OOP and Agile are the
>>>> best thing since sliced bread.
>>>
>>> There's still a place for COBOL. Sometimes the practical language
>>> instead of the fashionable language is required.
>>
>> If companies started with no code at all, then I suspect that
>> very few would pick Cobol today.
>
> And why is that? Is it because the newer languages are better
> for the tasks COBOL was designed for or is is it because academia
> stopped teaching it and chose to attack it vehemently.

Availability of people with skills is a potential explanation.
But it empirical evidence does not support it - the very most
used languages are taught, but among the second tier languages
many are not taught widely including Go, Rust, Swift, Kotlin,
Scala, Groovy, Ruby, VB etc..

The main driver has to be that the newer languages and the
supported frameworks/libraries make developers more productive.
They can focus on the business logic and let the language and
frameworks/libraries handle some of the trivial stuff. Same
thing that happened when people switch from assembler to
Fortran and Cobol a long time ago.

Possible augmented by the fact that a lot of the stuff that
is used today does not provide easy access to Cobol. Making
it more cumbersome to integrate.

>> But the reality is that a lot of companies got a lot of Cobol
>> code. And moving away from Cobol may be a huge and risky task.
>
> And totally unnecessary.  Modernization doesn't have to mean
> using the language du jour.

True. And MicroFocus is making most of their money from
companies wanting to modernize without migrating off Cobol.

But if a company has to do a really big technological upgrade,
then a big part of them decide to migrate off Cobol. It is the right
time.

But a lot also decide to postpone.

Arne

On 10/19/2021 12:34 PM, Bill Gunshannon wrote:
> On 10/18/21 10:07 PM, Arne Vajhøj wrote:
>> On 10/18/2021 1:28 PM, Simon Clubley wrote:
>>> OOP allows you to very nicely implement abstraction layers provided
>>> you don't go overboard and have 10 layers of abstraction to write
>>> out a single character (for example). :-)
>>>
>>> Agile OTOH seems way too often to be used as an excuse to not to do
>>> the hard and real work of designing and laying out the overall
>>> architecture before implementing the design.
>>
>> I think that is mostly a myth that thrives among non-agile
>> developers.
>
> Nope, it's accurate.

First let us document that agile do use architecture.

The Open Group (same that do the Unix specification and TOGAF) has
create Open Agile Architecture Standard:

https://pubs.opengroup.org/architecture/o-aa-standard/

Plenty of key agile people have been writing about agile and
architecture:

Jim Highsmith (co-author agile manifest) in "Architects: Anchors or
Accelerators to Organizational Agility?" presenttaion:

"So, Are architecture and agile development compatible?
Of course they are!"

Robert Martin (co-author agile manifest) in "Agile Principles, Patterns,
and Practices in C#":

"This is not an abandonment of architecture and design. Rather, it is a
way to incrementally evolve the most appropriate architecture and design
for the system. It is also a way to keep that design and architecture
appropriate as the system grows and evolves over time. Agile development
makes the process of design and architecture continous."

Martin Fowler (co-author agile manifest) in
https://martinfowler.com/articles/designDead.html:

"I think there is a role for a broad starting point architecture. Such
things as stating early on how to layer the application, how you'll
interact with the database (if you need one), what approach to use to
handle the web server."

"So my advice is to begin by assessing what the likely architecture is.
If you see a large amount of data with multiple users, go ahead and use
a database from day 1. If you see complex business logic, put in a
domain model. However in deference to the gods of YAGNI, when in doubt
err on the side of simplicity. Also be ready to simplify your
architecture as soon as you see that part of the architecture isn't
adding anything."

Kent Beck (co-author agile manifest, inventor of XP) in
"Extreme Programming Explained":

"The architecture for a little system should not be the same as for a
big system. While the system is little the architect makes sure the
system has the right little architecture. As the system grows, the
architect makes the architecture keeps pace."

Alistair Cockburn (co-author agile manifest) in "Agile Software
Development":

"Agile methodologies place a premium on
getting something up and running early, and
evolving it over time. Not all projects are equally
amenable to tiny evolutionary steps. Deciding how
to break up the giant architecture on a large project
into smaller pieces that can be built and tested
incrementally, does take some work. It can be
done, however, and is worth the effort."

"We insist that the architecture be allowed to
adjust over time, just as the requirements and
process are. An architecture locked down too hard,
too early, will not be able to adjust to the inevitable
surprises that surface during implementation and
with changing requirements. An architecture that
grows in steps can follow the changing knowledge
of the team and the changing wishes of the user
community."

Scott Ambler (inventor Disciplined Agile Delivery) in
http://agilemodeling.com/essays/agileArchitecture.htm"

"Contrary to popular belief, architecture is an important aspect of
agile software development efforts, just like traditional efforts, and
is a critical part of scaling agile approaches to meet the real-world
needs of modern organizations. But, agilists approach architecture a bit
differently than traditionalists do."

"Architecture provides the foundation from which systems are built and
an architectural model defines the vision on which your architecture is
based. The scope of architecture can be that of a single application, of
a family of applications, for an organization, or for an infrastructure
such as the Internet that is shared by many organizations. Regardless of
the scope, my experience is that you can take an agile approach to the
modeling, development, and evolution of an architecture."

These people know what agile is, because they invented agile!

Anyone believing that agile does not use architecture has not studied agile.

Obviously not everyone has studied agile. And in theory the belief
could thrive both among pro-agile and con-agile people. But I do
not think I have ever met the belief among pro-agile.

It is a belief that thrive among con-agile that have not studied
agile.

>> Agile does not mean no architecture. Agile means the
>> right amount of architecture depending on project
>> size, criticality and volatility.
>>
>> There has been written a ton about it the last decade.
>> Leading authors include Scott Ambler and Martin Fowler.
>> Some agile methodologies even use TOGAF.
>
> One of the places I worked at made us all take Agile clases.
> I still have my book from the course and I break it out when
> I need a good laugh.  It talks about what is now called
> "waterfall" (we didn't call it that when we were doing it)
> as something totally foreign to what was actually done.
> And then sets itself up as the answer for a problem that
> exists only in the minds of Agile supporters.

The term "waterfall" to describe software methodology has been
used since at least 1976 (by a couple of military vendor guys
in a paper presented at an IEEE conference).

But let me guess: they explained that with waterfall then if
any requirements changed then all work was ditched and started
over.

Just like con-agile often do not have a clue about how agile
works, then many con-waterfall does not have a clue about
how waterfall works.

Arne

On Saturday, October 16, 2021 at 12:36:21 PM UTC+13, I wrote:
>
> On Saturday, October 16, 2021 at 4:38:37 AM UTC+13, Arne Vajhøj wrote:
>>
>> DECnet is a bit possessive with NIC's - first thing it does is to change
>> the MAC address.
>>
> I know. It’s even more primitive than AppleTalk, it doesn’t have an ARP layer.
> So instead it has to compute the MAC address from the protocol address.
>
> But we can cope with that.

Turns out somebody else has been way ahead of us. Among the standard Debian packages is a DECnet implementation suite, apparently modelled on the Ultrix implementation <https://packages.debian.org/bullseye/libdnet>, <https://packages.debian.org/bullseye/dnet-progs>. Look at that, there is an equivalent to PHONE, there is a VMSmail-to-SMTP gateway, there is something called librms!

(How did I find it? I was just idly browsing the netlink(7) man page <https://manpages.debian.org/bullseye/manpages/netlink.7.en.html> -- as you do -- when I saw that the Linux kernel had provisions for handling DECnet routing messages. So I looked for userland packages that might use that, and there you are.)

Personally I would not allow DECnet anywhere near layer 2 on an actual physical NIC these days--I would cocoon it securely in a tunnel at layer 7. But I’m sure this implementation can cope with that ...