[talk] possible meeting topic: FreeBSD desktop stuff with a side of DJ-BSD redux

[jpb]

On Tue, 4 Mar 2025 14:04:37 -0500
"James K. Lowden" <jklowden at schemamania.org> wrote:

> On Mon, 3 Mar 2025 17:36:11 -0500
> Charlie Li <vishwin at freebsd.org> wrote:
> 
> > is interest. There is now a FreeBSD Laptop Desktop Working Group
> > (LDWG) [0] that meets monthly (on Jitsi), with some Foundation
> > involvement,   
> 
> Can I talk to you about gcc?  FSVO $talk and  $you? 
> 
> As perhaps some here assembled may know, I've been working on adding
> COBOL to gcc for the last, oh, 4 years.  The idea was adopted by the
> GCC steering committee a couple years back, and now we're in the
> midst of having our patches applied upstream, hopefully for inclusion
> in gcc-15, due for release next year.  Yes, we're already talking
> about mid-2026.  
> 
> For expediency, we've been developing in Ubuntu.  It's ~everywhere;
> for example I use Ubuntu Multipass on macOS to install Linux virtual
> machines on my laptop.  I don't guess LDWG cares about that kind of
> environment, but it's one reason (of many) that Linux is where we
> started.  
> 
> I was contacted upon a time about patches for FreeBSD, but that
> conversation petered out.  I would still like to make sure the
> compiler and runtime library build and install happily on FreeBSD
> (well, *BSD). I'm happy to work with anyone who shares that goal.  
> 
> Some may ask: Why?  Why COBOL?  If I may be permitted....
> 
> The answer is simply this: 100 billlion lines or more.  There is a lot
> of COBOL out there you've never seen.  There is a (measured) 95%
> probability your last ATM transaction went through a COBOL application
> written in the 1980s, if not earlier.  The books-and-records
> applications written for the mainframe Back In The Day still run,
> because computing interest hasn't changed.  Actually: *can't* change,
> because no one wants their interest calculated differently.  
> 
> Can't change is why those applications still run on the mainframe,
> using emulation provided by IBM for machines they haven't manufactured
> in decades.  Rest assured, it works.  It has to. it is also Not
> Cheap.  
> 
> Mayhap you, dear reader, work for such an organization.  If all goes
> according to plan, there will be two open-source compilers for COBOL:
> GnuCOBOL, which converts COBOL to C, and uses gcc to compile that, and
> gcc-cobol, which is just gcc.  That means two ways to "lift and
> shift": compile the unaltered COBOL source code for any gcc target,
> and run it without paying IBM's totally reasonable mainframe licensing
> fees.  
> 
> [pitch] 
> I can help, but I don't have to.  The code is yours, both COBOL
> and compiler.  So is the choice.  Spend as much as you want.  
> [end pitch]
> 
> We'll be working on portability issues this year, and on expanding the
> supported architectures beyond x86_64 and aarch64.  (gcc-cobol
> requires 128-bit integer support.)   I look forward to making FreeBSD
> part of that story.  
> 
> --jkl
> 

Interesting!  My first computer job (1980) was on a Univac 1100
series mainframe using a COBOL application.  In fact my Mother was a
COBOL programmer for a multinational also on a Univac 1100.  She spent
time in Iran working for a bank.

I once applied to the IRS for a position using COBOL.  They didn't hire
me because I did not know how to program getting data off 9-track tape drives.

Oh well.

Every couple of years you hear about the need for COBOL programmers
because they are retiring or dying :-(  Sure to be good money for
people who still know that stuff.   My COBOL knowledge now is almost
gone.

IDENTIFICATION DIVISION
...

ENVIRONMENT DIVISION
...

DATA DIVISION
...

PROCEDURE DIVISION
...

That's about it :-(

Jim B.