Re: Client/Server Fujitsu Cobol appplications

From: jason (vyjs2m_at_hotmail.com)
Date: 04/15/04

  • Next message: docdwarf_at_panix.com: "Re: [OT] Hourly rate?" 
    Date: 15 Apr 2004 05:38:12 -0700

    riplin@Azonic.co.nz (Richard) wrote in message news:<217e491a.0404061107.216f412@posting.google.com>...
    > "Euromercante" <euro@dsdd.com> wrote
    >
    > > I've an application installed in the server (2003 server; 1GB RAM) and
    > > in the clients I've installed the runtime of Fujitsu on PC's with XP up to
    > > 40 PC's. We shared a folder with our application (with our cobol database
    > > files) in the server.
    > > I'm having some problems, because sometimes when I run a module of my
    > > application it takes 30 seconds and sometimes it takes more then 5 minutes.
    > > Do you know any similar situations, or why this is happening??
    > > Do you know a better way to configure this "Client/Server" application?
    >
    > You are most likely saturating the network with raw file block
    > accesses. Running the clients with shared file access on the server
    > means that with ISAM file the client will want to read the index
    > blocks for each data record read. A random read of one record may
    > require a dozen index block accesses. Of course these blocks cannot
    > be cached in the client because they may change as records are added
    > by others.
    >
    > It may also be lock contention. If there are a few records that are
    > used frequently and these are locked while user do input then the
    > programs may be spending long times waiting for locks to become free.
    >
    > Or it may be that the programs are doing just too much file access.
    > They may be reading files sequentially searching for data when they
    > should have had an index to get the data directly.
    >
    > Nothing that a complete redesign can't fix.

    Fujitsu Cobol tech. suport says
    1)it is better to use
       LOCK MODE MANUAL WITH LOCK ON MULTIPLE RECORDS
       not AUTOMATIC LOCK

    2)Lock a record [read with lock, read next with lock]
    only when you want to update/delete a record, and
    release it right away when the update work is done.

    3) Check the 2-byte file status for record lock ("99")
      and return control to your program for proper actions.

    These might ease the slow response problem.

    good lock,

    jason mo

  • Next message: docdwarf_at_panix.com: "Re: [OT] Hourly rate?"

    Relevant Pages

    • Re: File locking between Linux server and HP-UX 10.20 client
      ... > We are running into odd file locking problems between our NFS server ... ..from one of the HP clients. ... the portmapper on the server and whether a lock service is available. ...
      (comp.sys.hp.hpux)
    • Avoiding deadlocks in concurrent programming
      ... This is not really Python specific, but I know Python programmers are ... Since many clients can be making requests at once (>100 per second ... complicated by a backup thread which takes the data every 10 minutes ... The easiest way from a design stand point is have a single lock and let ...
      (comp.lang.python)
    • Re: 2000 server NT4 clients
      ... Use a combination of the old system policy editor on the server. ... poledit) and install security configuration manager on the NT clients ... and lock them down locally. ...
      (microsoft.public.win2000.networking)
    • Re: Lock a row
      ... and if the connection dies you are not even going ... Use the readpast hint as mentioned by Hugo to keep any clients ... >> row from a wrok-queue table and acquire an exclusive lock; ...
      (microsoft.public.sqlserver.programming)
    • Re: 2000 server with NT4 clients
      ... clients as they log in. ... "Chris" wrote in message ... > How do I lock down nt4 with a 200 server. ...
      (microsoft.public.win2000.security)