PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 09/13/2017 5:00 AM by  JimY
COBOL Slowness
 5 Replies
Sort:
You are not authorized to post a reply.
Page 1 of 212 > >>
Author Messages
Corey
Private
Private
New Member
(2 points)
New Member
Posts:2


Send Message:

--
04/13/2016 8:52 AM

    We are an Infor/Lawson customer working on an upgrade to their version 10 application suite. We are seeing significant delays in our batch job processing. When only one job is running with no users in our new environment we see process time 4 - 5 times longer than when they are run in version 9. We are running in a VM environment with the application and DB servers on separate servers running under Windows 2012 and SQL Server 2012 R2. After verifying and increasing resources on the servers we noted three things when the jobs are running.

    1. There is a FINDBEGRNG being used against the indexes, The increased times are associated with this call. The programs have been recompiled, with no change in the timing.

    2. While monitoring and capturing processing on the PID associated with the job there were messages indicating that that _ MFREDIR that the name not found or no such file. It attempted to locate the file multiple times with different file extensions - dll, gnt, int, 390, and lbr. The operation for Query Directory on path e:\MicroFocus\bin64\_MFREDIR(with each extension dll, gnt, int, and lbr) having a result of NO SUCH FILE with Detail: Filter:_MFREDIR(with each extension dll, gnt, int, and lbr). Same result and detail for QueryDirectory on E:\lsfprod\law\print\(User_ID). For QueryOpen Operation it appears to be looking for _MFREDIR in all of the directory structure - E:\MicroFocus\bin64, E:\MicroFocus\binn64, E:\MicroFocus\bin, C:\Windows\System32\, C:\Windows\System\, C:\Windows, E:\LUU, E:\cygwin64, E:\lsfprod\gen\bin, and under E:\Java, E:\PERL. All doing the QueryOpen looking for _MFREDIR.dll.

    3. After the job starts running and starts to perform COBOL it appears to stop and resource utilization drops to virtually no activity, which might be when the FINDBEGRNG call on the index might me running or extremely slow.

    We increased the ARRAYBUFSIZE to 100, added more memory did a defrag


    attachments show timestats on one job and PID process monitor sample

    Attachments
    John
    IT Director
    Mount Sinai Medical Center
    New Member
    (3 points)
    New Member
    Posts:1


    Send Message:

    --
    06/20/2017 10:02 AM

    We are getting the same slowness with our system as part of our upgrade and conversion to Windows.   Did you ever find any solution to your issue?

     

    Thanks.

    AlanK
    Project Manager
    Private
    Basic Member
    (19 points)
    Basic Member
    Posts:7


    Send Message:

    --
    09/08/2017 6:05 PM
    This may be a little late but we had unexplained performance issues when we moved from V9 to V10 Windows Platform on VMs. Testing direct queries to the database resulted in significantly slower times on the newer setup though it had more resources. Issue turned out to be performance settings on the vm host servers.
    JimY
    Private
    Private
    Veteran Member
    (1055 points)
    Veteran Member
    Posts:377


    Send Message:

    --
    09/12/2017 11:09 AM
    Hi AlanK,
    What performance settings did you modify on the VM host? Thank you.
    AlanK
    Project Manager
    Private
    Basic Member
    (19 points)
    Basic Member
    Posts:7


    Send Message:

    --
    09/12/2017 2:48 PM
    Hi JimY,
    I did not get a screenshot of the settings but the server team referenced the BIOS max performance settings' on the host server. These settings should be the same as recommend by Epic for their host vm servers.

    HTH
    Alan
    You are not authorized to post a reply.
    Page 1 of 212 > >>