I'm hoping this group might be able to help advise.

About 30 years ago I used to work with VMS before I moved to the Unix/Linux world.

I have about 15 years left in my career and I was interested in making a change back to OpenVMS.

Before cracking open the books again and studying up along with the hobbyist license that I have going here at home, I wanted to get a feel of who still uses the O/S and what level of opportunity might exist for a second-career. I realize that the OpenVMS customer base is likely not growing much, or at all.

How many OpenVMS shops still exist in the U.S.? Is it true that many System Managers have retired at this point, leaving a shortage? Would you encourage or discourage an effort like mine? Is it worth the time and effort?

On 2022-08-09, Tim Lank <timlank@timlank.com> wrote:
> I'm hoping this group might be able to help advise.
>
> About 30 years ago I used to work with VMS before I moved to the Unix/Linux world.
>
> I have about 15 years left in my career and I was interested in making a change back to OpenVMS.
>
> Before cracking open the books again and studying up along with the hobbyist license that I have going here at home, I wanted to get a feel of who still uses the O/S and what level of opportunity might exist for a second-career. I realize that the OpenVMS customer base is likely not growing much, or at all.
>
> How many OpenVMS shops still exist in the U.S.? Is it true that many System Managers have retired at this point, leaving a shortage? Would you encourage or discourage an effort like mine? Is it worth the time and effort?

Overall, I would consider VMS as being in a state of managed decline.

You are not going to see any brand new customers moving to VMS as
VMS is way too behind in terms of security and available software
and general functionality.

However, existing sites are going to continue using it unless they
either move away due to application retirement or are forced away
(because, say, VSI goes bust and they need to move away before the
licences expire).

There is also some potential for existing sites to add additional
VMS machines to support an increased workload, but I don't have
a feeling for how many sites might fall into this category.

Simon.

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

On 08/09/22 14:02, Simon Clubley wrote:
> On 2022-08-09, Tim Lank<timlank@timlank.com> wrote:
>> I'm hoping this group might be able to help advise.
>>
>> About 30 years ago I used to work with VMS before I moved to the Unix/Linux world.
>>
>> I have about 15 years left in my career and I was interested in making a change back to OpenVMS.
>>
>> Before cracking open the books again and studying up along with the hobbyist license that I have going here at home, I wanted to get a feel of who still uses the O/S and what level of opportunity might exist for a second-career. I realize that the OpenVMS customer base is likely not growing much, or at all.
>>
>> How many OpenVMS shops still exist in the U.S.? Is it true that many System Managers have retired at this point, leaving a shortage? Would you encourage or discourage an effort like mine? Is it worth the time and effort?
>
> Overall, I would consider VMS as being in a state of managed decline.
>
> You are not going to see any brand new customers moving to VMS as
> VMS is way too behind in terms of security and available software
> and general functionality.
>
> However, existing sites are going to continue using it unless they
> either move away due to application retirement or are forced away
> (because, say, VSI goes bust and they need to move away before the
> licences expire).
>
> There is also some potential for existing sites to add additional
> VMS machines to support an increased workload, but I don't have
> a feeling for how many sites might fall into this category.
>
> Simon.
>

That's the pessimistic view, but if vsi keep at it in the long term,
there's no reason why it should not be competitive in respect of the
points you are making. There's been a huge effort just to get it
ported to X86, so perhaps no, in the short term, but who can predict
then future ?.

Without hope, vision and a plan, there is no future...

Chris

On Tuesday, August 9, 2022 at 9:43:08 AM UTC-4, chris wrote:
> On 08/09/22 14:02, Simon Clubley wrote:
> > On 2022-08-09, Tim Lank<tim...@timlank.com> wrote:
> >> I'm hoping this group might be able to help advise.
> >>
> >> About 30 years ago I used to work with VMS before I moved to the Unix/Linux world.
> >>
> >> I have about 15 years left in my career and I was interested in making a change back to OpenVMS.
> >>
> >> Before cracking open the books again and studying up along with the hobbyist license that I have going here at home, I wanted to get a feel of who still uses the O/S and what level of opportunity might exist for a second-career. I realize that the OpenVMS customer base is likely not growing much, or at all.
> >>
> >> How many OpenVMS shops still exist in the U.S.? Is it true that many System Managers have retired at this point, leaving a shortage? Would you encourage or discourage an effort like mine? Is it worth the time and effort?
> >
> > Overall, I would consider VMS as being in a state of managed decline.
> >
> > You are not going to see any brand new customers moving to VMS as
> > VMS is way too behind in terms of security and available software
> > and general functionality.
> >
> > However, existing sites are going to continue using it unless they
> > either move away due to application retirement or are forced away
> > (because, say, VSI goes bust and they need to move away before the
> > licences expire).
> >
> > There is also some potential for existing sites to add additional
> > VMS machines to support an increased workload, but I don't have
> > a feeling for how many sites might fall into this category.
> >
> > Simon.
> >
> That's the pessimistic view, but if vsi keep at it in the long term,
> there's no reason why it should not be competitive in respect of the
> points you are making. There's been a huge effort just to get it
> ported to X86, so perhaps no, in the short term, but who can predict
> then future ?.
>
> Without hope, vision and a plan, there is no future...
>
> Chris

