PA100 going into Recovery

I had an incident where Add-Ins didn't work with IC11 but did work with other IC programs. Below are the compile instructions Infor Xtreme support gave me. They worked. It might be worth it for you to try this or talk to IX about it.
Event Note:
Donna, I'm going to have you recompile IC11 using the following steps:

1. cd to $LAWDIR/productline/icsrc/int/pdlib
This directory contains "machine code" for the source located in $LAWDIR/productline/icsrc/icpdlib .
To speed up compile time these files are not rebuilt every time a program compiles. In order to make sure that all of these files have been properly rebuilt, remove all of the files in that directory. Removing these files forces the compiler to rebuild them when the next compile is executed. This will increase the time it takes to compile a program temporarily.

2. run a lstinvk compile (List Invoke)
Since many of the programs in the procurement suite call "invoked" programs, it is important that the invoked programs are re-compiled as well as the program itself after the files in $LAWDIR/productline/int/pdlib are removed.
Example: lstinvk -q productline ic11

3. run a qcompile against the program itself
Example: qcompile productline ic ic11

That was a great idea. It did not change the results, but I had not tried that yet.

I assume that when it happens, you just recover the job and it completes successfully? Which would mean it's not a corrupt data issue.

Are the three actions the most common? If so, it's probably a coincidence that it fails when processing them. If not, is there something common? Are they the only ones that use every field (all 36 of them)? Are they the only ones that include user fields or fields that impact taxes or leave processing or fields that impact some other specific module? Are they the only ones that are often future-dated or affect positions 2-99? Are they the only ones that attempt to correct personnel action history?

Is there any chance PA100 is being run by multiple users at the same time resuting in a record lock? I know that's really reaching, but it's the only thing I can think of at this moment.

All good questions.  The three actions are common, do not use all of teh fields, but I think we are finding that it is occurringwhen it tries to do both PAEMPPOS and EMPLOYEE and we think it is about an update to user level and reporting location,  which does lead us down a bsi path but has gotten us nowhere.     Now,  we are trying these odd things.  It seems to be ok in trace mode but not as a normal compile.  Not convinved on that one yet.  Still trying it out

Sounds like you're able to identify the specific action that caused the failure. Have you tried to duplicate the problem by entering that action in a test environment with the Immediate flag set to "Y". Since it runs through the same logic as PA100, but for only the one transaction, it should be easier to debug (I'm not sure what the proper term is) and can easily be rerun as many times as necessary.

If you enter it in Immediate and it completes without issue, I would gess that whould be helpful info for the Lawson support folks.

I'm not sure if this is related but we had a similar problem when we upgraded to 9.01 with a locked work file causing one of the HR batch programs to go into recovery. No one including Lawson could figure it out and they actually starting writing a JT to amend the code. What we believe to be the cause was that an incorrect platform of LSF was accidentally installed by someone (32 bit on our 64 bit server). Why the install worked and no other major application problems surfaced baffles me but when we reinstalled the 64 bit version the problem seemed to go away. Has any system maintenance been performed on your instance?

Thank you for your replies.  We had done the PA52 with immediate and they did always work.   What we now think it is, is that the ulimit for the user lawson had to be set to unlimited.  As we did suspect that it was a space/file size issue, this does seem to make sense.  We have set it and twice now, it has run without going into recovery.