3 minute response time on all on-line screens. iSeries

 3 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
KAZ
New Member
Posts: 2
New Member

    I'm hoping someone might come up with a few ideas on this.  We have a level 1 case opened with GSC, but they seem stymied.   We’ve been a Lawson shop for 10 years, and have never seen anything like this. Quite suddenly this past Friday morning, all of the on-line screens for all modules starting getting 3 minute response times. Any DB navigation or update results with the same dreadful response. We’ve been on R9 for 2 years now, and had always had good (< 2 sec) on most screen activity, e.g. Next/Prev, Change, etc.

    This is occurring in both Portal and LID. Many aspects of Lawson are acting normally (batch jobs, laua, etc).  Functions that spawn LACOBRTS Processes (AP10, PO20, etc), are the ones we’re having the problems with.  Any DB navigation or action within these jobs results in a 3 minute response time.  Network and firewall rules have been thoroughly investigated, and nothing seems abnormal.
    There are a lot of hands on this box, so I’m guessing someone tweaked something, and may not want to own up to it.
    Background. iSeries V5R4, Lawson 9.0.0.4 apps/env, RSS/PFlow. HP Openview and AppWorx for sys monitoring and scheduling.
    Hoping some of the good people here may have an idea where we can look.
    TIA
    Jimmy Chiu
    Veteran Member
    Posts: 641
    Veteran Member

      Have you tried a complete reboot of the whole lawson server set?

      Are your server(s) hosted locally?

       

      KAZ
      New Member
      Posts: 2
      New Member

        Thanks for the reply Jimmy.  Yes on the reboots, a couple of times.  But we just found the problem about 35 minutes ago!

        It looks like someone in one our facilities in another city logged onto our network with a PC named LOCALHOST. This caused our corporate DNS to point to that person's laptop when resolving LOCALHOST. Hence, when Lawson tried to talk to itself, it would sit there retrying that bad IP. 

        We cleared LOCALHOST off the DNS, did a CFGTCP, opt 12, hit enter. Voila.   Reponse was back to normal immediately.

        Thanks for all you took a look at our issue.  It was a long weekend!

        Jimmy Chiu
        Veteran Member
        Posts: 641
        Veteran Member
          A workstation with a computer name "LOCALHOST"... nice one.