Would anyone say whether there is a shortage of System Managers, or a surplus?

If you think there is a surplus, then I’d not consider it worth my time and effort.

On the related note, I don't expect going to x86_64 will bring any new customers to the platform. That ship has sailed a long time ago. The time for that would have been in the Compaq/Alpha days (pre-linux boom).

On Tuesday, August 9, 2022 at 9:06:54 AM UTC-7, tim...@timlank.com wrote:
> On Tuesday, August 9, 2022 at 9:43:08 AM UTC-4, chris wrote:
> > That's the pessimistic view, but if vsi keep at it in the long term,
> > there's no reason why it should not be competitive in respect of the
> > points you are making. There's been a huge effort just to get it
> > ported to X86, so perhaps no, in the short term, but who can predict
> > then future ?.
> >
> > Without hope, vision and a plan, there is no future...
> >
> > Chris
> Would anyone say whether there is a shortage of System Managers, or a surplus?
>
> If you think there is a surplus, then I’d not consider it worth my time and effort.
>
> On the related note, I don't expect going to x86_64 will bring any new customers to the platform. That ship has sailed a long > time ago. The time for that would have been in the Compaq/Alpha days (pre-linux boom).

The engineering investments needed to get OpenVMS to be competitive with modern server products would be massive. Re-igniting investments in open source components running on top of OpenVMS could help the team scale tremendously, but it's not clear VSI has the resources or even the desire to achieve competitive parity with modern operating systems.

On 8/9/2022 1:04 PM, jimc...@gmail.com wrote:
> On Tuesday, August 9, 2022 at 9:06:54 AM UTC-7, tim...@timlank.com wrote:
>> On Tuesday, August 9, 2022 at 9:43:08 AM UTC-4, chris wrote:
>>> That's the pessimistic view, but if vsi keep at it in the long term,
>>> there's no reason why it should not be competitive in respect of the
>>> points you are making. There's been a huge effort just to get it
>>> ported to X86, so perhaps no, in the short term, but who can predict
>>> then future ?.
>>>
>>> Without hope, vision and a plan, there is no future...
>>>
>>> Chris
>> Would anyone say whether there is a shortage of System Managers, or a surplus?

Back in the day there was such a position as System Manager. Perhaps today
there is much less demand. As an example, a product I'm aware of has an
installation where the system is set up to support the application(s), and
independent running of the system is not desired. The users have procedures
available for all that they must do. Even adding and removing user accounts is
run from a script, in a captive account.

>> If you think there is a surplus, then I’d not consider it worth my time and effort.

If anything, there is a shortage, and that is one of the complaints about VMS,
the difficulty to find experienced people. The trick is to be able to find the
companies that need VMS help.

One problem is that many VMS sites have been running VMS for a long time, 30-40
years even, and seem to recall the salaries from back at that time.

>> On the related note, I don't expect going to x86_64 will bring any new customers to the platform. That ship has sailed a long > time ago. The time for that would have been in the Compaq/Alpha days (pre-linux boom).
>
> The engineering investments needed to get OpenVMS to be competitive with modern server products would be massive. Re-igniting investments in open source components running on top of OpenVMS could help the team scale tremendously, but it's not clear VSI has the resources or even the desire to achieve competitive parity with modern operating systems.
>

I see things a bit differently, but, I will admit that perhaps I don't see so well.

The term "server" might be a bit hard to totally define. People do different
things with computers. One person's "server" might not be another person's
"server".

I don't expect VMS to compete for the same jobs as other systems. Rather, I
look for VMS to sell to it's strengths, and not try to out-do the so called
"modern server products".

As an example, trying to compete using Apache as a web server won't work so
well. Apache gets more attention in Linux environments. Rather, perhaps use
WASD and get better results, if running a web server on VMS. Myself, I'm not
too interested in web server software.

Some things, TCP/IP, SSH, SSL, and such will be needed for all but a stand alone
system, and even then, can be used for terminal sessions.

