public inbox for linux-msdos@vger.kernel.org
 help / color / mirror / Atom feed
From: Shaw Tong Tan <shawtan@yahoo.com>
To: dosEmu-list <linux-msdos@vger.kernel.org>, "Alain M." <alainm@pobox.com>
Subject: Re: Status Update : Deployment of DOSEMU Application Server
Date: Wed, 29 Oct 2008 18:57:20 -0700 (PDT)	[thread overview]
Message-ID: <865250.65511.qm@web52508.mail.re2.yahoo.com> (raw)
In-Reply-To: <49087453.2060002@pobox.com>

Per the posted questions, the additional info below.

1.  DOSEMU+FreeDOS and CLIPPER Locking issue

Reply:  My specific scenario is as follow:

1a.  I do not have source code to the software.
1b.  From the original DOS batch file supplied by vendor, I can see that it setups the clipper path, so I assume it should be clipper-based.
1c.  The clipper-based software is also likely re-compiled with 3rd party tools.  I am not 100% sure on this.  I attempted this path initially because I wanted to solve the 100% CPU problem and there are several DOS tools out there that can help if you have a standard Clipper-based setup.  During the course of doing this I remember 1 or 2 tools that can check the compiled code (low-level) to see whether it has the loop present and change it, but the software I have gave negative result.  (according to info, that loop is pretty common on old dos program, the negative result likely means that the local software has some non-standard changes compared to straight clipper compile.)
1d.  Eventually I received an advice from list member to use a specialize tool and I did that.  However, I need to do additional nice level tuning and CPU affinity control to get to acceptable setup.

the above is to explain the clipper-based software background.  Now on to locking.

2.  For now, I have many users doing READ and upto 3 doing WRITE.
3.  Maybe that is why locking problem is minimal.  I am still observing since this is 1st week of deployment.  Prior to the deployment I have a test where I open 4 instances of the same data entry screen (key in PO)(so likely accessing the same tables and potentials locking issue)  However, they seemed to progress without any problems at the time of testing.

ST

  parent reply	other threads:[~2008-10-30  1:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-29  5:43 Status Update : Deployment of DOSEMU Application Server Shaw Tong Tan
2008-10-29 14:33 ` Alain M.
2008-10-29 18:36   ` Andrew Joakimsen
2008-10-29 21:15     ` Alain M.
2008-10-29 21:47       ` Andrew Joakimsen
2008-10-30  1:57   ` Shaw Tong Tan [this message]
2008-10-31  0:10     ` Andrew Joakimsen
2008-10-31  2:59       ` Shaw Tong Tan
  -- strict thread matches above, loose matches on Subject: below --
2008-10-30  9:02 Shaw Tong Tan
2008-10-30 13:42 ` Ivan Baldo
2008-10-30 13:43 ` Alain M.
2008-10-30 13:45 ` Alain M.
2008-10-30 17:14 Manfred Scherer
2008-11-02 22:40 ` Claudia Neumann
2008-11-08 16:49 Manfred Scherer
2008-11-09  8:24 ` Claudia Neumann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=865250.65511.qm@web52508.mail.re2.yahoo.com \
    --to=shawtan@yahoo.com \
    --cc=alainm@pobox.com \
    --cc=linux-msdos@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox