topic Re: Languages and SDLN in Operating System - OpenVMS

Languages and SDLN

Troodon — Sat, 07 Apr 2007 16:12:27 GMT

I wonder if it'd really be all that difficult to include SDLN parser code into the various compilers so that include directives referencing STARLET or LIB pulled their definitions from a language independent reference which tracked the executive.

Right now, if you upgrade OpenVMS without reinstalling your language-specific STARLET definitions, you risk an out-of-date object.

Given the extraordinary performance of OpenVMS compilers (I remember RSX compiles and TKBs that took all day), I don't think the added burden would be significant.

Re: Languages and SDLN

Hein van den Heuvel — Sat, 07 Apr 2007 18:33:40 GMT

>> Languages and SDLN
What is SDLN?

OpenVMS had 2 language independend data languages that I know:

CDDL = The CDD Language

SDL = Structure Datadefintion Language?
http://h71000.www7.hp.com/freeware/freeware60/sdl/freeware_readme.txt

VMS Enigneering used SDL for its work.

Customers were supposed to usec CDDL in a VIA environment.

>> I wonder if it'd really be all that difficult to include SDLN parser code into the various compilers so that include directives referencing STARLET or LIB pulled their definitions from a language independent reference which tracked the executive.

The compiler folks foudn they often needed little tweaks to make it really work. The bulk translation worked just fine, but some details needed polishing.

Also, while the virtues of resusable code where touted, it wasn't fully followed. The fiefdoms did not help: VMS, RTL, CTL, TLE
I thinkk the latter two stood for
Commercial Tools and Languages (Cobol, Basic...)
and
Technical Language Environment (Fortran, Pascal,...)

>> Right now, if you upgrade OpenVMS without reinstalling your language-specific STARLET definitions, you risk an out-of-date object.

Following the various release notes / read me's and such seems to be enough to control the problem.

With the level of changes to be expected over the next few year it's clearly a non-problem IMHO.

>> I remember RSX compiles and TKBs that took all day

One of the RSX guys (McCarthy? Todd Schoeller?) had a sign on his (then ZK) cubicle wall along the lines of "The Taskbuilber is extra slow on Thursdays"

I just loved ODL files. It was so easy to be the one-eyed king in the land of blind!

Thanks for bringing back the memories ;-)

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

Re: Languages and SDLN

Troodon — Sun, 08 Apr 2007 14:41:11 GMT

Remember this from RSX days?

"> SET /COFFEEBREAK ! Go have some coffee"

"> SET /NOCOFFEEBREAK ! Time to get back to work"

Re: Languages and SDLN

Hein van den Heuvel — Sun, 08 Apr 2007 14:43:51 GMT

Oh yeah, right after you entered the clock frequency, as 50 or 60 hz.
50 --> tea
60 --> coffee

:-)

Hein.

Re: Languages and SDLN

Hoff — Sun, 08 Apr 2007 16:43:57 GMT

There's potentially more to this than the SDL/NOPARSE processing, witness the LIBEXT stuff that was originally used by C. (Both SDL and LIBEXT are on the Freeware. LIBEXT provided part of the processing involved here.)

SDL and SDL/NOPARSE can both convert the SDI intermediate files into language-specific files. SDL can further convert source files into either SDI files or language-specific files. The intermediate files are what are used to populate STARLETSD.

The compilers then process the language-specific include files. Typically using standard means. (As Hein mentions, the other approach here is via the Oracle CDD Respository mechanisms. Many of the compilers included this, but AFAIK CDD was never used to generate the system symbols.)

So you're looking to go from the SDI files or the STARLETSD library or equivalent, into whatever the compiler expects to receive.

There's no callable SDL version, so that's a bit of coding work. Basically, this involves inserting the SDI processing into the compiler file input processing path, and having the SDI feed the language-specific source code back.

Sure. It's possible.

Assuming the request is scheduled and then -- at the earliest -- this is probably a couple of years out, with details depending on the release cycles for the particular compilers involved. That's a guess, and it places this out around V8.4, and possibly later, based on the OpenVMS roadmap and on what I've seen of typical compiler release cycles.

Lob a formal request at HP, if you want to see it. In the meantime, I'd reinstall the compilers after an upgrade, assuming I needed the updated or the new definitions.

Stephen Hoffman
HoffmanLabs

--

If I were feeling "sneaky", I'd look to either flag the STARLETSD changes after the upgrade and trigger a request for invocation of the compiler installations, or I'd look to drop off some sort of stub procedure that would extract and update the definitions when STARLETSD was changed. This avoids having to modify all the compilers.

Re: Languages and SDLN

Troodon — Sun, 08 Apr 2007 16:51:56 GMT

Since system definitions have been known to change between versions (like bugs in RMS, for example), it seems to me the OpenVMS folks ought to at the very least generate a notice that BASIC$STARLET or the C header files might need to be rebuilt.