Live data from Hacker News

IBM COBOL for Linux on x86

www-01.ibm.com

91–100 of 112 posts

Re: IBM COBOL for Linux on x86

#91
post #82

Earlier quoted context omitted.

Except this bit: Please note that in accordance with the license agreement between VMS Software Inc. and HPE, VMS Software Inc. are not able to distribute VAX licenses. Since I've got actual Vaxen it doesn't help.

So back to the original question, what about macro32, the VAX emulator built into VMS on alpha and itanium? Where you have the source, you can build a native binary. Where you lack it, perhaps the emulation is sufficiently robust. https://en.m.wikipedia.org/wiki/VAX_MACRO

Running VAX binaries per-se isn't a problem, you can run them on SIMH quite reasonably[1]. The challenge is running VAX binaries that use authorization keys (PAKs). Unless you have the key (or forge one) the binary won't run.

I have keys for the VAX assembler (and Fortran, BASIC, and Ada) so running source, and building applications that DECUS distributed back in the day, isn't a problem for me.

What annoyed me was that VMS/VAX support was discontinued by the hobbyiest program. When it was announced and I asked for details they suggested I contact licensing. Which I did and suggested I could buy new licenses for VAX machines for $5,000 good for up to 25 users. For a machine that was headed for the skip. So someone, somewhere, and I'm thinking US GOV here, "can't" upgrade their VAX hardware and HP has them over a barrel so they continue to hold those licenses as saleable products. But that is purely speculation on my part.

[1] In fact, for the earlier models (anything before the VAX 4000 series), they run faster on a modern PC under simh than they do on the original hardware.

Re: IBM COBOL for Linux on x86

#92
post #73

Earlier quoted context omitted.

> Everyone with unmaintainable COBOL has long since migrated to really bad Java code instead. Sadly this is entirely untrue. What's happening in practice is they're still running COBOL and they're paying some woefully underpaid and underappreciated developers to write PHP ("Zend Core") for System-i. This allows companies to run web applications on these aging systems.

Plenty of jobs for remote COBOL devs in the 120-160k range, still. I wouldn’t call “live-where-you-want” at 150k/year woefully underpaid. That affords a great living in a lot of America. ‘Specially if you take two.

I wasn't talking about remote COBOL devs.

Pay for PHP devs, even on these systems is generally lower and a lot of the work is in Europe where developer pay is half.

Re: IBM COBOL for Linux on x86

#93

Earlier quoted context omitted.

I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. I would be a bit surprised if they open-sourced it; OpenJ9 is open-sourced, but the COBOL compiler for Z is one of those rare compilers that is still being sold to paying customers.

Did I work with you!? I also worked on the COBOL backend for TR. And yeah, I'd also be HIGHLY surprised if it ever got open-sourced.

We must have just missed each other. I started in January 2014.

Re: IBM COBOL for Linux on x86

#94

Earlier quoted context omitted.

I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. I would be a bit surprised if they open-sourced it; OpenJ9 is open-sourced, but the COBOL compiler for Z is one of those rare compilers that is still being sold to paying customers.

> I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. Does it have anything in common with XL C? Does it use W code as an intermediate language? And what language is it written in? (PL/X? PL.8? C/C++?)

Assuming nothing's changed since I left, the front-end is taken from the old COBOL compiler, and is written in PL/X. It emits WCode for the backend, which is written in C++.

XL C is a separate codebase, with very little shared code IIRC.

Re: IBM COBOL for Linux on x86

#96
post #72

Earlier quoted context omitted.

> I can assure you that "Quickbook Payroll" would not be able to handle this on a similarly resourced x86 machine. Not even close. Why? I've been into x86 databases since the Windows NT days and 5000 doesn't seem an impressive number to me.

The OP's comment was conditional: on a similarly resourced x86 machine . Windows, let alone Quickbooks is not going to run very well on a machine with just 512MB of RAM.

I know today Windows is not going to run very well. But why? What are they doing to consume so much resources? Today Windows and Office do exactly same job they did 20 years ago (I even used 3-rd party bells&whistles to make Windows 2000 and 98 look at least as "cool" as it does today as I was a kid and enjoyed that).

Also, I can imagine using an Excel spreadsheet with some sheets, thousands of records on each one (Excel 97 max rows was 65536) + formulae and macros even 20 years ago so, again, 5000 doesn't seem an impressive.

I can't remember how much would SQLServer with a database take those days though so perhaps a 4GB HDD might indeed be insufficient.

Re: IBM COBOL for Linux on x86

#97
post #9

I'm just imagining the level of jaw dropping and brain exploding that would have gone on had that same headline been published in 1998. Obviously at this point almost three decades into the internet era no one really cares. We all know that "somewhere" old COBOL code is running, but in practice the companies managing the bulk of data for society didn't even exist before Y2K. Everyone with unmaintainable COBOL has lon…

Sounds like another opportunity to extract millions of dollars from hard-headed customers that are 20 years behind

Re: IBM COBOL for Linux on x86

#98
post #82

Earlier quoted context omitted.

Except this bit: Please note that in accordance with the license agreement between VMS Software Inc. and HPE, VMS Software Inc. are not able to distribute VAX licenses. Since I've got actual Vaxen it doesn't help.

So back to the original question, what about macro32, the VAX emulator built into VMS on alpha and itanium? Where you have the source, you can build a native binary. Where you lack it, perhaps the emulation is sufficiently robust. https://en.m.wikipedia.org/wiki/VAX_MACRO

There's two separate programs under VMS:

MACRO32 is a VAX assembly compiler - given a VAX assembly source listing, it can turn it into object code for Alpha, IA64 or x86. In some cases, the code will need special annotations.

There's also VEST on Alpha which does translation of user-mode VAX binaries into Alpha binaries. I think that was an optional product. Many products (including things unrelated to the operating system) don't fall into the user-mode category due to the use of the "Privileged Image" mechanism of VMS.

Nitpick: Neither are emulators in the strictest sense of the term.

Re: IBM COBOL for Linux on x86

#99
post #72

Earlier quoted context omitted.

> I can assure you that "Quickbook Payroll" would not be able to handle this on a similarly resourced x86 machine. Not even close. Why? I've been into x86 databases since the Windows NT days and 5000 doesn't seem an impressive number to me.

The OP's comment was conditional: on a similarly resourced x86 machine . Windows, let alone Quickbooks is not going to run very well on a machine with just 512MB of RAM.

similarly priced machines would run circles around it?

Re: IBM COBOL for Linux on x86

#100
I had to chuckle at this, one of the bulleted features:

"Offers an extended source format that lets source text vary in length up to 252 bytes per line. COBOL for Linux on x86 supports fixed source format and extended source format. Fixed source format consists of text that varies in length up to a 72 bytes per line."

Yeah I'm never going to be in the same room as COBOL code

Post reply on HN