[Info-vax] Free Pascal for VMS ?

[Stephen Hoffman]

On 2018-05-15 16:28:25 +0000, seasoned_geek said:

May I suggest asking questions and learning?  Whether that's about IP 
networking, about LLVM, about open source in general, or particularly 
about what VSI is working on with the OpenVMS port?  About current 
x86-64 processor reliability and availability features and 
capabilities, too.  That'll likely involve discussions of Intel Xeon 
and Run Sure as the port progresses.

Somewhat unfortunately for marketing and learning, VSI is not known for 
their marketing and communications.  Outside of technical update days 
and bootcamp, that tends to be lacking.   Which means some rummaging 
around here for previous postings and discussions, and acquiring 
materials from VSI presentations, and some time working through the 
references in the VSI roadmap.   Or attending the VSI presentations, 
where the budget and time for that is available.  Or asking questions.


> On Tuesday, May 15, 2018 at 11:16:02 AM UTC-5, Stephen Hoffman wrote:
> 
>> For now, having and selling OpenVMS on x86-64 is the only reasobable> 
>> path forward for VSI OpenVMS on new hardware.
>> 
> 
> But we aren't gointo have OpenVMS on x86-64. We are going to have a 
> *nix that sucks and ___NOBODY___ has officially answered the question 
> as to what the target market is for this port and how that target will 
> be served.

That would be quite incorrect.  The port will not produce a Unix system.

I doubt you're going to get an offical answer from VSI for the target 
markets and related details, beyond general comments in existing 
presentations and the very obvious services and support of the existing 
installed base, and particularly with a path to server hardware past 
the end of the HPE Integrity Itanium server roadmap.

> Following a negative zero down the path of just another *nix which 
> sucks completely abandons the existing market which is funding 
> everything.

That would be quite incorrect.  Probably the biggest risk to the future 
of OpenVMS at VSI is that they will spend too much time and effort 
catering to the installed base and compatibility.  That being about the 
opposite to what you're concerned about.

> Everybody has heard all of this talk about Go and Rust and script 
> language of the week and jumping to LLVM based compilers pretty much 
> ensuring the bulk of the existing code base won't compile because *nix 
> couldn't handle all of the VMS extensions which are in use.

That too would be quite incorrect.   The existing compilers are using 
the old front-ends, which means apps — outside of architecture-specific 
details, and that caveat is the same as the previous two OpenVMS ports 
— will compile and work the same as always. Discussions of Rust and Go 
are part of moving OpenVMS and existing apps forward.  For those folks 
with apps tied the pre-millenial era and apps, new tools will be of 
little interest.  For those folks that are interested in moving 
existing apps forward and for folks that are or become interested in 
adopting newer tools and approaches, access to a ported LLVM and cmake 
and git and more current compilers and tools will help keep OpenVMS 
from being tossed aside, and — eventually, after a whole lot of work — 
make it interesting to wholly new apps and projects.






-- 
Pure Personal Opinion | HoffmanLabs LLC