[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::axp-developer

Title:Alpha Developer Support
Notice:[email protected], 800-332-4786
Moderator:HYDRA::SYSTEM
Created:Mon Jun 06 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3722
Total number of notes:11359

3328.0. "Yardarm Software Ltd - Point 23010" by RDGENG::ASAP () Mon Mar 17 1997 06:15

    Company Name :  Yardarm Software Ltd - Point 23010
    Contact Name :  Peter Terelak
    Phone        :  01372.37.51.93
    Fax          :  01372.37.71.83
    Email        :  [email protected]
    Date/Time in :  17-MAR-1997 11:14:40
    Entered by   :  John Wood
    SPE center   :  REO

    Category     :  VMS
    OS Version   :  6.2
    System H/W   :  Alpha


    Brief Description of Problem:
    -----------------------------

I am sending this in response to my query over VMS Resource Locking. We have
a problem with our application which we believe is due to the VMS Resource
Locking not working correctly all of the time, see also the attached code.
We believe the return from the ResourceLock procedure can be 0 even when the
Resource Lock fails.

I'm afraid it is not practical to send any more of the source code, both for
reasons of conifdentiality and because thereis so much of it - literally
thousands of files. Also, I cannot guarantee to reproduce the problem. The
configuration on which this problem occurs is:

        Alpha 1000
        VMS 6.2
        DecNet Full Function
        Clustering and shadowing enabled

I would like you to a) see if there is anything wrong with the code and b)
if you know of any problems logged with Resourc Locking which could occur
with our configuration and explain our problem. Many thanks.


#include <assert.h>
#include <lckdef.h>
#include <starlet.h>
#include <stdio.h>
#include <ssdef.h>

#include <atsstd.h>

#include <strdescriptor.h>
#include <systemlock.h>






Public Logical lockResource (
    SystemLock* sl,
    char*       res
)
{

    StrDescriptor resstr;
    long result;

    i_StrDescriptor (&resstr, res);

    result = sys$enqw (0, LCK$K_EXMODE, sl->lksb, 0, &resstr,0,0,0,0,0,0);

    return (result == SS$_NORMAL && sl->lksb[0] == SS$_NORMAL);
}





Public Logical unlockResource (
    SystemLock* sl
)
{

    long result;

    result = sys$deq (sl->lksb[1],0,0,0);

    return (result == SS$_NORMAL && sl->lksb[0] == SS$_NORMAL);
}

T.RTitleUserPersonal
Name
DateLines
3328.1RDGENG::WOOD_J[email protected]Mon Mar 17 1997 10:2486
Date:	17-MAR-1997 14:17:05.07
From:	DEC:.REO.REOVTX::WOOD_J       "[email protected]"
Subj:	Digital ASAP #23010: VMS lock manager
To:	smtp%"[email protected]"


Re. your report of problems with OpenVMS Alpha v6.2 Lock Manager:

> We have a problem with our application which we believe is due to the VMS
> Resource Locking not working correctly all of the time, see also the attached
> code. We believe the return from the ResourceLock procedure can be 0 even when
> the Resource Lock fails.

Thanks for the code example. A few comments:

o   VMS system services return an odd-numbered status if the work, and an
    even-numbered status if they fail. This makes it easy to test just the
    least signifigant bit of the status return to determine success or
    failure from the routine, without having to check for all the possible
    return values. The macro $VMS_STATUS_SUCCESS(code) in <stdef.h> returns
    TRUE if "code" indicates a good status.

    In your example, you're just testing for SS$_NORMAL, whereas $ENQW could
    also return a successful code of SS$_SYNCH (if the appropraite flag was
    passed in, which in your example you're not). Thus in your example a
    change to using the $VMS_STATUS_SUCCESS macro is unnecessary, but I
    thought I'd mention it as a general practise.

o   With the arguments you've specified to $ENQW, the call will either: return
    with an error status; or block (wait) until it is able to lock the
    resource, and then return a good status. If lockResource() manages to
    take out a lock, then it should return 1 (True); otherwise it should
    return 0 (False) to indicate failure. Your comment above seems to indicate
    you expected the code to behave differently to this: perhaps you could
    explain further?

    Because you don't expect $ENQW to fail, I suggest that you add some code
    after the $ENQW call to display the status-codes if they're not SS$_NORMAL.
    This might help identify the cause of any problem with your program. E.g.
    on my system, I get a status code 10820 back from $ENQW if I try to take
    out many locks: doing "$ EXIT 10820" I get a message indicating I've
    exceeded my lock enqueue limits, so now I know where to look to address
    the problem.


o   I found mention of a patch kit for OpenVMS Alpha v6.2 at the world-wide-web
    URL of:
        ftp://ftp.service.digital.com/public/vms/axp/v6.2/
    which I got to from the URL:
        http://www.service.digital.com/html/patch_public.html

    From the description of the patch:
    +++
        3  PROBLEMS ADDRESSED IN ALPSYS02_062 KIT
              o  SYS$ENQ System Service call/program hangs due to the event 
                 flag not being set.
              o  Due to an image build problem, the LOCKING.EXE  image included
                 in the ALPSYS01_062 kit did not contain the problem fix it
                 should have.
    ---
    However, this doesn't sound to me like your problem.


o   Your code example does not contain a definition of the lock status block
    structure. However, Looking at your code I suspect you're defined it
    as being something like:
        int lksb[2];
    whereas a better definition would be:
        struct lksb_struct
        {
            short condition_value;
            short reserved;
            int   lock_id;
        } lksb;
    If my guess is right, you might be accessing *both* the shorts as the
    condition-value. Now this will happen to work if "reserved" is always zero,
    which in my tests it happened to be, but cannot be relied upon.


I hope this helps you progress the problem.

  John Wood
  Software Partner Engineering (UK)
  Digital Equipment Co.


3328.2RDGENG::WOOD_J[email protected]Fri Mar 21 1997 03:4535
Date:	21-MAR-1997 08:30:23.55
From:	DEC:.REO.REOVTX::WOOD_J       "[email protected]"
Subj:	RE: Lock Problem
To:	SMTP%"[email protected]"

>Thanks for your reply on this problem. Could you tell me how I can determine
>the lock enqueue limits, and how they can be changed.

Enqueue limits are a process quota. To see the amount of quota a process
has remaining, do:

$ SHOW PROCESS /QUOTA  [/ID=pid]
..
Process Quotas:
  ..
 Enqueue quota:                      2000  Shared file limit:        0
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


To change a process's enqueue quota, use the AUTHORIZE utility:

$ set process /privilege=all
$ set def sys$system
$ run authorize
UAF> show <username>
..
CPU:        (none)  Enqlm:      2000  Pgflquo:     500000
..	            ^^^^^^^^^^^^^^^^
UAF> modify <username> /enqlm=3333
	-this will change the user's value of ENQLM when he next logs in

Hope this helps.

Regards,
  John Wood