--
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 8/9/2022 12:06 PM, Tim Lank wrote:
> Would anyone say whether there is a shortage of System Managers, or a surplus?
>
> If you think there is a surplus, then I’d not consider it worth my time and effort.

Very difficult to say - VMS is a niche market today with
little industry attention - and the specifics may depend
on the location.

But if I am to look in my crystal ball, then it
says:
* very few 100% VMS system manager jobs
* some jobs with a combination of VMS system
management and other OS sysadmin
* some jobs with a combination of VMS system
management and VMS development
* lots of VMS people retiring and practically
no new VMS people

I believe the number of VMS jobs compared to
the number of people looking for VMS jobs are
fine.

But the VMS jobs may be difficult to find and you may
have to relocate if remote work with occasionally
travel is not an option.

There are VMS job ads, but based on what has been
commented here then a large portion of them are
consulting companies looking to pay peanuts.

But if you are not in a hurry you could keep
looking until the right job at the right location
is there.

Arne

On 8/9/2022 12:06 PM, Tim Lank wrote:
> On the related note, I don't expect going to x86_64 will bring any
> new customers to the platform. That ship has sailed a long time ago.
> The time for that would have been in the Compaq/Alpha days (pre-linux
> boom).

For VMS to be long term viable it has to.

But VSI's current problem is to get the existing
Alpha and Itanium customers on x86-64.

Getting new customers is huge task waiting.

Arne

On Tuesday, August 9, 2022 at 4:44:27 PM UTC-4, Arne Vajhøj wrote:
> On 8/9/2022 12:06 PM, Tim Lank wrote:
> > On the related note, I don't expect going to x86_64 will bring any
> > new customers to the platform. That ship has sailed a long time ago.
> > The time for that would have been in the Compaq/Alpha days (pre-linux
> > boom).
> For VMS to be long term viable it has to.
>
> But VSI's current problem is to get the existing
> Alpha and Itanium customers on x86-64.
>
> Getting new customers is huge task waiting.
>
> Arne

Thank you to everyone that contributed to this thread.

Here are my takeaways:

Pros:
- shortage of System Managers
- lots of VMS people retiring and practically no new VMS people
(both would make sense given their likely average age and the duration of how long OpenVMS has been relatively out of the Industry eye/favor)

