Discussion:
OpenVMS developmen integration with Azure DevOps.
(too old to reply)
Jan-Erik Söderholm
2021-09-01 09:47:25 UTC
Permalink
Hi.

There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.

They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.

Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?

Has anyone looked at other tools (DECset?) to do anything in
this direction?

Regards,
Jan-Erik.
Arne Vajhøj
2021-09-01 12:35:25 UTC
Permalink
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.

But most things are possible with some effort.

I know that:
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops

https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/

https://medium.com/@bbenz/azure-devops-and-jenkins-in-perfect-harmony-8c92ff980723

Maybe some of that stuff can be utilized.

Arne
Jan-Erik Söderholm
2021-09-01 14:52:30 UTC
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.
But most things are possible with some effort.
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops
https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/
Maybe some of that stuff can be utilized.
Arne
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)

We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?

Ah, well. Not my idea to look at DevOps. It also seems as we are going
to Agile/Scrum also. Where are those retirment plans...
Arne Vajhøj
2021-09-01 15:16:36 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.
But most things are possible with some effort.
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops
https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/
Maybe some of that stuff can be utilized.
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
:-)

But if they want to proceed then there may be some ways to integrate.
Post by Jan-Erik Söderholm
Ah, well. Not my idea to look at DevOps. It also seems as we are going
to Agile/Scrum also. Where are those retirment plans...
There are some people here that prefer measles over Scrum, but if the
project is a decent fit for Scrum, then it is not bad. In fact there are
probably many of such projects that are doing things very Scrum like
even though they have never heard of Scrum.

Arne
Craig A. Berry
2021-09-01 15:59:09 UTC
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.
But most things are possible with some effort.
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops
https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/
Maybe some of that stuff can be utilized.
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
:-)
But if they want to proceed then there may be some ways to integrate.
I couldn't find anything quickly about the Azure DevOps test runner. I
know the GitHub CI test runner is a .NET Core application so it would
have to be either ported (requiring .NET Core to be ported) or
completely reimplemented to report test results from VMS. It's possible
Azure DevOps has a published API and writing a client for it wouldn't be
too horrible. But more work than on other platforms where all the
pieces are already there.
Arne Vajhøj
2021-09-01 18:16:55 UTC
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.
But most things are possible with some effort.
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops
https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/
Maybe some of that stuff can be utilized.
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
:-)
But if they want to proceed then there may be some ways to integrate.
I couldn't find anything quickly about the Azure DevOps test runner.  I
know the GitHub CI test runner is a .NET Core application so it would
have to be either ported (requiring .NET Core to be ported) or
completely reimplemented to report test results from VMS.  It's possible
Azure DevOps has a published API and writing a client for it wouldn't be
too horrible.  But more work than on other platforms where all the
pieces are already there.
I believe Azure DevOps only supports .NET and Selenium
by itself.

But it can be extended.

And someone has apparently extended it to work with Jenkins.

And Jenkins can be extended too.

And we know somebody has extended it to work with VMS.

In the devops world it is:
1) Linux
2) Windows
3) Everybody else

Arne
Phillip Helbig (undress to reply)
2021-09-01 17:00:48 UTC
Permalink
Post by Jan-Erik Söderholm
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
Ah, well. Not my idea to look at DevOps. It also seems as we are going
to Agile/Scrum also. Where are those retirment plans...
So glad I retired before I had to use JIRA.

---Steve Lionel
Arne Vajhøj
2021-09-01 18:06:27 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
It also seems as we are going
to Agile/Scrum also. Where are those retirment plans...
So glad I retired before I had to use JIRA.
---Steve Lionel
Jira is a web based bug tracking system.

I don't think it is worse or better than many other such systems.
Bugzilla is supposedly more widely used.

