I have been using assembler for the last 30 years or so and not doing much coding in COBOL.

I now have a need to write a program that needs to have a user written error handler.

The concept of the program is that it will issue a SET xxxx to ENTRY 'modname'. The problem is, modname may not exist in the current set of load libraries available to the program. So, I want to trap the S806 that will be issued (that is, the CEE3DD error) and allow the program to continue versus be aborted.

I have successfully written a two program construct that traps the S806 and allows the program to continue, but what I really want to do is combine the two programs into 1 and use an ENTRY statement for the entry point of the error handler.

I have done this and the SET used to obtain the entry point of the handler function and is successfully used in a registration call for the error handler.

Unfortunately, when I execute the program, the error handle routine does not get control. My SET xxxx to ENTRY 'modname" fails with a CEE3501S, which is the s806 LE abend code, which my error handler is lookginfor, but, as I indicated, the error handler isn't gaining control.

To be clear, I do have two entries in my load library for the program and the error handler. In fact, the error handler is shown in the load library member list as being an ALIAS of the main program.

If I check the link edit output, it all appears to be correct and it, too, shows the main program and the error handle entry as being an alternate entry point.

I realize that this is going to cause 2 copies of the executable module to be loaded, but the modules are very small so I don't really care about that part.

Has anyone written a main program/error handler construct like this? If so, did you ever get it to work?

Thanks,

Charles

Why don´t you write a LE condition handler employing callable services

• CEEHDLR (register a condition handler) and
• CEEHDLU (unregister a condition handler)

and

the actual handler.

The handler can be implementeds in COBOL and be statically linked to your application program.

One problem may be the communication between the applcation and the handler, how to signal an error? That may however be solved by using the GLOBAL attribute on a parameter definition residing in both sources (application and handler).

As a excercise I actually wrote this two part executable:

1. Application that does "set procedure-pointer..." and
2. handler that reacts and reports on S806

And it works all right to my understanding at least.

Regards Lars

Thanks Lars,

I have written an error handler, in cobol, using the LE routines you have cited.

If the code is placed into a section of the main program identified with an ENTRY statement, it doesn't work.

If I put it into a separately compiled program, it works.

Unfortunately, the separately compiled program version is not the desired, nor mandated, version we need.

Ultimately, using a separately compiled program or an ENTRY within a single program should provide EXACTLY the same results.

If I compile and link a program of the desired name for the handler, I get a unique copy of the program loaded when the handler is registered.

If I use an ENTRY statement in a single program I get an ALIAS for the main program with the proper entry point identified and, at runtime, when the handler is registers I get a unique copy of the load module loaded.

So, what's the difference whether I code a separate program or an ENTRY within another program. In both cases the code for the handler is loaded independently from the main program that is registering the handler.

Thanks for the suggestion but I've already gone past the point of your suggestion and am in need of why it isn't working the way it should.

Chuck

OK, so I think I know how your setup is working. By the way, do you use the DYNAM compiler option? I did not and got the linkage editor resolving:

• My conditon handler and
• My application submodule (as used in the "set procedure-pointer...." statement).

at compile/link time (no dynamic loads whatsoever).

My change at first (before i saw your reply) was to "hide" the application module in a variable which is set at runtime like:

1. Move 'SUBMOD' To Ws-dynmod
2. Set  Ws-Pointer To Ws-dynmod

Which that took care of that.

So this was my setup:

Main program statically linked with the Condition handler and a dynamic invocation of some sub-module with unknown existence.

Btw, this would be our standard setup for condition handlers in order to be able to reuse them in different main programs.

In your setup however, as I understand it, is that all "linking" is done in runtime, right? So you store the executable as one (physical) load module with an alias entry (for the condition handler). So, to my understanding, what will happen at runtime, when the condition happens is:

The Conditon name "load" (the alias) will be loaded which actually means that a new copy (what if it is marked REUS or RENT?) of the executing program will be put into memory (as you stated before).

The question here however is which entry-point will be used when control is passed to the condition handler. Externally known as its condition handler name but the copy in memeory still has the primary entry point set to the application program (Program-Id).

• You said that in this scenario the condition handler will not be invoked (by its entry point name) but what happens instead?
• Is any (application) code at all invoked?
• Did you run it in a debugger?

What are the LE-messages and abends?

Regards Lars