1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

single user job failing

Discussion in 'Database Admin' started by pradeep10, Apr 10, 2012.

  1. pradeep10

    pradeep10 New Member

    Hi Experts, Am an AIX admin and very new to the progress DB. I have a single user EOD job scheduled in my server and it is not completing in the expected time. I was told by the application team that this job gets completed in an hour time which is now taking more than 4 hours but still not completing. I am concerned about 2 errors. ERROR 1 : FLOATING POINT exception ERROR 2 : bfx: Field too large for a data item. Try to increase -s. (42)....... Can you let me know whether these 2 errors are the culprits which keeps the job running for a very long time and not completing the job in time. Can you please help me out to fix this issue.
  2. Rob Fitzpatrick

    Rob Fitzpatrick ProgressTalk.com Sponsor

    Welcome to ProgressTalk. Please take a moment to read the Posting Guidelines. It will increase the likelihood that you will receive useful feedback to your posts.

    Specifically, please state your Progress version and service pack, and your operating system(s) and version(s).

    Regarding your description of the problem, there may be a terminology issue. A Progress database can be opened in one of two ways, either single-user (with a Progress client or utility) or multi-user (with a Progress database broker). As the names suggest, when you have opened a database single-user, no other users can connect to it. If it was opened multi-user, then many Progress (or "4GL") clients can connect simultaneously, either locally on the database server ("self-service client") or remotely via TCP ("remote client"). SQL clients are always remote (TCP), even if they run on the database server. You stated that this end-of-day job is single user, but I suspect it may be a self-service batch-mode client connected to a multi-user database; this is typical for batch processing. You should confirm whether the database actually gets shut down at end of day and this job runs single-user, or whether it is running multi-user. If it is single-user, then you are incurring unnecessary downtime and experiencing reduced performance.

    Progress runtime error messages that appear in log files or in the UI typically end with a number in brackets, as you see in your ERROR 2. These numbers can be looked up in a Progress editor under the Help menu, assuming you have access to that.

    Here is the description of an error 42:
    The "-s" in question is a client startup parameter, which is specified in the application command line that launches the Progress client session in which the application code runs. The -s parameter specifies the size of the call stack in KB, and defaults to 40. Depending on your application design (deep call stack, use of recursion, etc.), you may need to specify a value greater than the default to prevent this error. However that may just be masking an application design issue. Your "application team" needs to take ownership of this issue and explore it further. Regarding the floating point error, this could also be an application issue. Refer to this article from the Progress Knowledge Base.

    I can't advise you on application performance generally without knowing more about your Progress version, OS, hardware, and database configuration. The latter can be found in the database log (dbname.lg) in the database directory. Search backward in the end of the file for "(333)", which is a multi-user start. The next 50-70 lines show the parameters with which the database was last started and will be helpful in assessing configuration at a high level.
  3. tamhas

    tamhas ProgressTalk.com Sponsor

    If the job is running much longer than usual and never completing, it is possible that the errors are putting it into an infinite loop. As a DBA, you are not really going to diagnose that from the outside. It will take a programmer.
Similar Threads
Forum Title Date
Development Running procedure in single-user Aug 16, 2013
QAD's MFG/PRO restrict printer to a single user Sep 12, 2011
Development Check if in single-user mode Aug 19, 2009
Database Admin single user db Nov 8, 2007
Symix Syteline Single User Mode and Multiple Developers... Sep 14, 2006

Share This Page