Arne
Phillip Helbig (undress to reply)
2021-09-01 19:05:42 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
It also seems as we are going
to Agile/Scrum also. Where are those retirment plans...
So glad I retired before I had to use JIRA.
---Steve Lionel
Jira is a web based bug tracking system.
I know; I had to use it a bit before I retired. :-) But it is part of
the landscape of Docker, cloud stuff, Jenkins, DevOps, and all that
newfangled stuff.
Post by Arne Vajhøj
I don't think it is worse or better than many other such systems.
I've used a much better system, which had been custom built. :-|
Arne Vajhøj
2021-09-01 22:59:53 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
It also seems as we are going
to Agile/Scrum also. Where are those retirment plans...
So glad I retired before I had to use JIRA.
---Steve Lionel
Jira is a web based bug tracking system.
I know; I had to use it a bit before I retired. :-) But it is part of
the landscape of Docker, cloud stuff, Jenkins, DevOps, and all that
newfangled stuff.
I believe bug tracking systems are way older than containers,
cloud, CI/CD and devops.

They are necessary.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
I don't think it is worse or better than many other such systems.
I've used a much better system, which had been custom built. :-|
Hmmm.

I have used many of such.

And the basics seems pretty identical. Someone create a
bug report by filling out a form, someone assign it to
a developer, the developer fixes the bug and mark it as
fixed, QA verifies that it is fixed.

Then there are the bells and whistles:
- search capability
- automatic generation of release notes
- email notification
- VCS integration
- LDAP authentication
- etc.

But honestly they do not matter much to me.

Arne
Phillip Helbig (undress to reply)
2021-09-02 06:46:44 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
So glad I retired before I had to use JIRA.
---Steve Lionel
Jira is a web based bug tracking system.
I know; I had to use it a bit before I retired. :-) But it is part of
the landscape of Docker, cloud stuff, Jenkins, DevOps, and all that
newfangled stuff.
I believe bug tracking systems are way older than containers,
cloud, CI/CD and devops.
In general, yes. My point is that Jira seems to be commonly used by
those who also use containers, DevOps, etc.
Post by Arne Vajhøj
They are necessary.
Of course.
Post by Arne Vajhøj
And the basics seems pretty identical. Someone create a
bug report by filling out a form, someone assign it to
a developer, the developer fixes the bug and mark it as
fixed, QA verifies that it is fixed.
- search capability
- automatic generation of release notes
- email notification
- VCS integration
- LDAP authentication
- etc.
Right. The point is that if one compares two systems and a feature
commonly used by many people in one is lacking in the other, then there
is an important difference.
Rich Alderson
2021-09-03 01:15:11 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Jira is a web based bug tracking system.
I know; I had to use it a bit before I retired. :-) But it is part of
the landscape of Docker, cloud stuff, Jenkins, DevOps, and all that
newfangled stuff.
I believe bug tracking systems are way older than containers,
cloud, CI/CD and devops.
Such as DEC's SPR system, for instance...
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Simon Clubley
2021-09-03 18:37:34 UTC
Permalink
Post by Rich Alderson
Post by Arne Vajhøj
I believe bug tracking systems are way older than containers,
cloud, CI/CD and devops.
Such as DEC's SPR system, for instance...
Yeah, but we have moved on a bit from scribbling a problem onto a
paper form and then sending it in the post to DEC. :-)

OTOH, I wonder how many useless SPR submissions DEC had to deal with
in those days compared to the number of high quality submissions
they received ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-09-01 21:31:48 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.
But most things are possible with some effort.
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops
https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/
Maybe some of that stuff can be utilized.
Arne
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
Right, so he didn't know what he was talking about, huh?

Who wants to follow this pied piper into the swamp, and worse?
Post by Jan-Erik Söderholm
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
As observer, the guy had no idea what he was talking about.

Some question for the jerk ...

The current system is working just fine, why should we take your advice?

What will we get? A sideways move, at best, and more likely bugs and less.

Who is going to pay for this?

What is the business case to do anything?

