Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
There are no good choices here.
Your available choices are to...
...convince Synergex to port DIBOL/DBL, or convince somebody to port an
existing DIBOL compiler or to write a new DIBOL compiler for you, or
write one yourself. For folks writing a new DIBOL compiler, the back
end will prolly be LLVM, that for either native code or (using
emscripten) to WebAssembly for browser-based operations, or otherwise.
And no, I'm not aware of an open-source DIBOL compiler.
...translate the existing DIBOL code into C or into some other
language, using the available d2c or dibol2c or other tooling, or
home-grown tooling. That'll prolly then best use a C refactoring tool
such as Xcode or a Visual Studio Code plug-in, or potentially using
manual translations. That there are vendors with automated translation
services available would not surprise. I looked around for tools that
translated into C, there may well be other language targets for other
tools. Migration Specialties was offering CBL, though that targets DEC
VAX DIBOL and apparently doesn't target DIBOL/DBL.
...port the DIBOL apps to another platform with a supported DIBOL
compiler. This when continued use of the current platform and current
compiler becomes untenable. This other platform may well co-exist as a
guest with OpenVMS x86-64 in a virtual machine, too. Either long-term,
or for the duration of the platform migration.
...If the project is just starting and there is not yet an extensive
installed base of DIBOL code, use a different programming language with
the required support. VSI expects to have BASIC, Fortran, and COBOL
available for OpenVMS x86-64, and there are other common languages and
other DSLs available for various requirements.
...Leave (for another job, retirement, etc) before this DIBOL situation
blows up; defer, delay, deny, etc.
Absent a sufficiently large number of zeros included with the request,
VSI won't be writing the compiler for you. They've far too much work
already. VSI also prolly doesn't have the VAX DIBOL compiler source
code as AFAIK all that went to the predecessor of Syngergex a
Complicating the cost calculations, if Synergex isn't porting
DIBOL/DBL, that can be inferred to believe the market here is small,
and which usually then means a custom compiler will be expensive, and
for a product at risk of being undercut by some future port by
Synergex. That'll be an expensive compiler, for the work and for the
It's also some time before this OpenVMS x86-64 discussion is even
particularly relevant, as the second native-tooling beta V9.1 hasn't
arrived yet (early 2021 was predicted), and the V9.2 production release
will prolly be a year or three after that. Few third-party vendors are
likely to commit to porting until after V9.1 is available and tested,
and variously of those vendors may not release statements until much
closer to or even after V9.2 is released; until they know more about
the target and about the platform and the market.
If the priority for this whole porting discussion is due to concerns
about existing and old hardware, maybe replace that with less-old
hardware and/or with emulation as an interim step in whatever the
long-term plans here might be.
The referenced dibol2c and d2c tools are open-source. YMMV, etc.
There are various LLVM examples around, and open-source projects using
LLVM, if you're inclined to write your own front-end and DIBOL parser.
*Visions of a GoFundMe being run for and by the few sites still using DIBOL*
Pure Personal Opinion | HoffmanLabs LLC