SYS$SETEXV (Fortran90/Fortran77)

[HDS]

Hello.

I am working with the need for a condition handler and am looking for an example in Fortran-90 or Fortran-77 that uses the SYS$SETEXV system service.

Can someone provide a simple example of its use? Nothing complex...no specific type of handler; any one will do.

I realize that this is a very ambiguous generic question to post, but it truly is just a "playing around" sort of scenario at the moment. I am just looking for an example off of which I can expand.

Your assistance is greatly appreciated. I thank you in advance.

-Howard-

[Mike Kier]

Are you sure you want to be playing with the last chance exception vectors?

Or did you just want a condition handler? If so, you'd probably want to use LIB$ESTABLISH and there are lots of examples around. A quick Google will find several Fortran examples.

[Hoff]

Short answer: use lib$establish and (more often than not) lib$establish(lib$sig_to_ret) or analogous.

The HP OpenVMS Fortran documentation contains a wealth of information, and certainly contains information on using condition handling on OpenVMS. For instance:

http://h71000.www7.hp.com/doc/82final/6443/6443pro_040.html#ch_chf

is a link to the chapter on this topic, and the chapter specific to Fortran condition handling.

Stay away from sys$setexv; that's not what you want.

[HDS]

Hello.

I did see the LIB$ESTABLISH examples on the web. But, if I am correct, using that service within a subroutine establishes the condition handler only for that subroutine....and would not apply to the caller [whoever that may be]. In short, I was looking for a way to code a common subroutine to establish a specific condition handler for any image, throughout the entire image from its main down thru all of its functions and called subroutines. I am under the impression (maybe mistaken) that this could be done by using the SYS$SETEXV to define the handler "globally" and can thus be passed upward to the caller and then carried downward as the image runs. (I hope that makes sense...I am having difficulty expressing what I am seeking.)

This approach is desired mainly because of the coding standards that we currently use; the use of a common subroutine to do the task instead of having users explicitly assign using LIB$ESTABLISH. We could then, possibly, call that common $SETEXV routine (whatever we opt to cal it) from the common initialization routine used by all..maybe. Dunno for sure, this is still in the "playing around" stage of development...it is just an idea at the moment.

Hence, my request for an example of the use of $SETEXV within fortran-77 or fortran-90 to see if it does what I think...maybe, maybe not. For now, this is just an idea in its youth stage.

Thank you.

-Howard-

[John Gillings]

Howard,

Exception vectors are only necessary for writing debuggers, performance monitors or where you need different handlers for inner and outer modes. This isn't a FORTRAN type of thing (nothing against FORTRAN, but this area is well outside it's strengths). There really aren't any "simple examples" for which is makes sense to use $SETEXV.

The correct tool for the job of handling exceptions in user mode code is LIB$ESTABLISH. Depending on exactly how your condition handler is used, in FORTRAN you may need to be careful about reentrancy and static data. It may be necessary to declare local variables as having attribute AUTOMATIC, or specify OPTIONS /RECURSIVE for the entire module. Any shared variables should also be given attribute VOLATILE.

[Hoff · Accepted solution]

Using lib$establish is the way you want to go.

If you want to go for a wrapper at the main level, then either explicitly implement what amounts to a dummy main with the lib$establish and then call the "old" main routine, or implement and use the lib$initialize psect.

Or update your standards to localize the signal handling. Alter the coding standards to use standard Fortran constructs, or to use lib$establish or such. Possibly toss some Perl or php code at the Fortran source pool here, if your source code is sufficiently cookie-cutter to automate the replacement process.

I'd stay away from sys$setexv here, regardless. Per HP: "The software exception vectors are intended primarily for performance monitors and debuggers." I don't tend to prefer to use the lib$initialize psect, though I'd use that in preference to using sys$setexv here.