The list is long ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-09-01 23:05:19 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.
But most things are possible with some effort.
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops
https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/
Maybe some of that stuff can be utilized.
Arne
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
Right, so he didn't know what he was talking about, huh?
He knew very well what he was talkning about! Azure Devops...
But he didn't know a) that we use OpenVMS and b) what OpenVMS is.
That was not his fault.
Post by Dave Froble
Who wants to follow this pied piper into the swamp, and worse?
Post by Jan-Erik Söderholm
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
As observer, the guy had no idea what he was talking about.
He very well did. Not his fault he hadn't been updated correctly
by the guy who had asked him to run the presentation for our group.
Post by Dave Froble
Some question for the jerk ...
The current system is working just fine, why should we take your advice?
The *system* works just fine. But our development processes does not.
Post by Dave Froble
What will we get?  A sideways move, at best, and more likely bugs and less.
We might end up using DevOps just to get a better development process.
That is, the administrative part. Technically we might keep what we have.
Post by Dave Froble
Who is going to pay for this?
Does it matter? The goal is to get a better development process and
better deliveries of functionallity to the business.
Post by Dave Froble
What is the business case to do anything?
The mess within the development processes.
Post by Dave Froble
The list is long ....
Now, *I* is not convinced that any new support system will help
us, as long as we have the organization and the staffing we have.
We have a group of "developers" that have none or very little
background from VMS. They might know Cobol, but...

I spend a considerable part of by consulting hours to "support"
our developers with guidings and suggestion around the more basic
OpenVMS stuff. How logical names works. How mailboxes works.
A lot of other basic VMS stuff. 6 years now and 3 major change
of staff and it is not getting better.

But they are payed 1/3 of my hourly rate...
k***@gmail.com
2021-09-02 00:25:10 UTC
Permalink
-----Original Message-----
Söderholm via Info-vax
Sent: September-01-21 8:05 PM
Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
DevOps.
[snip]
Post by Dave Froble
What is the business case to do anything?
The mess within the development processes.
Post by Dave Froble
The list is long ....
Now, *I* is not convinced that any new support system will help us, as long as
we have the organization and the staffing we have.
We have a group of "developers" that have none or very little background
from VMS. They might know Cobol, but...
I spend a considerable part of by consulting hours to "support"
our developers with guidings and suggestion around the more basic
OpenVMS stuff. How logical names works. How mailboxes works.
A lot of other basic VMS stuff. 6 years now and 3 major change of staff and it is
not getting better.
But they are payed 1/3 of my hourly rate...
This type of conversation is where I like to trot out this 2014 timeless OpenVMS article:
<https://thedailywtf.com/articles/Jurassic-Programmers->

In terms of Jenkins integration with OpenVMS development:
<https://www.slideshare.net/ecubemarketing/why-nxtware-remote-for-jenkins>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
k***@gmail.com
2021-09-03 20:05:51 UTC
Permalink
-----Original Message-----
Info-vax
Sent: September-02-21 3:34 PM
Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
DevOps.
Post by k***@gmail.com
This type of conversation is where I like to trot out this 2014 timeless
<https://thedailywtf.com/articles/Jurassic-Programmers->
You have posted it before.
And it is very funny.
And such things happen.
But most likely this particular story is made up.
No idea, but You could always contact the author for details on where and/or
what the story was based on.
<https://thedailywtf.com/authors/alex-papadimoulis>
<quote>
SQL Server had been abandoned for indexed files stored on VMS.
...
The rock stars had created a monstrosity of a database, consisting of
hundreds
of undocumented tables </quote>
So the dropped the relational database for VMS index-sequential files, but
when they needed to convert back they had a relational database.
That does not add up.
Not sure where article stated what the repository was when they converted
back. I would have assumed they left the files in RMS indexed files.
<quote>
Multi-tier programming was also abandoned, leaving business calculations
everywhere from within DIBOL code on VMS to the paint routine of a
Windows cont
</quote>
So they dropped multi-tier but have business logic in multiple tiers. That
does
not add up.
They likely had the Dibol business code running on the same server as the
RMS indexed files. As I know you know, placing the App and DB tier on the
same OS instance (even Web) is very common in the OpenVMS world. Placing the
App/DB on the same OS instance is not something typically done in the
Windows/Linux culture (even on VMware, they are separate OS instances).
<quote>
hundreds of undocumented tables tied together with hundreds of
undocumented relations, all glued together with copious amounts of XML
</quote>
Database tables are not glued together by XML.
Not sure, but perhaps its possible (likely?) the article was modified by a
non-technical editor?
<quote>
new team of sharp-minded programmers to completely rewrite the software
as a Windows application using VisualBasic.NET ...
version 2's data structure was built by programmers fresh out of college
</quote>
Some Colleges teach C# but practically none teach VB.NET. New graduates
and VB.NET is just a non-existing combination.
Let's not forget the article was from 2008 - 13 years ago.

