I have zero COBOL experience (but am fairly well-versed in other languages, so I think I can stumble along and figure it out), and am trying to look at a user exit written for us by Lawson Blended PS.

The code is in BNUX70PD - it is a custom calculation for when your benefits start based on your hire date (pretty simple, basically "if hire date between a and b, then start date=c, if between d and e, the f, etc.) BN16 is where we specify the custom calc is to be used for that plan, and BN31.2 shows the calculated eligibility date. All works fine in production.

Now I'm trying to merge these changes in to a new version of the files after loading a CTP. All looks fine to me, but the calculation is not running. I'm not sure if BN31.2 is when the calc is called, or if it is called at some point previous to this and BN31.2 is just reading it from the DB.

It look like BNED70PD performs 5000-DO-UX-FROM-DATE-70 if it is a custom calc, and BNED70PD seems to say that maybe BN100 is where this is actually called. Any tips on how to debug this for a newb? Thanks in advance!

It doesn't sound like you're using an actual "User Exit" here. Instead it sounds like you're talking about a modified / customized library routine.

Lawson terminology aside and assuming I've got it right, what you're describing sounds about right. Working backwards I see these calls:

5000-DO-UX-FROM-DATE-70 should contain the custom calculation and is called by
6200-SET-FROM-DATE is called by
6000-CALC-WAIT-PERIOD is called by
5000-ELIGIBILITY-DATE-CALC is called by
5000-ELIGIBILITY-DATE-CALC-70 is called by several programs, including -

BN100, 101, 145, 245, 31, 45 and BS12, 13, 14, 15.

So, to get this working in TEST or DEV you'll need to copy the customized code from PROD in the BNUX70PD library to the one in TEST/DEV and then recompile each program above to make sure that code is recognized. (library code is not dynamically linked and requires a recompile for each change).

If this does not work you could try DISPLAY statements or something in that routine to verify that the code is actually executing. DISPLAY works best for batch programs, but you can view them via 'tmmon' for on-line programs too. HOWEVER, since DISPLAY statements are not overly helpful for anything other than very simple problems you might have to go to the MicroFocus debugger utility. It's quite handy and answers most questions straight away, but does require some knowledge to get working the 1st time (particularly if you're on Windows). I'd recommend looking around this site and/or support.lawson.com if you need to go to that step.

Great reply, thanks. I'm having trouble finding much on how to use cobanim. KB article 72260 just says "set breakpoints as needed" (thanks a lot, mind telling me how?) Have a short list of cobanim keys or commands handy, or can someone point me to one?

I went though GSC since I was having some funky experiences with cobanim. For the record, here's what we did (BN31.2 as an example):

* compile with debugging enabled: qcompile -D test bn bn31
* verify ladebug.cfg settings per KB article 72260
* startladebug
* cobanim test bn31 (run this in LID, all you SSH types). you should see the COBOL source in the cobanim window immediately.
* hit "s" (for "step") until you reach the line
CALL "GetTransaction"
don't step past this line yet.
* open another LID session and pull up the form in question (lapm test bn31.2). put in your criteria and inquire (or whatever action you are debugging). The lapm session will hang, that's ok.
* switch over to your cobanim session and hit "s" - it should go back to stepping through the code.
* in general, the capital letter of the commands at the bottom are all you have to type to make that command happen. For example, to set a breakpoint, hit "b" (Breakpoint) and then "s" (Set). "bu" unsets a breakpoint. "f" to find text. "z" to zoom through the code to the next breakpoint. KB article 85243 is about all you can find anywhere documentation-wise. "q" to view the value of a variable.

I have some more playing to do, but I'll post the answer to my original problem once I figure it out.

A darn handy function also is the "p" for Perform-Step. This lets you "skip through" a section of cod you don't care about. So, for example, if you need the program to run the 200-EDIT-TRANS section, but you know you're problem isn't in there you can hit "p" instead of "s" (step). That will essentially perform the routine and come back to the next line. VERY handy (IMHO!). :)

I use this for database calls (840-FIND, etc) and when debugging batch programs I use it all the time for the print routines. Those print routines are REALLY long and are never where the problem is.

Good luck with debugger. Handy tool once you learn it.

Thanks Keith. For all those playing at home, the debugger showed me everything I need to know (once I figured out how to use it). The problem was that the CTPs had actually changed the code in BNED70PD, which is what calls the custom calc in BNUX70PD. The new code moved an uninitialized field over the calculated value, so I changed our custom code in BNUX70PD to save the calculated value to this different field instead (it all gets moved to the same field in the end, and it's still just BNUX70PD I have to maintain going forward).