And the other examples under Special Uses... like the GRIB data, I have toyed with reading weather model data and I just write Go code that reads the files and does conversions as necessary on x86 without having to involve a mainframe. (Although that said, I have an odd fascination with mainframes despite never using them professionally, and maintain a system using the Hercules emulator and the MVS 3.8 operating system, which was the last freely-available version of what became today's z/OS.)
Regardless, I wasn't able to find in the WP entry adequate support of your assertion. (Oddly, the "[..]" were in the original WP text):
> As IBM is the only remaining provider of hardware (and only in their mainframes) using their non-standard floating-point format, no popular file format requires it; Except the FDA requires the SAS file format and "All floating-point numbers in the file are stored using the IBM mainframe representation. [..] Most platforms use the IEEE representation for floating-point numbers. [..] To assist you in reading and/or writing transport files, we are providing routines to convert from IEEE representation (either big endian or little endian) to transport representation and back again." Code for IBM's format is also available under LGPLv2.1
There's only a regulation for a file format (and a single, isolated one at that), not regulation of using/processing, and format conversion utilities are available, rendering it irrelevant.
- IBM legacy hexadecimal floating point you mentioned
- IEEE 754 binary floating point
- IEEE 754 decimal floating point (they were a first implementation of it)
So perhaps you were downvoted because on the mainframe, you don't have to use the legacy format at all.
[1]https://en.m.wikipedia.org/wiki/IBM_hexadecimal_floating_poi...