Having stated this, the article drives home the point that many, many
companies in the last number of years have been bamboozled into converting
to the next big shiny technology only to find that the grass is not always
greener on the other side. They often learn a very painful and very
expensive lesson. Experienced programmers that understand the company
culture and business logic used in these Apps are critical resources to a
companies future success.

Its why many Med-Large Customers with battle proven applications that run
the business now (albeit on older technologies) now typically choose a
strategy of "upgrade and integrate" v.s. the strategy that vendors all to
often push of "rip and replace".


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Arne Vajhøj
2021-09-04 13:57:30 UTC
Permalink
Post by k***@gmail.com
-----Original Message-----
Info-vax
Sent: September-02-21 3:34 PM
Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
DevOps.
Post by k***@gmail.com
This type of conversation is where I like to trot out this 2014 timeless
<https://thedailywtf.com/articles/Jurassic-Programmers->
You have posted it before.
And it is very funny.
And such things happen.
But most likely this particular story is made up.
No idea, but You could always contact the author for details on where and/or
what the story was based on.
<https://thedailywtf.com/authors/alex-papadimoulis>
<quote>
SQL Server had been abandoned for indexed files stored on VMS.
...
The rock stars had created a monstrosity of a database, consisting of hundreds
of undocumented tables </quote>
So the dropped the relational database for VMS index-sequential files, but
when they needed to convert back they had a relational database.
That does not add up.
Not sure where article stated what the repository was when they converted
back.
See second part of quote above.
Post by k***@gmail.com
I would have assumed they left the files in RMS indexed files.
They said they did in first part of quote above.
Post by k***@gmail.com
<quote>
Multi-tier programming was also abandoned, leaving business calculations
everywhere from within DIBOL code on VMS to the paint routine of a
Windows cont
</quote>
So they dropped multi-tier but have business logic in multiple tiers. That does
not add up.
They likely had the Dibol business code running on the same server as the
RMS indexed files. As I know you know, placing the App and DB tier on the
same OS instance (even Web) is very common in the OpenVMS world. Placing the
App/DB on the same OS instance is not something typically done in the
Windows/Linux culture (even on VMware, they are separate OS instances).
Yes.

But the quote explicitly say code on Windows and VMS - that makes two
tiers.
Post by k***@gmail.com
<quote>
hundreds of undocumented tables tied together with hundreds of
undocumented relations, all glued together with copious amounts of XML
</quote>
Database tables are not glued together by XML.
Not sure, but perhaps its possible (likely?) the article was modified by a
non-technical editor?
That is certainly possible.

But then it may be more of "fiction based on true events" than
"documentary".
Post by k***@gmail.com
<quote>
new team of sharp-minded programmers to completely rewrite the software
as a Windows application using VisualBasic.NET ...
version 2's data structure was built by programmers fresh out of college
</quote>
Some Colleges teach C# but practically none teach VB.NET. New graduates
and VB.NET is just a non-existing combination.
Let's not forget the article was from 2008 - 13 years ago.
Same back then.

