VSI OpenVMS Forum

Greetings!

Section 1.1 of the VSI CMS manual suggests that we use "SDL."

Our I64 SDL is from Freeware v80 v2.3-1.

Might a native x86 SDL somehow be available? Any plans? Keeping an I64 system as part of a cross-build environment is severely frowned upon.

Thank you kindly for any thoughts or ideas!

On a tangent (that lead us to look for something more modern) is that v2.3-1 SDL will not build the I64/x86
sys$sysroot:[syshlp.examples.cms]cms$routines.sdl

$ sdl/lang=pascal sys$sysroot:[syshlp.examples.cms]cms$routines.sdl
Error on line 4 column 12: Found reserved-word "constant" when expecting
one of { "module" end-of-file }

But I don't think that's fodder for a problem report...
\john

John! Send me mail sometime!

Yes, we plan in putting up public versions of things like SDL and BLISS. I'm close to having a native BLISS kit ready. We're actively working on building SDL now. It is mostly in C++ and needed the native C++ compiler.

John

We, too, are interested in x86 SDL whenever that becomes a "thing". We have used it for quite some time to create cross-language include files for our large project (C and Fortran), starting on Alpha and then on IA64, and now would be awesome for our x86 porting efforts. -Marc

John wrote . . .

> On a tangent (that lead us to look for something more modern) is that v2.3-1 SDL will not build the I64/x86
> sys$sysroot:[syshlp.examples.cms]cms$routines.sdl

> $ sdl/lang=pascal sys$sysroot:[syshlp.examples.cms]cms$routines.sdl
> Error on line 4 column 12: Found reserved-word "constant" when expecting
> one of { "module" end-of-file }

That's not an SDL problem; it's a problem with the provided copy of CMS$ROUTINES.SDL.

That's been fixed in a not-yet-released version of CMS. That CMS kit provides a correct copy
of CMS$ROUTINES.SDL and also provides a language-specific copy of CMS$ROUTINES.

-- Rob

We haven't forgotten about SDL. It is important for us also. SDL is written in C++ and seems to be a mix of good and bad C++ code (insert joke about EVERY C++ program here). It has been a good test of the compiler and RTL. We recently found/fixed a bug in the LIBCXXABI RTL routine dealing with exception handling (a TRY around a call to CLI$PRESENT that signalled an error tripped it up).

John