Cons:
- finding companies that need VMS help
(exactly - where would I even find these jobs - what job search sites?)
- salaries are outdated
(not worth the opportunity cost)
- very few 100% VMS system manager jobs
- some jobs with a combination of VMS system
management and other OS sysadmin
(I am trying to get away from other OS sysadmin)
- some jobs with a combination of VMS system
management and VMS development
(I'm definitely not a developer type)
- I believe the number of VMS jobs compared to
the number of people looking for VMS jobs are
fine. (i.e. supply~=demand - conflicting information here from above)
- may have to relocate if remote work with occasionally
travel is not an option.
(I would most likely need remote with occasional travel)
- large portion of VMS job ads are
consulting companies looking to pay peanuts.
(not worth the opportunity cost)

On 2022-08-09 11:23:05 +0000, Tim Lank said:

> I'm hoping this group might be able to help advise.
>
> About 30 years ago I used to work with VMS before I moved to the
> Unix/Linux world.
>
> I have about 15 years left in my career and I was interested in making
> a change back to OpenVMS.
>
> Before cracking open the books again and studying up along with the
> hobbyist license that I have going here at home, I wanted to get a feel
> of who still uses the O/S and what level of opportunity might exist for
> a second-career. I realize that the OpenVMS customer base is likely
> not growing much, or at all.
>
> How many OpenVMS shops still exist in the U.S.? Is it true that many
> System Managers have retired at this point, leaving a shortage? Would
> you encourage or discourage an effort like mine? Is it worth the time
> and effort?

There's not a great deal of demand for OpenVMS folks; app developers or
administrators. What openings are around tend to be replacements or
backfilling of positions from retirements and such, or can be hiring
associated with an app port or other specific tasks or service
offerings.

Lots of existing production apps around, some actively maintained and some not.

VSI does provide a means for customers to avoid porting off of OpenVMS
until and unless the customer needs or wants to port.

Wholly new-to-OpenVMS vendors with new-to-OpenVMS apps are vanishingly
rare. And as was recently discussed around here, DECnet FAL support
just doesn't seem to appeal to enough new folks. 😜

More generally, OpenVMS is not feature competitive, and not soon
feature competitive. VSI is working diligently and is addressing some
of the gaps here, including the migration to LLVM, and the migration to
x86-64 hardware. Which means VSI necessarily targets existing apps and
related niches for current and new work, as work shifts away from the
port.

For hardware choices, Itanium is gone, and Alpha is further gone. Which
leaves x86-64 for servers, or low-volume and more expensive boutique
platforms, or platforms earlier in any potential adoption cycle. Choice
of platform also ties into the availability of existing tooling with
compatible licenses, and other details.

VSI is approaching a decade for the x86-64 port underway, though that
also involved creating and staffing a new business. Last big hunk
remaining on the current roadmap is the tooling. What else VSI might
plan past that? https://vmssoftware.com/about/roadmap/

As mentioned else-thread and as translated from management-speak,
"staff shortage" means the employer is loathe to get into a wage
competition for staff. An employer that is unwilling to offer
sufficient money to attract the staffing. These claims can also serve
as the foundation for increasing the workloads on individual staff, and
as a means to "justify" lowered customer service or fewer offerings or
other such. Any employer can hire more staff by offering competitive
wages and compensation, of course. If an OpenVMS employer offered
Silicon Valley wages and remote work and competitive benefits for
instance, most any employer around can be flush with OpenVMS staff,
both those established and senior, and those able and willing to be
trained.

There can be some other opportunities here for you, though. You are
potentially well positioned to assist with porting existing apps off of
OpenVMS, or connecting into apps on OpenVMS or exporting data from apps
on OpenVMS, for instance. A whole lot of the easier-to-port apps have
already been ported off OpenVMS, too.

Can you find an OpenVMS job? Likely. Whether the job requires
relocation? Sufficient wages and benefits? Whether the work is
interesting? Whether the job can last as long as you want? All your
decision.

--
Pure Personal Opinion | HoffmanLabs LLC

On Wednesday, August 10, 2022 at 8:44:27 AM UTC+12, Arne Vajhøj wrote:
> On 8/9/2022 12:06 PM, Tim Lank wrote:
> > On the related note, I don't expect going to x86_64 will bring any
> > new customers to the platform. That ship has sailed a long time ago.
> > The time for that would have been in the Compaq/Alpha days (pre-linux
> > boom).
> For VMS to be long term viable it has to.
>
> But VSI's current problem is to get the existing
> Alpha and Itanium customers on x86-64.
>
> Getting new customers is huge task waiting.

I think it is also a task VSI is not willing (or not able) to undertake. To seriously
compete with Linux they'd have to actually open-source OpenVMS and accept
outside contributions.

I don't know that any other proprietary operating system is successfully
competing with Linux outside of the desktop (and I guess mobile) today.
Even Windows Server kind of looks to be in a state of managed decline at
this point with Microsoft porting a lot of their stuff to Linux and adding Linux
compatibility to desktop Windows.

I guess the real question VSI has to answer for potential customers who
don't already have significant investments in OpenVMS-specific software
is why rent OpenVMS to run Linux software when Linux already does that
for free?

On 9/08/2022 7:23 pm, Tim Lank wrote:
> I'm hoping this group might be able to help advise.
>
> About 30 years ago I used to work with VMS before I moved to the
> Unix/Linux world.
>
> I have about 15 years left in my career and I was interested in
> making a change back to OpenVMS.
>
> Before cracking open the books again and studying up along with the
> hobbyist license that I have going here at home, I wanted to get a
> feel of who still uses the O/S and what level of opportunity might
> exist for a second-career. I realize that the OpenVMS customer base
> is likely not growing much, or at all.
>
> How many OpenVMS shops still exist in the U.S.? Is it true that many
> System Managers have retired at this point, leaving a shortage?
> Would you encourage or discourage an effort like mine? Is it worth
> the time and effort?

What is all this bullshit?

If you're independently wealthy and want VMS for its beauty then knock
yourself out! If you need to earn a living then stick to Linux.

If the answer is A then I have a VAX, Alpha, and Itanium to sell you

On 8/10/2022 2:50 AM, Richard Maher wrote:
> If you're independently wealthy and want VMS for its beauty then knock
> yourself out! If you need to earn a living then stick to Linux.

Linux is where there are most sysadmin and developer jobs. By far.

But one does not necessarily need to go with the most common choice.
Most common does not imply best.

There is a practical advantage with the common choice though. If we
say there are 10000 Linux job sin the US then it is highly likely to be
one relative close - if there are 10 good VMS jobs then it is way more
likely that that they all are out of commute range.

Arne

On 8/9/2022 7:45 PM, David Goodwin wrote:
> On Wednesday, August 10, 2022 at 8:44:27 AM UTC+12, Arne Vajhøj wrote:
>> On 8/9/2022 12:06 PM, Tim Lank wrote:
>>> On the related note, I don't expect going to x86_64 will bring any
>>> new customers to the platform. That ship has sailed a long time ago.
>>> The time for that would have been in the Compaq/Alpha days (pre-linux
>>> boom).
>> For VMS to be long term viable it has to.
>>
>> But VSI's current problem is to get the existing
>> Alpha and Itanium customers on x86-64.
>>
>> Getting new customers is huge task waiting.
>
> I think it is also a task VSI is not willing (or not able) to undertake. To seriously
> compete with Linux they'd have to actually open-source OpenVMS and accept
> outside contributions.

I don't see that as obvious.

Current VMS users does not seem particular interested in seeing VMS
as open source.

Current VMS does not seem interested in contributing to open source.

Most open source OS besides Linux is struggling. So I would not expect
new VMS users to be that much different.

> I don't know that any other proprietary operating system is successfully
> competing with Linux outside of the desktop (and I guess mobile) today.

True but also a bit misleading. There is no OS successfully (as in
growing) competing with Linux on servers in the cloud & container
world - closed source or open source.

And I think that the closed source (Windows, z/OS, i/OS, AIX, Solaris
etc.) are doing better than the open source (FreeBDS, NetBSD, OpenBSD,
Illumos, OpenIndiana, ReactOS etc.).

> Even Windows Server kind of looks to be in a state of managed decline at
> this point with Microsoft porting a lot of their stuff to Linux and adding Linux
> compatibility to desktop Windows.

WSL is a VM that run Linux to enable Linux builds and test.

That is not Linux compatibility.

> I guess the real question VSI has to answer for potential customers who
> don't already have significant investments in OpenVMS-specific software
> is why rent OpenVMS to run Linux software when Linux already does that
> for free?

Good question.

But lots of companies actually pay for Linux (Redhat subscription).

There are companies that are willing to pay if the cost is low and the
service is good.

Arne

On Wednesday, August 10, 2022 at 1:44:23 PM UTC-4, Arne Vajhøj wrote:
> On 8/9/2022 7:45 PM, David Goodwin wrote:
> > On Wednesday, August 10, 2022 at 8:44:27 AM UTC+12, Arne Vajhøj wrote:
> >> On 8/9/2022 12:06 PM, Tim Lank wrote:
> >>> On the related note, I don't expect going to x86_64 will bring any
> >>> new customers to the platform. That ship has sailed a long time ago.
> >>> The time for that would have been in the Compaq/Alpha days (pre-linux
> >>> boom).
> >> For VMS to be long term viable it has to.
> >>
> >> But VSI's current problem is to get the existing
> >> Alpha and Itanium customers on x86-64.
> >>
> >> Getting new customers is huge task waiting.
> >
> > I think it is also a task VSI is not willing (or not able) to undertake.. To seriously
> > compete with Linux they'd have to actually open-source OpenVMS and accept
> > outside contributions.
> I don't see that as obvious.
>
> Current VMS users does not seem particular interested in seeing VMS
> as open source.
>
> Current VMS does not seem interested in contributing to open source.
>
> Most open source OS besides Linux is struggling. So I would not expect
> new VMS users to be that much different.
> > I don't know that any other proprietary operating system is successfully
> > competing with Linux outside of the desktop (and I guess mobile) today.
> True but also a bit misleading. There is no OS successfully (as in
> growing) competing with Linux on servers in the cloud & container
> world - closed source or open source.
>
> And I think that the closed source (Windows, z/OS, i/OS, AIX, Solaris
> etc.) are doing better than the open source (FreeBDS, NetBSD, OpenBSD,
> Illumos, OpenIndiana, ReactOS etc.).
> > Even Windows Server kind of looks to be in a state of managed decline at
> > this point with Microsoft porting a lot of their stuff to Linux and adding Linux
> > compatibility to desktop Windows.
> WSL is a VM that run Linux to enable Linux builds and test.
>
> That is not Linux compatibility.
> > I guess the real question VSI has to answer for potential customers who
> > don't already have significant investments in OpenVMS-specific software
> > is why rent OpenVMS to run Linux software when Linux already does that
> > for free?
> Good question.
>
> But lots of companies actually pay for Linux (Redhat subscription).
>
> There are companies that are willing to pay if the cost is low and the
> service is good.
>
> Arne

"But lots of companies actually pay for Linux (Redhat subscription).
There are companies that are willing to pay if the cost is low and the
service is good."

Both are true and now that IBM has bought Red Hat - those costs have gone up.

OpenVMS x86-64 would need to compete in that space on costs and yet with high levels of support. But as you say, probably exclusively to existing OpenVMS customers, since they can't compete on the open source features.

Tim

On 10/08/2022 8:15 pm, Arne Vajhøj wrote:
> On 8/10/2022 2:50 AM, Richard Maher wrote:
>> If you're independently wealthy and want VMS for its beauty then
>> knock yourself out! If you need to earn a living then stick to
>> Linux.
>
> Linux is where there are most sysadmin and developer jobs. By far.
>
> But one does not necessarily need to go with the most common choice.
> Most common does not imply best.
>
> There is a practical advantage with the common choice though. If we
> say there are 10000 Linux job sin the US then it is highly likely to
> be one relative close - if there are 10 good VMS jobs then it is way
> more likely that that they all are out of commute range.
>
> Arne
>
>

Mate, I've learnt .NET Framework now Core, C#, WebAPI, SQL Server,
Javscript ES 2015+, HTML, DOM, CSS but all these <best jobs out there
want crap like React, Angular, Vue, and Entity Framework :-(

On 8/11/2022 8:27 PM, Richard Maher wrote:
> Mate, I've learnt .NET Framework now Core, C#, WebAPI, SQL Server,
> Javscript ES 2015+, HTML, DOM, CSS but all these <best jobs out there
> want crap like React, Angular, Vue, and Entity Framework :-(

Lear EF (and maybe Dapper!) to complete your server side skills.

And go for companies that do not not believe in the "full stack
developer" hype.

..NET backend and React/Angular/Vue frontend are very different -
I don't think it is wise to try and cover both.

Arne

On 8/11/22 7:27 PM, Richard Maher wrote:
> On 10/08/2022 8:15 pm, Arne Vajhøj wrote:
>> On 8/10/2022 2:50 AM, Richard Maher wrote:
>>> If you're independently wealthy and want VMS for its beauty then
>>> knock yourself out! If you need to earn a living then stick to
>>> Linux.
>>
>> Linux is where there are most sysadmin and developer jobs. By far.
>>
>> But one does not necessarily need to go with the most common choice.
>> Most common does not imply best.
>>
>> There is a practical advantage with the common choice though. If we
>> say there are 10000 Linux job sin the US then it is highly likely to
>> be one relative close - if there are 10 good VMS jobs then it is way
>> more likely that that they all are out of commute range.
>>
>> Arne
>>
>>
>
>
> Mate, I've learnt .NET Framework now Core,

No such thing. As of .NET 6, what was Core is just part of .NET,
including all the cross-platform bits.

> C#, WebAPI, SQL Server,
> Javscript ES 2015+, HTML, DOM, CSS but all these <best jobs out there
> want crap like React, Angular, Vue, and Entity Framework :-(

From limited experience of both, EFCore seems slightly less horrible
than Hibernate, which isn't saying much. It works, and if you don't
like or understand SQL and do like and understand whatever OOP language
you're running, then you'll like the persistence engines, as they call
them. If you care about performance, you'll want to profile what it's
doing and make sure it isn't doing things like making multiple
unnecessary round trips the database, e.g., once to count how may rows
a query will return and another time to run the actual query.

The front end frameworks are very large and have steep learning curves.
If you know JavaScript you can debug them somewhat without knowing all
the details, but actually writing new stuff from scratch is hard to do
part-time.

On 8/11/2022 10:02 PM, Craig A. Berry wrote:
> On 8/11/22 7:27 PM, Richard Maher wrote:
>> Mate, I've learnt .NET Framework now Core,
>
> No such thing.  As of .NET 6, what was Core is just part of .NET,
> including all the cross-platform bits.

MS naming and versioning can be messy.

There was .NET FX 4.x and .NET Core 3.x - then MS EOL'ed .NET FX and
renamed .NET Core 4.0 to .NET 5.0 (and .NET 6.0 is then really
..NET Core 5.0).

>> C#, WebAPI, SQL Server, Javscript ES 2015+, HTML, DOM, CSS but all
>> these <best jobs out there want crap like React, Angular, Vue, and
>> Entity Framework :-(
>
> From limited experience of both, EFCore seems slightly less horrible
> than Hibernate, which isn't saying much.  It works, and if you don't
> like or understand SQL and do like and understand whatever OOP language
> you're running, then you'll like the persistence engines, as they call
> them.

Even if one knows SQL then an ORM will usually result in
significant less code and less code means easier maintenance.

>  If you care about performance, you'll want to profile what it's
> doing and make sure it isn't doing things like making multiple
> unnecessary round trips the database, e.g., once to count how may rows
> a query will return and another time to run the actual query.

Dumping the generated SQL should be mandatory for ORM usage.

Arne

On 12/08/2022 8:26 pm, Arne Vajhøj wrote:
>
> Even if one knows SQL then an ORM will usually result in
> significant less code and less code means easier maintenance.
>

BOLLOCKS!!!

On 8/13/2022 11:25 PM, Richard Maher wrote:
> On 12/08/2022 8:26 pm, Arne Vajhøj wrote:
>> Even if one knows SQL then an ORM will usually result in
>> significant less code and less code means easier maintenance.
>
> BOLLOCKS!!!

No.

Try compare:

public List<T1> GetRangeOfPK(int f1_start, int f1_end)
{
List<T1> res = new List<T1>();
using(IDbConnection con = GetConnection())
{
con.Open();
using(IDbCommand cmd = con.CreateCommand())
{
cmd.CommandText = "SELECT f1,f2 FROM t1 WHERE f1
BETWEEN @f1_start AND @f1_end";
cmd.Connection = con;
IDbDataParameter pf1_start = cmd.CreateParameter();
pf1_start.ParameterName = "@f1_start";
pf1_start.DbType = DbType.Int32;
pf1_start.Value = f1_start;
cmd.Parameters.Add(pf1_start);
IDbDataParameter pf1_end = cmd.CreateParameter();
pf1_end.ParameterName = "@f1_end";
pf1_end.DbType = DbType.Int32;
pf1_end.Value = f1_end;
cmd.Parameters.Add(pf1_end);
using(IDataReader rdr = cmd.ExecuteReader())
{
while(rdr.Read())
{
res.Add(new T1((int)rdr["f1"],
(string)rdr["f2"]));
}
}
}
}
return res;
}

with:

public List<T1> GetRangeOfPK(int f1_start, int f1_end)
{
using(MyDbContext db = new MyDbContext(constrkey))
{
return db.T1.Where(t1 => f1_start <= t1.F1 && t1.F1 <=
f1_end).ToList();
}
}

The ORM code is at a higher abstraction level and much shorter.

Arne

On 15/08/2022 2:50 am, Arne Vajhøj wrote:
> On 8/13/2022 11:25 PM, Richard Maher wrote:
>> On 12/08/2022 8:26 pm, Arne Vajhøj wrote:
>>> Even if one knows SQL then an ORM will usually result in
>>> significant less code and less code means easier maintenance.
>>
>> BOLLOCKS!!!
>
> No.
>
> Try compare:
>
> public List<T1> GetRangeOfPK(int f1_start, int f1_end) { List<T1> res
> = new List<T1>(); using(IDbConnection con = GetConnection()) {
> con.Open(); using(IDbCommand cmd = con.CreateCommand()) {
> cmd.CommandText = "SELECT f1,f2 FROM t1 WHERE f1 BETWEEN @f1_start
> AND @f1_end"; cmd.Connection = con; IDbDataParameter pf1_start =
> cmd.CreateParameter(); pf1_start.ParameterName = "@f1_start";
> pf1_start.DbType = DbType.Int32; pf1_start.Value = f1_start;
> cmd.Parameters.Add(pf1_start); IDbDataParameter pf1_end =
> cmd.CreateParameter(); pf1_end.ParameterName = "@f1_end";
> pf1_end.DbType = DbType.Int32; pf1_end.Value = f1_end;
> cmd.Parameters.Add(pf1_end); using(IDataReader rdr =
> cmd.ExecuteReader()) { while(rdr.Read()) { res.Add(new
> T1((int)rdr["f1"], (string)rdr["f2"])); } } } } return res; }
>
> with:
>
> public List<T1> GetRangeOfPK(int f1_start, int f1_end) {
> using(MyDbContext db = new MyDbContext(constrkey)) { return
> db.T1.Where(t1 => f1_start <= t1.F1 && t1.F1 <= f1_end).ToList(); }
> }
>
> The ORM code is at a higher abstraction level and much shorter.
>
> Arne
>
>
>

Mate, we can all abstract away code behind smoke and mirrors :-(

How 'bout I give you an amazing stored procedure that results in minimum
C# interface? All write operations should be SPs any way. Or I just
return a collection/iterable so you can still get your jollies with Lambdas.

As I keep telling OO people "It's not all about reducing your typing
effort!"

On 8/14/2022 10:24 PM, Richard Maher wrote:
> On 15/08/2022 2:50 am, Arne Vajhøj wrote:
>> On 8/13/2022 11:25 PM, Richard Maher wrote:
>>> On 12/08/2022 8:26 pm, Arne Vajhøj wrote:
>>>> Even if one knows SQL then an ORM will usually result in significant less
>>>> code and less code means easier maintenance.
>>>
>>> BOLLOCKS!!!
>>
>> No.
>>
>> Try compare:
>>
>> public List<T1> GetRangeOfPK(int f1_start, int f1_end) { List<T1> res
>> = new List<T1>(); using(IDbConnection con = GetConnection()) { con.Open();
>> using(IDbCommand cmd = con.CreateCommand()) { cmd.CommandText = "SELECT f1,f2
>> FROM t1 WHERE f1 BETWEEN @f1_start
>> AND @f1_end"; cmd.Connection = con; IDbDataParameter pf1_start =
>> cmd.CreateParameter(); pf1_start.ParameterName = "@f1_start"; pf1_start.DbType
>> = DbType.Int32; pf1_start.Value = f1_start; cmd.Parameters.Add(pf1_start);
>> IDbDataParameter pf1_end =
>> cmd.CreateParameter(); pf1_end.ParameterName = "@f1_end"; pf1_end.DbType =
>> DbType.Int32; pf1_end.Value = f1_end; cmd.Parameters.Add(pf1_end);
>> using(IDataReader rdr =
>> cmd.ExecuteReader()) { while(rdr.Read()) { res.Add(new
>> T1((int)rdr["f1"], (string)rdr["f2"])); } } } } return res; }
>>
>> with:
>>
>> public List<T1> GetRangeOfPK(int f1_start, int f1_end) { using(MyDbContext db
>> = new MyDbContext(constrkey)) { return
>> db.T1.Where(t1 => f1_start <= t1.F1 && t1.F1 <= f1_end).ToList(); } }
>>
>> The ORM code is at a higher abstraction level and much shorter.
>>
>> Arne
>>
>>
>>
>
> Mate, we can all abstract away code behind smoke and mirrors :-(
>
> How 'bout I give you an amazing stored procedure that results in minimum C#
> interface? All write operations should be SPs any way. Or I just return a
> collection/iterable so you can still get your jollies with Lambdas.
>
> As I keep telling OO people "It's not all about reducing your typing effort!"

Agreed 110% ...

Perhaps some objects don't work as well as possible. The OO folks will just say
faster HW makes that not an issue. I think efficiency is always an issue. I
doubt they will ever agree, because they might not like to type?

--
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 8/14/22 1:50 PM, Arne Vajhøj wrote:
> On 8/13/2022 11:25 PM, Richard Maher wrote:
>> On 12/08/2022 8:26 pm, Arne Vajhøj wrote:
>>> Even if one knows SQL then an ORM will usually result in
>>> significant less code and less code means easier maintenance.
>>
>> BOLLOCKS!!!
>
> No.
>
> Try compare:
>
>         public List<T1> GetRangeOfPK(int f1_start, int f1_end)
>         {
>             List<T1> res = new List<T1>();
>             using(IDbConnection con = GetConnection())
>             {
>                 con.Open();
>                 using(IDbCommand cmd = con.CreateCommand())
>                 {
>                     cmd.CommandText = "SELECT f1,f2 FROM t1 WHERE f1
> BETWEEN @f1_start AND @f1_end";
>                     cmd.Connection = con;
>                     IDbDataParameter pf1_start = cmd.CreateParameter();
>                     pf1_start.ParameterName = "@f1_start";
>                     pf1_start.DbType = DbType.Int32;
>                     pf1_start.Value = f1_start;
>                     cmd.Parameters.Add(pf1_start);
>                     IDbDataParameter pf1_end = cmd.CreateParameter();
>                     pf1_end.ParameterName = "@f1_end";
>                     pf1_end.DbType = DbType.Int32;
>                     pf1_end.Value = f1_end;
>                     cmd.Parameters.Add(pf1_end);
>                     using(IDataReader rdr = cmd.ExecuteReader())
>                     {
>                         while(rdr.Read())
>                         {
>                             res.Add(new T1((int)rdr["f1"],
> (string)rdr["f2"]));
>                         }
>                     }
>                 }
>             }
>             return res;
>         }
>
> with:
>
>         public List<T1> GetRangeOfPK(int f1_start, int f1_end)
>         {
>             using(MyDbContext db = new MyDbContext(constrkey))
>             {
>                 return db.T1.Where(t1 => f1_start <= t1.F1 && t1.F1 <=
> f1_end).ToList();
>             }
>         }
>
> The ORM code is at a higher abstraction level and much shorter.

The first one could be a lot shorter if you write some utility code to
set up the parameters and load the DataReader into a list. This one
does that for stored proc calls but could be extended to take simple
SELECT statements:

https://github.com/snickler/EFCore-FluentStoredProcedure

On 2022-08-15, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Perhaps some objects don't work as well as possible. The OO folks will just say
> faster HW makes that not an issue. I think efficiency is always an issue. I
> doubt they will ever agree, because they might not like to type?
>

OO, done properly, gives you way more maintainable code.

Simon.

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