VB.NET was never a thing in education. Pascal, C++, Java, C#, Python,
maybe some OCAML or Haskell - not VB.NET. VB.NET existed for the
millions and millions of VB6 and ASP/VBS programmers that existed
late 90's/early 00's.
Post by k***@gmail.com
Having stated this, the article drives home the point that many, many
companies in the last number of years have been bamboozled into converting
to the next big shiny technology only to find that the grass is not always
greener on the other side. They often learn a very painful and very
expensive lesson. Experienced programmers that understand the company
culture and business logic used in these Apps are critical resources to a
companies future success.
Its why many Med-Large Customers with battle proven applications that run
the business now (albeit on older technologies) now typically choose a
strategy of "upgrade and integrate" v.s. the strategy that vendors all to
often push of "rip and replace".
It is a fact that many big IT projects fail. Going over time, over
budget and below expected functionality is common. Being
cancelled after spending lots of money is not unheard of.

Add unrealistic expectations, poor project management
and inexperienced developers and failure changes from
potential risk to almost certainty.

Having developers with domain/company experience is
critical for maintenance, enhancements and small system
migrations. But for large system migrations then I would
prioritize experience with large system migrations over
domain/company experience.

Arne
Dave Froble
2021-09-04 17:16:04 UTC
Permalink
-----Original Message-----
Info-vax
Sent: September-04-21 10:58 AM
Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
DevOps.
Post by k***@gmail.com
-----Original Message-----
via Info-vax
Sent: September-02-21 3:34 PM
Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
DevOps.
Post by k***@gmail.com
This type of conversation is where I like to trot out this 2014 timeless
<https://thedailywtf.com/articles/Jurassic-Programmers->
You have posted it before.
And it is very funny.
And such things happen.
But most likely this particular story is made up.
No idea, but You could always contact the author for details on where
and/or what the story was based on.
<https://thedailywtf.com/authors/alex-papadimoulis>
<quote>
SQL Server had been abandoned for indexed files stored on VMS.
...
The rock stars had created a monstrosity of a database, consisting of
hundreds of undocumented tables </quote>
So the dropped the relational database for VMS index-sequential
files, but when they needed to convert back they had a relational
database.
Post by k***@gmail.com
That does not add up.
Not sure where article stated what the repository was when they
converted back.
See second part of quote above.
Its just an article, but I read it as " but. when they needed to convert back they had a relational database to convert back to RMS files".
Post by k***@gmail.com
I would have assumed they left the files in RMS indexed files.
They said they did in first part of quote above.
Post by k***@gmail.com
<quote>
Multi-tier programming was also abandoned, leaving business
calculations everywhere from within DIBOL code on VMS to the paint
routine of a Windows cont </quote>
So they dropped multi-tier but have business logic in multiple tiers.
That does not add up.
They likely had the Dibol business code running on the same server as
the RMS indexed files. As I know you know, placing the App and DB tier
on the same OS instance (even Web) is very common in the OpenVMS
world. Placing the App/DB on the same OS instance is not something
typically done in the Windows/Linux culture (even on VMware, they are
separate OS instances).
Yes.
But the quote explicitly say code on Windows and VMS - that makes two tiers.
Post by k***@gmail.com
<quote>
hundreds of undocumented tables tied together with hundreds of
undocumented relations, all glued together with copious amounts of
XML </quote>
Database tables are not glued together by XML.
Not sure, but perhaps its possible (likely?) the article was modified
by a non-technical editor?
That is certainly possible.
But then it may be more of "fiction based on true events" than
"documentary".
You could say the same about any article if you analyzed every sentence that had technology in it.
My point is that while there may have been some editing by a non-technical editor (when does that ever happen?), that does not mean the parts of the article is "fiction".
Post by k***@gmail.com
<quote>
new team of sharp-minded programmers to completely rewrite the
software as a Windows application using VisualBasic.NET ...
version 2's data structure was built by programmers fresh out of
college </quote>
Some Colleges teach C# but practically none teach VB.NET. New
graduates and VB.NET is just a non-existing combination.
Let's not forget the article was from 2008 - 13 years ago.
Same back then.
VB.NET was never a thing in education. Pascal, C++, Java, C#, Python, maybe
some OCAML or Haskell - not VB.NET. VB.NET existed for the millions and
millions of VB6 and ASP/VBS programmers that existed late 90's/early 00's.
Post by k***@gmail.com
Having stated this, the article drives home the point that many, many
companies in the last number of years have been bamboozled into
converting to the next big shiny technology only to find that the
grass is not always greener on the other side. They often learn a very
painful and very expensive lesson. Experienced programmers that
understand the company culture and business logic used in these Apps
are critical resources to a companies future success.
Its why many Med-Large Customers with battle proven applications that
run the business now (albeit on older technologies) now typically
choose a strategy of "upgrade and integrate" v.s. the strategy that
vendors all to often push of "rip and replace".
It is a fact that many big IT projects fail. Going over time, over budget and
below expected functionality is common. Being cancelled after spending lots
of money is not unheard of.
Add unrealistic expectations, poor project management and inexperienced
developers and failure changes from potential risk to almost certainty.
Having developers with domain/company experience is critical for
maintenance, enhancements and small system migrations. But for large
system migrations then I would prioritize experience with large system
migrations over domain/company experience.
Arne
While good SW/HW architecture planning is certainly important, one of the toughest parts of large system migrations is not so much the technical bits and bytes, but rather understanding and unravelling the unique business, legal, culture and regulatory requirements that went into all the highly custom application code that supports and/or runs the company critical applications.
In many large migrations, these are often not fully understood because the original programmers are either not there anymore, or perhaps the Apps do not have good documentation (bad docs is also not all on the programmers as they sometimes are way overworked and forced to make trade-offs to meet deadlines).
When large migrations fail, it is usually not for technical reasons only, but rather a failure to integrate the technology with the business requirements.
Hence, why many Customers today prefer "upgrade and integrate" and not "rip and replace".
Regards,
Kerry Main
Kerry dot main at starkgaming dot com
Kerry, there are some who will never agree with your logic. Why?
Because their future prospects depend on their being employed to "rip
and replace", and then attempt to fix all the "oops" that happen.

