More lang$xxx_ROUTINES files

[Mark Katz]

Over the last few months I read a ton of release notes and other docs in preparation for someday moving our systems into the modern era. I *think* I remember somewher in that reading that VMS and/or other products with callable features were contributing more SDL files so that more lang$xxx_ROUTINES files could be generated.

Was I hallucinating? Wishful thinking?

Specifically, I am thinking about DECset at the moment. I could use a PASCAL$SCA_ROUTINES.PAS with more stuff in it than SCA$QUERY_CALLABLE.PAS.

I currently have a home-grown file with much of callable CMS in it (it's probably 23+ years old and hasn't been updated in 15 years). I'd convert to a sanctioned version if one could be had.

Any clues?

Thanks, Mark

[John Gillings]

Mark,

I'm not sure I understand what you're asking. If you've got old, debugged, stable code, working with some set of declarations, why would you want to mess with it?

SDL is useful for defining interfaces in a (more or less) language independent form, and then generating language specific definitions, but the chances of an SDL generated set of routine declarations working with your existing code is slim!

There are many ways to skin the routine interface cat, so it's highly likely you've chosen different ways to define various things than SDL will generate.

Sanctioned or not, I'd recommend you avoid trying to convert from existing, debugged, working definitions to anything new. Changing will involve rechecking every call, and possibly changing data declarations. In extreme case you may even need to modify logic to deal with a structurally equivalent, but functionally divergent data structure.

Very simple case... is a particular argument defined as a structure passed by reference, or as a pointer to a structure passed by immediate value? Exactly the same thing to the run time instruction stream, but potentially expressed quite differently in source code.

What would changing things buy you? If the code hasn't been changed in 15 years, what are you achieving except an opportunity to introduce new bugs?

Of course, if you're developing new code, and system provided definitions are available, it's a good idea to use them.

That said, I occasionally find the system provided declarations try to be too general. In such cases I building my own declarations - particularly in Pascal where there are things like [UNSAFE] are used to define routines that deal with generic data structures. The disadvantage is you lose some Pascal compilation checks, which you get back by redefining routines with specific data types.

FWIW, from an IA64 system which does NOT have Pascal installed, the text library STARLETPAS.TLB contains modules:

PASCAL$ACLEDIT_ROUTINES
PASCAL$CLI_ROUTINES
PASCAL$CMA_ROUTINES
PASCAL$CONV_ROUTINES
PASCAL$CVT_ROUTINES
PASCAL$DCX_ROUTINES
PASCAL$DTK_ROUTINES
PASCAL$D_FLOAT
PASCAL$EDT_ROUTINES
PASCAL$FDL_ROUTINES
PASCAL$G_FLOAT
PASCAL$LBR_ROUTINES
PASCAL$LIB_ROUTINES
PASCAL$MAIL_ROUTINES
PASCAL$MTH_ROUTINES
PASCAL$NCS_ROUTINES
PASCAL$OTS_ROUTINES
PASCAL$PPL_ROUTINES
PASCAL$PSM_ROUTINES
PASCAL$SMB_ROUTINES
PASCAL$SMG_ROUTINES
PASCAL$SOR_ROUTINES
PASCAL$STR_ROUTINES
PASCAL$TBK_ROUTINES
PASCAL$TPU_ROUTINES
PASSTR$$FILES
PASSTR$$FILE_LIST
STARLET

[Hoff · Accepted solution]

I did encourage the DECset CMS folks to produce language definitions for various languages, and pointed to the usefulness of the SDL mechanisms in this context.

The CMS V4.0 release notes describe how to use the provided SDL file to create language-specific definitions. These are not tied into the Pascal library in any fashion, but you can obtain Pascal-language definitions from SDL.

As for the definitions for the various other DECset pieces, I don't know if the definitions for those were provided and haven't gone looking for same.

And changing working source code? As John asks, "Why?" That's just an invitation for a visit from Mr Murphy. And if you're going to consider changing your existing source code, figure out where you want to end up, whether that's use of newer language definitions and features, or toward better OpenVMS or cross-platform portability, toward lower code maintenance costs, or toward whatever other target you might have.

[Mark Katz]

John and Hoff -

Thanks for your replies.

>>I'm not sure I understand what you're asking. If you've got old, debugged, stable code, working with some set of declarations, why would you want to mess with it?

Well, actually I was adding something new to the old code that needs callable SCA (Source Code Analyzer) for SCA operations other than queries (for which definitions are provided).
Since I have never used callable SCA before, I don't have a homegrown set of definitions and would use a supplied set if they existed.

As for my existing CMS definitions, my primary concern *is* future maintenance. I am just returning to work here as a contractor after about 4 years of retirement and am trying to get the systems here caught up to more recent, supported versions of *everything*. In a few more years I will probably retire for good and someone else will have to fix anything that breaks from a VMS or layered product upgrade. I am doing as much as I can now to reduce the need for future changes to our own code. I won't go into detail about all the things I am doing to accomplish that, but replacing homegrown stuff with vendor-supplied stuff is one aspect that is at least being evaluated.

I will follow your pointer to the CMS files, Hoff, and at least generate the Pascal definitions from them to see what they look like. If I do nothing else, I will use them as a guide to update my own definitions with the new calls from CMS 4.x and any added parameters to existing calls since mine were last updated.

Thanks again,
Mark