Re: [vcf-midatlantic] COBOL: vintage vs. legacy code
"Joseph S. Barrera III via vcf-midatlantic" writes:
On Mon, May 22, 2017 at 7:53 PM, Jeffrey Jonas via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Java and all its variants and environments,
I've been writing Java for almost 20 years and fully expect to be writing in it for another 10.
I've been writing assembly for 40+ years and fully expect to be writing it for another 10+. ;)
On Wed, May 31, 2017 at 11:00 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I've been writing assembly for 40+ years and fully expect to be writing it for another 10+. ;)
Are you asserting that, say, VAX assembly and 6502 assembly are the *same language*? :-)
On May 31, 2017, at 2:36 PM, Joseph S. Barrera III via vcf-midatlantic <vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Wed, May 31, 2017 at 11:00 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I've been writing assembly for 40+ years and fully expect to be writing it for another 10+. ;)
Are you asserting that, say, VAX assembly and 6502 assembly are the *same language*? :-)
Same concepts, even if the target processor is different. FWIW, I was in a code review this week for a few hundred bytes of assembly code. The number of people fluent in assembly at the company is very small, but this product sells several hundred thousand units a year and is very important. The code was in C using a highly optimizing compiler but it couldn’t quite squeeze the code enough once a new feature was added, and going to a slightly larger processor with more RAM (32 bytes) was about four cents more per chip, so switching to assembly was the best approach. Not all computers have 2 TB disk and 32 GB RAM. When you need to save a few bytes, assembly is your friend. Bob
Oh man, do I envy you! Up until about 5 years ago, that was my shop too. Every byte we could save was gold. But now the Intel/"embedded" Linux monster has invaded and we write in C++ and solve our problems by throwing more CPU and memory at them. Sigh... Bill S. -----Original Message----- From: vcf-midatlantic [mailto:vcf-midatlantic-bounces@lists.vintagecomputerfederation.org] On Behalf Of Bob Applegate via vcf-midatlantic Sent: Thursday, June 01, 2017 11:17 AM To: vcf-midatlantic Cc: Bob Applegate Subject: Re: [vcf-midatlantic] COBOL: vintage vs. legacy code
On May 31, 2017, at 2:36 PM, Joseph S. Barrera III via vcf-midatlantic <vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Wed, May 31, 2017 at 11:00 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I've been writing assembly for 40+ years and fully expect to be writing it for another 10+. ;)
Are you asserting that, say, VAX assembly and 6502 assembly are the *same language*? :-)
Same concepts, even if the target processor is different. FWIW, I was in a code review this week for a few hundred bytes of assembly code. The number of people fluent in assembly at the company is very small, but this product sells several hundred thousand units a year and is very important. The code was in C using a highly optimizing compiler but it couldn’t quite squeeze the code enough once a new feature was added, and going to a slightly larger processor with more RAM (32 bytes) was about four cents more per chip, so switching to assembly was the best approach. Not all computers have 2 TB disk and 32 GB RAM. When you need to save a few bytes, assembly is your friend. Bob --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 06/01/2017 11:59 AM, William Sudbrink via vcf-midatlantic wrote:
Oh man, do I envy you! Up until about 5 years ago, that was my shop too. Every byte we could save was gold. But now the Intel/"embedded" Linux monster has invaded and we write in C++ and solve our problems by throwing more CPU and memory at them. Sigh...
http://www.monster.com/ -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Dave wrote:
On 06/01/2017 11:59 AM, William Sudbrink via vcf-midatlantic wrote:
Oh man, do I envy you! Up until about 5 years ago, that was my shop too. Every byte we could save was gold. But now the Intel/"embedded" Linux monster has invaded and we write in C++ and solve our problems by throwing more CPU and memory at them. Sigh...
Yea, yea. I complain, but the money's too good to quit. Plus I'm just getting my house the way I really want it (lab pictures coming soon) and don't want to move. Bill S. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Thu, Jun 1, 2017 at 8:16 AM, Bob Applegate via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
When you need to save a few bytes, assembly is your friend.
Oh, don't misunderstand me, I have no problems with assembly. But the last assembly I wrote was probably back in 1992 or so. Moving from 8080 to 6502 sure felt like a different programming language to me. And then 8088 did too. Addressing modes make a lot of difference.
Joseph S. Barrera III wrote:
On Thu, Jun 1, 2017 at 8:16 AM, Bob Applegate via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
When you need to save a few bytes, assembly is your friend.
Oh, don't misunderstand me, I have no problems with assembly. But the last assembly I wrote was probably back in 1992 or so.
Moving from 8080 to 6502 sure felt like a different programming language to me. And then 8088 did too. Addressing modes make a lot of difference.
True, but compared to a "modern" programmer that can barely understand pointers in his/her high level language... And doesn't "need" to or want to... Arg! You damn kids! Get off my lawn! Bill S. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 06/01/2017 12:24 PM, William Sudbrink via vcf-midatlantic wrote:
When you need to save a few bytes, assembly is your friend.
Oh, don't misunderstand me, I have no problems with assembly. But the last assembly I wrote was probably back in 1992 or so.
Moving from 8080 to 6502 sure felt like a different programming language to me. And then 8088 did too. Addressing modes make a lot of difference.
True, but compared to a "modern" programmer that can barely understand pointers in his/her high level language...
And doesn't "need" to or want to...
Arg! You damn kids! Get off my lawn!
I'm happy to charge exorbitant sums to clean up the messes they make. You should be too. :) -Dave -- Dave McGuire, AK4HZ New Kensington, PA
FWIW, I was in a code review this week for a few hundred bytes of assembly code. The number of people fluent in assembly at the company is very small, but this product sells several hundred thousand units a year and is very important. The code was in C using a highly optimizing compiler but it couldn’t quite squeeze the code enough once a new feature was added, and going to a slightly larger processor with more RAM (32 bytes) was about four cents more per chip, so switching to assembly was the best approach.
Not all computers have 2 TB disk and 32 GB RAM. When you need to save a few bytes, assembly is your friend.
True story: I was talking on the phone just now with a high-level Z-Systems software executive at IBM, who said (unprodded by me), "If you really want to be efficient, go make sure you use the exact right assembler instruction code to get the most out of the system."
On 06/01/2017 03:25 PM, Evan Koblentz via vcf-midatlantic wrote:
True story: I was talking on the phone just now with a high-level Z-Systems software executive at IBM, who said (unprodded by me), "If you really want to be efficient, go make sure you use the exact right assembler instruction code to get the most out of the system."
This has always been the case, on all architectures except the very complex ones with branch delay slots, etc that can be more effectively scheduled by a compiler. It's still very much the case in a very CISC architecture like IBM z. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
True story: I was talking on the phone just now with a high-level Z-Systems software executive at IBM, who said (unprodded by me), "If you really want to be efficient, go make sure you use the exact right assembler instruction code to get the most out of the system."
This has always been the case, on all architectures except the very complex ones with branch delay slots, etc that can be more effectively scheduled by a compiler. It's still very much the case in a very CISC architecture like IBM z.
I'm just saying it was entertaining to hear an IBM exec state it so directly and on-the-record. LOL, you should have heard what this person said * off * the record :) but I will not be publishing that.
This popped up on a screen on SourceForge just now: Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language With billions of lines of COBOL in use, this business language powers a large percentage of every ATM, government, and many other business transactions. Many businesses are looking for new ways to utilize decades of solid business logic without having to replace a mission critical application. Attend this TechBytes series sponsored by Micro Focus and presented by SourceForge to learn how organizations around the world are utilizing existing .NET and Java development teams to integrate and modernize COBOL applications. Attendees will learn: * What tools can be used to ‘free’ business logic from legacy code * Exposing COBOL processes as REST base services * Using COBOL as a .NET or JVM language Don’t wait – register now for these TechBytes to get started. About the Presenter: Michael Bleistein, Principal Architect, at Micro Focus, is a 25-year veteran when it comes to COBOL. Currently he specializes in modernization through .NET, Java, and SOA using Visual COBOL, helping customers understand Micro Focus solutions and how they can be used to combat their business problems.
My question to that is: Is it a problem if everything is working without any issues? I'm a firm believer of not fixing what isn't broken. On Sat, Jun 24, 2017 at 9:37 PM Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
This popped up on a screen on SourceForge just now:
Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language
With billions of lines of COBOL in use, this business language powers a large percentage of every ATM, government, and many other business transactions. Many businesses are looking for new ways to utilize decades of solid business logic without having to replace a mission critical application.
Attend this TechBytes series sponsored by Micro Focus and presented by SourceForge to learn how organizations around the world are utilizing existing .NET and Java development teams to integrate and modernize COBOL applications. Attendees will learn:
* What tools can be used to ‘free’ business logic from legacy code * Exposing COBOL processes as REST base services * Using COBOL as a .NET or JVM language
Don’t wait – register now for these TechBytes to get started.
About the Presenter: Michael Bleistein, Principal Architect, at Micro Focus, is a 25-year veteran when it comes to COBOL. Currently he specializes in modernization through .NET, Java, and SOA using Visual COBOL, helping customers understand Micro Focus solutions and how they can be used to combat their business problems.
-- Normal Person: Hey, it seems that you know a lot. Geek: To be honest, it's due to all the surfing I do. Normal Person: So you go surfing? Normal Person: But I don't think that has anything to do with knowing a lot... Geek: I think that's wrong on a fundamental level. Normal Person: Huh? Huh? What?
It's a problem for salespeople. That's about it. -Dave On 09/15/2017 08:09 AM, Joseph Oprysko via vcf-midatlantic wrote:
My question to that is: Is it a problem if everything is working without any issues? I'm a firm believer of not fixing what isn't broken.
On Sat, Jun 24, 2017 at 9:37 PM Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
This popped up on a screen on SourceForge just now:
Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language
With billions of lines of COBOL in use, this business language powers a large percentage of every ATM, government, and many other business transactions. Many businesses are looking for new ways to utilize decades of solid business logic without having to replace a mission critical application.
Attend this TechBytes series sponsored by Micro Focus and presented by SourceForge to learn how organizations around the world are utilizing existing .NET and Java development teams to integrate and modernize COBOL applications. Attendees will learn:
* What tools can be used to ‘free’ business logic from legacy code * Exposing COBOL processes as REST base services * Using COBOL as a .NET or JVM language
Don’t wait – register now for these TechBytes to get started.
About the Presenter: Michael Bleistein, Principal Architect, at Micro Focus, is a 25-year veteran when it comes to COBOL. Currently he specializes in modernization through .NET, Java, and SOA using Visual COBOL, helping customers understand Micro Focus solutions and how they can be used to combat their business problems.
-- Normal Person: Hey, it seems that you know a lot. Geek: To be honest, it's due to all the surfing I do. Normal Person: So you go surfing? Normal Person: But I don't think that has anything to do with knowing a lot... Geek: I think that's wrong on a fundamental level. Normal Person: Huh? Huh? What?
-- Dave McGuire, AK4HZ New Kensington, PA
On 09/15/2017 08:09 AM, Joseph Oprysko via vcf-midatlantic wrote:
My question to that is: Is it a problem if everything is working without any issues? I'm a firm believer of not fixing what isn't broken.
First let us assume that all code has bugs. "Working" means that given the current environment everything works, not that there are no circumstances under which it will fail What one needs to do is asses the risk that something will occur that breaks it. You may need to understand the code to do this. This can be a simple thing such as a field overflowing, or something more complex such as subtle change in the way the hardware works because the hardware broke and needed to be upgraded. Once you have assessed the risks, you need to decide if you have the capability to fix any bugs. Ig you don't have the capability to fix the hardware or software then what is the business impact of it breaking? If its negligible why are you using the software in the first place. The chances are it will have a major impact. Of course just because you change the hardware/software platform doesn't mean the risks go away. They are just different. Whilst it isn't at all common you do see posts on CCTALK and on the VCF Forums where someone has had an old system based on say an Apple II and the machine has failed with no backups... So whilst you shouldn't tamper for tamperings sake, its also shortsighted not to plan for the odd disruption. Dave
On Sat, Jun 24, 2017 at 9:37 PM Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
This popped up on a screen on SourceForge just now:
Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language
With billions of lines of COBOL in use, this business language powers a large percentage of every ATM, government, and many other business transactions. Many businesses are looking for new ways to utilize decades of solid business logic without having to replace a mission critical application.
Attend this TechBytes series sponsored by Micro Focus and presented by SourceForge to learn how organizations around the world are utilizing existing .NET and Java development teams to integrate and modernize COBOL applications. Attendees will learn:
* What tools can be used to ‘free’ business logic from legacy code * Exposing COBOL processes as REST base services * Using COBOL as a .NET or JVM language
Don’t wait – register now for these TechBytes to get started.
About the Presenter: Michael Bleistein, Principal Architect, at Micro Focus, is a 25-year veteran when it comes to COBOL. Currently he specializes in modernization through .NET, Java, and SOA using Visual COBOL, helping customers understand Micro Focus solutions and how they can be used to combat their business problems.
-- Normal Person: Hey, it seems that you know a lot. Geek: To be honest, it's due to all the surfing I do. Normal Person: So you go surfing? Normal Person: But I don't think that has anything to do with knowing a lot... Geek: I think that's wrong on a fundamental level. Normal Person: Huh? Huh? What?
-- Dave McGuire, AK4HZ New Kensington, PA
Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language
I think Digital was doing this 30+ years ago, if you replace "JVM" with "VAX standard calling procedures" :-) http://odl.sysworks.biz/disk$cddoc04jan11/decw$book/aa-h632e-te.p14.decw$boo... "VAX standard calling procedures [...] allow VAX COBOL programs to call (and be called by) other programs written in VAX COBOL, other VAX languages (such as BASIC, FORTRAN, and MACRO), system services, common run-time library subroutines, and screens produced by VAX Forms handling products." On Sat, Jun 24, 2017 at 6:36 PM, Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
This popped up on a screen on SourceForge just now:
Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language
With billions of lines of COBOL in use, this business language powers a large percentage of every ATM, government, and many other business transactions. Many businesses are looking for new ways to utilize decades of solid business logic without having to replace a mission critical application.
Attend this TechBytes series sponsored by Micro Focus and presented by SourceForge to learn how organizations around the world are utilizing existing .NET and Java development teams to integrate and modernize COBOL applications. Attendees will learn:
* What tools can be used to ‘free’ business logic from legacy code * Exposing COBOL processes as REST base services * Using COBOL as a .NET or JVM language
Don’t wait – register now for these TechBytes to get started.
About the Presenter: Michael Bleistein, Principal Architect, at Micro Focus, is a 25-year veteran when it comes to COBOL. Currently he specializes in modernization through .NET, Java, and SOA using Visual COBOL, helping customers understand Micro Focus solutions and how they can be used to combat their business problems.
Very true. I was doing this on an 11/780 in college back in '84. On Fri, Sep 15, 2017 at 10:59 AM Joseph S. Barrera III via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language
I think Digital was doing this 30+ years ago, if you replace "JVM" with "VAX standard calling procedures" :-)
http://odl.sysworks.biz/disk$cddoc04jan11/decw$book/aa-h632e-te.p14.decw$boo...
"VAX standard calling procedures [...] allow VAX COBOL programs to call (and be called by) other programs written in VAX COBOL, other VAX languages (such as BASIC, FORTRAN, and MACRO), system services, common run-time library subroutines, and screens produced by VAX Forms handling products."
On Sat, Jun 24, 2017 at 6:36 PM, Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
This popped up on a screen on SourceForge just now:
Give Legacy Code New Life With Modern COBOL AppDev: Using COBOL as a JVM language
With billions of lines of COBOL in use, this business language powers a large percentage of every ATM, government, and many other business transactions. Many businesses are looking for new ways to utilize decades of solid business logic without having to replace a mission critical application.
Attend this TechBytes series sponsored by Micro Focus and presented by SourceForge to learn how organizations around the world are utilizing existing .NET and Java development teams to integrate and modernize COBOL applications. Attendees will learn:
* What tools can be used to ‘free’ business logic from legacy code * Exposing COBOL processes as REST base services * Using COBOL as a .NET or JVM language
Don’t wait – register now for these TechBytes to get started.
About the Presenter: Michael Bleistein, Principal Architect, at Micro Focus, is a 25-year veteran when it comes to COBOL. Currently he specializes in modernization through .NET, Java, and SOA using Visual COBOL, helping customers understand Micro Focus solutions and how they can be used to combat their business problems.
participants (10)
-
Bob Applegate -
Dave G4UGM -
Dave McGuire -
Dean Notarnicola -
Douglas Crawford -
Evan Koblentz -
Joseph Oprysko -
Joseph S. Barrera III -
VAXman＠tmesis.org -
William Sudbrink