Are there implementations that are a wreck? Sure. Such need to be
addressed.

But when an application is successfully doing it's job, those who wish
to sup at the hog trouth are sure not doing the company any good.

The real problem is management that doesn't have a clue ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-04 23:21:04 UTC
Permalink
Hence, why many Customers today prefer "upgrade and integrate" and not "rip and replace".
Kerry, there are some who will never agree with your logic.  Why?
Because their future prospects depend on their being employed to "rip
and replace", and then attempt to fix all the "oops" that happen.
Certain software consultant houses has as their business to do
such migrations.

Of course they will recommend to migrate.

That is no different than if you go to a car dealership, then
the sales guy will recommend you to buy a new car.

It is managements responsibility to do their own evaluation about
what makes sense.
Are there implementations that are a wreck?  Sure.  Such need to be
addressed.
But when an application is successfully doing it's job,
That something is working does not mean that it does not
make sense to migrate.

Maybe migrating could deliver the same functionality at
lower cost.

Maybe migrating could provide new capabilities that could
make the business more competitive.

That need to be evaluated.

Also if the old system is doing its job.
The real problem is management that doesn't have a clue ...
In the end everything is managements responsibility.

Good management makes good decisions. Bad management makes
bad decisions.

Arne
Arne Vajhøj
2021-09-04 23:13:40 UTC
Permalink
Vajhøj via Info-vax Sent: September-04-21 10:58 AM On 9/3/2021 4:05
Post by k***@gmail.com
Not sure, but perhaps its possible (likely?) the article was
modified by a non-technical editor?
That is certainly possible.
But then it may be more of "fiction based on true events" than
"documentary".
You could say the same about any article if you analyzed every
sentence that had technology in it.
My point is that while there may have been some editing by a
non-technical editor (when does that ever happen?), that does not
mean the parts of the article is "fiction".
There may be some basis in a real story.

But like 1/3 of the article is simply false.