(Or -- depending on what the goal(s) here might be -- I'd use process dumps or integrated debugging.)

Depending on what you are up to, Fortran itself has some exception processing, either explicitly or via DFOR$GET_FPE, DFOR$SET_FPE or such.

And exceptions can be a performance problem on OpenVMS I64; they're often very slow.

[John Gillings]

Howard,
(clash with Hoff!).

A condition handler established with LIB$ESTABLISH applies to the routine that declares it, and all routines below it.

To create a "global" handler, establish it in the main routine. It's not really modular to impose a handler on routines above you. Also realise that handlers declared at intervening routines will take precedence. I'm not sure if FORTRAN declares a default handler. If it does the condition handling facility may never see your $SETEXV routine. You may also interfere with debuggers & performance monitors if you declare exception vectors which override theirs.

Your goal of the "common initialisation" routine can be achieved using a "call through" routine. Something like:

routine call_with_handler(handler,target_routine,args,...)
lib$establish(handler)
target_routine(args,...)
return

(details of how you deal with generic argument lists left as an excercise)

[HDS]

Hello.

I am seeing a trend in the responses. That is that I seem to be asking about the use of a service that is truly not recommended....maybe one of those "if I have to ask about its use, it is not likely what I want to use." Interesting.

I will take this information under advisement and see if I can get the LIB$ESTABLISH to do what I want...maybe I am misusing it...I just may try different attributes as suggested. (Thank you for that idea.)

As it seems at the moment, we have a common callable subroutine used as an initialization routine in most of our main routines. A new subroutine call was added to that standard INI routine that makes use of the LIB$ESTABLISH. However, we are seeing that once the INI routine has returned back to its caller, the condition handler is no longer established as desired. After reading further on the use of LIB$ESTABLISH, I do believe that this resetting/loss of the established CH is expected behavior, so I was looking for an alternative...and then the SYS$SETEXV came to mind.

Admittedly, these suggestions away from $SETEXV's use interest me...is there a downside to its use? Can harm come about? Hmmm...cannot help but wonder. I do understand that if one is not familiar with the use of a certain service that their improper use may be more harmful than useful...especially when run with elevated privileges. But, I cannot help but be curious...is this truly that harmful? Can LIB$ESTABLISH do what we seek? Could I just be misusing LIB$ESTABLISH and, if not, are there alternatives to it and/or SYS$SETEXV ?

Hmmmm.....

I do thank you for your responses.

-Howard-

[HDS]

Thank you Hoff and John.

My last response was sent before I read your latest postings.

I am grateful for the advice.

I will presnt this information to the powers-that-be and see what comes out of it.

Again, I thank you. This is very helpful.

-Howard-

[John Gillings]

Howard,

Yes, misuse of $SETEXV can be harmful. It's non-modular. You may be replacing exception vectors put in place by other system components (the language, DEBUG, etc...). You have no idea what you might be breaking.

Note that it is possible to establish a handler for a higher level routine. On VAX it was trivially easy, just walk up the call stack and drop your handler address at the top of the frame pointer you want to establish the handler for. On Alpha and Itanium it's more complex, but (I believe) still possible. Check out the LIB$*INVO_CONTEXT routines, and the calling standards. Effectively you want to call a routine "ESTABLISH_HANDLER_FOR_MY_CALLER".

[RBrown_1]

You said "... we have a common callable subroutine used as an initialization routine in most of our main routines. A new subroutine call was added to that standard INI routine that makes use of the LIB$ESTABLISH. However, we are seeing that once the INI routine has returned back to its caller, the condition handler is no longer established as desired."

We solved this problem with LIB$INITIALIZE. See the Programming Concepts manual, chapter "Image Initialization". You use this to perform initialization before your main program is called. It the initialation establishes a condition handler, then it will be there when your main program starts.

Hoff mentioned that this was not his favourite thing to do, but was better than SYS$SETEXV.

[Hoff]

Depending on what you're up to (and I don't know that I've seen that particular detail listed quite yet), sometimes an exit handler ($dclexh) can be an appropriate construct, as can be the distributed lock manager. If I need to have a reliable rundown (across application and system crashes), I tend to use the distributed lock manager or DECdtm (or direct to 2PC, 3PC or Paxos) and/or RMS journaling and/or database journaling.

[HDS]

Good morning and Thank You.

The ideas presented are being discussed amongst the participants here. The LIB$INITIALIZE seems to be a possible approach; we're trying to see if it does what is needed.

The specific details of this particular project are difficult for me to explain at this time, but I will try to obtain a clear description that can be posted. I understand that doing so would be helpful.

Thank you all for the responses. This kind of information from experienced and knowledgable professionals is so extremely helpful.

-H-

[HDS]

Hello.

I have provided all of this useful information to the interested parties. They are working on an approach now.

I wish to thank all for your assistance.

-Howard-