PA100 going into Recovery

Sort:
You are not authorized to post a reply.
Author
Messages
Sheila Kendall
Advanced Member
Posts: 29
Advanced Member
    We have been having PA100 go into recovery almost daily for  a couple of months.  We have been working iwth Lawson Support, but so far none of us have found the cause yet.  It does not go into recovery every tiem,  it does not go into recovery every time for a specific action, although it "seems" like if it goes into recovery it is on three specific actions.  We've recompiled, rebuilt indexes, checked bsi (although I believe Lawson support thinks there is an Oracle issue around bsi interface),  we get inconsistent messages when it goes into recovery (as if it is just dumping out a message), we've run it at different times of the day.  I am checking custom indexes to make sure KEY CHANGE = YES,  but we have not recently added any new indexes.   ANy ideas of other things we could try?
    Donna Wirt
    Basic Member
    Posts: 17
    Basic Member
      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
      Sheila Kendall
      Advanced Member
      Posts: 29
      Advanced Member
        That was a great idea. It did not change the results, but I had not tried that yet.
        Karen Ploof
        Veteran Member
        Posts: 118
        Veteran Member
          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.
          Sheila Kendall
          Advanced Member
          Posts: 29
          Advanced Member
            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
            Karen Ploof
            Veteran Member
            Posts: 118
            Veteran Member
              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.
              Joe O'Toole
              Veteran Member
              Posts: 314
              Veteran Member
                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?
                Sheila Kendall
                Advanced Member
                Posts: 29
                Advanced Member
                  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. 
                  You are not authorized to post a reply.