That is over my threshold for being taken serious.
Post by k***@gmail.com
Having stated this, the article drives home the point that many,
many companies in the last number of years have been bamboozled
into converting to the next big shiny technology only to find
that the grass is not always greener on the other side. They
often learn a very painful and very expensive lesson. Experienced
programmers that understand the company culture and business
logic used in these Apps are critical resources to a companies
future success.
Its why many Med-Large Customers with battle proven applications
that run the business now (albeit on older technologies) now
typically choose a strategy of "upgrade and integrate" v.s. the
strategy that vendors all to often push of "rip and replace".
It is a fact that many big IT projects fail. Going over time, over
budget and below expected functionality is common. Being cancelled
after spending lots of money is not unheard of.
Add unrealistic expectations, poor project management and
inexperienced developers and failure changes from potential risk to
almost certainty.
Having developers with domain/company experience is critical for
maintenance, enhancements and small system migrations. But for
large system migrations then I would prioritize experience with
large system migrations over domain/company experience.
While good SW/HW architecture planning is certainly important, one of
the toughest parts of large system migrations is not so much the
technical bits and bytes, but rather understanding and unravelling
the unique business, legal, culture and regulatory requirements that
went into all the highly custom application code that supports and/or
runs the company critical applications.
In many large migrations, these are often not fully understood
because the original programmers are either not there anymore, or
perhaps the Apps do not have good documentation (bad docs is also not
all on the programmers as they sometimes are way overworked and
forced to make trade-offs to meet deadlines).
When large migrations fail, it is usually not for technical reasons
only, but rather a failure to integrate the technology with the
business requirements.
This is exactly why I think it is more important with people that
know big projects and know how to ensure that everything get
covered than people who knows the existing code base.
Hence, why many Customers today prefer "upgrade and integrate" and
not "rip and replace".
The cost and risk of such migrations rightfully scare many
higher management.

But I think the most important reason for not migrating is
the opportunity cost - the business benefits that could have
been gained if everybody had not been tied up in a migration.

But at some point it may be forced on them:
- something critical goes EOL
- the integration cost with other systems becomes too
high

Arne
Dave Froble
2021-09-02 02:58:31 UTC
Permalink
Jan-Erik, I'm going to argue with you ...

:-)
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
I suspect that typical VMS processes are a few decades behind
modern cloud devops processes.
But most things are possible with some effort.
- John Malmberg & vms-ports use Jenkins for builds
- Jenkins integrate with Azure devops
https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/
Maybe some of that stuff can be utilized.
Arne
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
Right, so he didn't know what he was talking about, huh?
He knew very well what he was talkning about! Azure Devops...
But he didn't know a) that we use OpenVMS and b) what OpenVMS is.
That was not his fault.
He may have known his subject matter, but it seems to me that he didn't
do any preliminary work on understanding his intended audience. Any
decent presenter would think to do so.
Post by Jan-Erik Söderholm
Post by Dave Froble
Who wants to follow this pied piper into the swamp, and worse?
Post by Jan-Erik Söderholm
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
As observer, the guy had no idea what he was talking about.
He very well did. Not his fault he hadn't been updated correctly
by the guy who had asked him to run the presentation for our group.
I'd suggest he didn't do due diligence. I've been in that position a
few times, (tried hard to avoid such), and I made sure I understood my
audience. I hated coming off as uninformed.
Post by Jan-Erik Söderholm
Post by Dave Froble
Some question for the jerk ...
The current system is working just fine, why should we take your advice?
The *system* works just fine. But our development processes does not.
What is the problem there? Perhaps I can help? :-)
Post by Jan-Erik Söderholm
Post by Dave Froble
What will we get? A sideways move, at best, and more likely bugs and less.
We might end up using DevOps just to get a better development process.
That is, the administrative part. Technically we might keep what we have.
Post by Dave Froble
Who is going to pay for this?
Does it matter?
It matters a lot ...

Hire me if you have an unlimited purse ...

:-)
Post by Jan-Erik Söderholm
The goal is to get a better development process and
better deliveries of functionallity to the business.
Any goal needs first a good solution plan ...
Post by Jan-Erik Söderholm
Post by Dave Froble
What is the business case to do anything?
The mess within the development processes.
Which you haven't yet described ...
Post by Jan-Erik Söderholm
Post by Dave Froble
The list is long ....
Now, *I* is not convinced that any new support system will help
us, as long as we have the organization and the staffing we have.
We have a group of "developers" that have none or very little
background from VMS. They might know Cobol, but...
That sounds very strange to me ..
Post by Jan-Erik Söderholm
I spend a considerable part of by consulting hours to "support"
our developers with guidings and suggestion around the more basic
OpenVMS stuff. How logical names works. How mailboxes works.
A lot of other basic VMS stuff. 6 years now and 3 major change
of staff and it is not getting better.
Doesn't seem "right" to me that the developers devise any plans. That
takes someone who knows the environment quite well. Pure coders can
follow a plan. They might not be good at planning. Do we have the
inmates running the asylum?
Post by Jan-Erik Söderholm
But they are payed 1/3 of my hourly rate...
Perhaps now we know the problem ...

:-)

Perhaps I'm spoiled. With our Codis product, a single command will do a
complete build of the application from sources. Perhaps I'm a bit
biased, since I did the design of the procedures. :-)

I do not believe that any generic system could do better, or even as
well. Of course "belief" usually doesn't require actual proof.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phillip Helbig (undress to reply)
2021-09-02 06:54:11 UTC
Permalink
https://xkcd.com/2510/
Arne Vajhøj
2021-09-01 23:10:04 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Right, the guy that made the Azure DevOps presentation from our group
had a hard time to understand why we just didn't copy our source codes
to a Azure VM and just run the build from DevOps... :-)
Right, so he didn't know what he was talking about, huh?
Who wants to follow this pied piper into the swamp, and worse?
Post by Jan-Erik Söderholm
We had to run a quick presentation of OpenVMS on our Alpha dev system.
Oh, so it is Cobol?
Oh, so it is a main-frame?
Oh, so this is not running on X86?
As observer, the guy had no idea what he was talking about.
Some question for the jerk ...
The current system is working just fine, why should we take your advice?
Working fine does not mean that it cannot be improved.

These people may understand the benefits of the new process well, but
given that obviously do not know anything about VMS, then they don't
know anything about the cost to integrate VMS into it. "I see benefits
X but I have no idea what the cost will be" is not a good sales pitch,
Post by Dave Froble
What will we get?  A sideways move, at best, and more likely bugs and less.
Hooking the VMS development process into the company's overall
development process is not likely to change the number of bugs. Same
code base and same people editing the code base - just a different
scripting to do the builds, run the tests and do the deployments.
Post by Dave Froble
Who is going to pay for this?
Relevant question for all changes that require work.

And when talking custom work like here, then the cost is
likely to be pretty high.
Post by Dave Froble
What is the business case to do anything?
A good CI/CD pipeline can provide real value:
- bugs found sooner than later
- testers save time on trivial work, so either the company
save hours or the testers can spend more time testing the
interesting stuff

Arne
John Vottero
2021-09-06 16:59:27 UTC
Permalink
Post by Jan-Erik Söderholm
Hi.
There are talks around our OpenVMS environment and project work
where it is looked at to add Azure DevOps to our work environment.
They are talkning about "pipelines" within Azure DevOps where
the build procedures are setup and the build is run from within
the Azure Devops environment.
Does anyone have any comments around this? Have anyone looked at
using Azure DevOps for their OpenVMS development/test/deploy?
Has anyone looked at other tools (DECset?) to do anything in
this direction?
Regards,
Jan-Erik.
I used Visual Studio and Azure DevOps for OpenVMS development. A build consisted of a PowerShell script that FTPed the source code to an OpenVMS build machine and then kicked off a batch job to do the actual build. We used DevOps for source control and tying code changes to tickets. We didn't use DevOps pipelines for the builds but that wouldn't be hard since the build was a PowerShell script.

The hard part for you will be using PowerShell to kick off an OpenVMS batch job and waiting for it to succeed or fail. We used our own product (JAMS) for that. Information of JAMS is available here: https://www.helpsystems.com/product-lines/jams

I'm retired now but I spent 30 years working on JAMS.

Loading...