Cluster problems - or maybe license problems? - VMS

This is a discussion on Cluster problems - or maybe license problems? - VMS ; Hi All I have 3 alphas (alpha, beta and gamma - imaginative names eh!)- (2*DS10L and one Personal Alpha v2) running hobbyist versions of VMS 8.3 and all the layered product licenses. DECnet Plus is operating perfectly on all of ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Cluster problems - or maybe license problems?

  1. Cluster problems - or maybe license problems?

    Hi All

    I have 3 alphas (alpha, beta and gamma - imaginative names eh!)-
    (2*DS10L and one Personal Alpha v2) running hobbyist versions of VMS 8.3
    and all the layered product licenses. DECnet Plus is operating
    perfectly on all of them and I have used them fine for a long time. The
    licenses have expiry dates of August. I decided to cluster them, so I
    read the fine manuals to refresh my memory and then ran CLUSTER_CONFIG
    on alpha.

    I told it to boot locally, not serve MSCP or boot disks, use an
    ALLOCLASS of 1, use LANCP for cluster comms etc., expected votes = 2
    (three nodes, so any two are OK), no quorum disk.

    When it reboots, all is fine *except* that it has now decided that the
    OPENVMS-ALPHA license is expired. Checking the database it shows an
    expiry of August. The LMF logical points to SYS$COMMON:[SYSEXE] as I
    think it should. So, some things won't start and I can only log in from
    the console. Funny thing is that TCP/IP and everyhting else is fine -
    the web server works and is accessible, FTP works - I can't log in.

    Next problem - I ran CLUSTER_CONFIG on gamma, told it to join the
    cluster, same configuration details etc. When it boots, it joins the
    cluster and then fails back to the >>> with the message

    OpenVMS (TM) Alpha Operating System, Version V8.3
    © Copyright 1976-2006 Hewlett-Packard Development Company, L.P.

    %DECnet-I-LOADED, network base image loaded, version = 05.13.00

    %SYSINIT-I- waiting to form or join an OpenVMS Cluster
    %VMScluster-I-LOADSECDB, loading the cluster security database
    %CNXMAN, Sending VMScluster membership request to system ALPHA
    %CNXMAN, Now a VMScluster member -- system GAMMA
    %SYSINIT-E- volume already mounted on a differently-named device, status
    = 00728
    0B4

    **** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****

    ** Bugcheck code = 0000036C: PROCGONE, Process not in system
    ** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: GAMMA
    ** Supported CPU count: 00000001
    ** Active CPUs: 00000000.00000001
    ** Current Process: SYSINIT
    ** Current PSB ID: 00000001
    ** Image Name: SYSINIT.EXE


    OK, what volume? There is only one disk in each box, MSCP_LOAD and
    MSCP_SERVE_ALL are both 0....what have I done wrong (again)!

    All help truly appreciated.

    Cheers

  2. Re: Cluster problems - or maybe license problems?

    Gremlin wrote:

    > use an
    > ALLOCLASS of 1,


    Same on all three boxes ?

  3. Re: Cluster problems - or maybe license problems?

    Jan-Erik Söderholm wrote:
    > Gremlin wrote:
    >
    >> use an ALLOCLASS of 1,

    >
    > Same on all three boxes ?


    No - alpha is 1, gamma is 2

  4. Re: Cluster problems - or maybe license problems?

    This is your problem:

    %SYSINIT-E- volume already mounted on a differently-named device, status =
    00728

    All the system drives on the three different machines have the same volume
    label. Boot two of the three machines, standalone, and rename the volume
    label to something unique.

    $ set vol/label=newlabel

    Ken


  5. Re: Cluster problems - or maybe license problems?

    Gremlin wrote:
    > Hi All
    >
    > I have 3 alphas (alpha, beta and gamma - imaginative names eh!)-
    > (2*DS10L and one Personal Alpha v2) running hobbyist versions of VMS 8.3
    > and all the layered product licenses. DECnet Plus is operating
    > perfectly on all of them and I have used them fine for a long time. The
    > licenses have expiry dates of August. I decided to cluster them, so I
    > read the fine manuals to refresh my memory and then ran CLUSTER_CONFIG
    > on alpha.
    >
    > I told it to boot locally, not serve MSCP or boot disks, use an
    > ALLOCLASS of 1, use LANCP for cluster comms etc., expected votes = 2
    > (three nodes, so any two are OK), no quorum disk.
    >
    > When it reboots, all is fine *except* that it has now decided that the
    > OPENVMS-ALPHA license is expired. Checking the database it shows an
    > expiry of August. The LMF logical points to SYS$COMMON:[SYSEXE] as I
    > think it should. So, some things won't start and I can only log in from
    > the console. Funny thing is that TCP/IP and everyhting else is fine -
    > the web server works and is accessible, FTP works - I can't log in.
    >
    > Next problem - I ran CLUSTER_CONFIG on gamma, told it to join the
    > cluster, same configuration details etc. When it boots, it joins the
    > cluster and then fails back to the >>> with the message
    >
    > OpenVMS (TM) Alpha Operating System, Version V8.3
    > © Copyright 1976-2006 Hewlett-Packard Development Company, L.P.
    >
    > %DECnet-I-LOADED, network base image loaded, version = 05.13.00
    >
    > %SYSINIT-I- waiting to form or join an OpenVMS Cluster
    > %VMScluster-I-LOADSECDB, loading the cluster security database
    > %CNXMAN, Sending VMScluster membership request to system ALPHA
    > %CNXMAN, Now a VMScluster member -- system GAMMA
    > %SYSINIT-E- volume already mounted on a differently-named device, status
    > = 00728
    > 0B4
    >
    > **** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
    >
    > ** Bugcheck code = 0000036C: PROCGONE, Process not in system
    > ** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: GAMMA
    > ** Supported CPU count: 00000001
    > ** Active CPUs: 00000000.00000001
    > ** Current Process: SYSINIT
    > ** Current PSB ID: 00000001
    > ** Image Name: SYSINIT.EXE
    >
    >
    > OK, what volume? There is only one disk in each box, MSCP_LOAD and
    > MSCP_SERVE_ALL are both 0....what have I done wrong (again)!
    >
    > All help truly appreciated.
    >
    > Cheers


    Fantastic - re-labelling fixed the second problem, any thoughts about
    why the license now seems invalid? Now both nodes nelieve that there is
    no valid OPENVMS_ALPHA license, but everything else (like TCP/IP etc)
    works fine!!

  6. Re: Cluster problems - or maybe license problems?

    On May 2, 9:37 am, Gremlin wrote:
    > Gremlin wrote:
    > > Hi All

    >
    > > I have 3 alphas (alpha, beta and gamma - imaginative names eh!)-
    > > (2*DS10L and one Personal Alpha v2) running hobbyist versions of VMS 8.3
    > > and all the layered product licenses. DECnet Plus is operating
    > > perfectly on all of them and I have used them fine for a long time. The
    > > licenses have expiry dates of August. I decided to cluster them, so I
    > > read the fine manuals to refresh my memory and then ran CLUSTER_CONFIG
    > > on alpha.

    >
    > > I told it to boot locally, not serve MSCP or boot disks, use an
    > > ALLOCLASS of 1, use LANCP for cluster comms etc., expected votes = 2
    > > (three nodes, so any two are OK), no quorum disk.

    >
    > > When it reboots, all is fine *except* that it has now decided that the
    > > OPENVMS-ALPHA license is expired. Checking the database it shows an
    > > expiry of August. The LMF logical points to SYS$COMMON:[SYSEXE] as I
    > > think it should. So, some things won't start and I can only log in from
    > > the console. Funny thing is that TCP/IP and everyhting else is fine -
    > > the web server works and is accessible, FTP works - I can't log in.

    >
    > > Next problem - I ran CLUSTER_CONFIG on gamma, told it to join the
    > > cluster, same configuration details etc. When it boots, it joins the
    > > cluster and then fails back to the >>> with the message

    >
    > > OpenVMS (TM) Alpha Operating System, Version V8.3
    > > © Copyright 1976-2006 Hewlett-Packard Development Company, L.P.

    >
    > > %DECnet-I-LOADED, network base image loaded, version = 05.13.00

    >
    > > %SYSINIT-I- waiting to form or join an OpenVMS Cluster
    > > %VMScluster-I-LOADSECDB, loading the cluster security database
    > > %CNXMAN, Sending VMScluster membership request to system ALPHA
    > > %CNXMAN, Now a VMScluster member -- system GAMMA
    > > %SYSINIT-E- volume already mounted on a differently-named device, status
    > > = 00728
    > > 0B4

    >
    > > **** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****

    >
    > > ** Bugcheck code = 0000036C: PROCGONE, Process not in system
    > > ** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: GAMMA
    > > ** Supported CPU count: 00000001
    > > ** Active CPUs: 00000000.00000001
    > > ** Current Process: SYSINIT
    > > ** Current PSB ID: 00000001
    > > ** Image Name: SYSINIT.EXE

    >
    > > OK, what volume? There is only one disk in each box, MSCP_LOAD and
    > > MSCP_SERVE_ALL are both 0....what have I done wrong (again)!

    >
    > > All help truly appreciated.

    >
    > > Cheers

    >
    > Fantastic - re-labelling fixed the second problem, any thoughts about
    > why the license now seems invalid? Now both nodes nelieve that there is
    > no valid OPENVMS_ALPHA license, but everything else (like TCP/IP etc)
    > works fine!!


    I can't remember if this affects clusters without a common system disk
    and/or license database. With a common database you have to set
    certain licenses to EXCLUDE the nodes other than the one you want to
    load them. If for example you have three OPENVMS-ALPHA-USER licenses,
    one for each node, you had to LICENSE MODIFY OPENVMS-ALPHA-USER/
    AUTH=node1licenseauthstring/EXCLUDE=(node2,node3), and do the same for
    each of the other two licenses. Otherwise whichever node accessed
    first would load all of the license PAKs and leave none for subsequent
    boots.

    I don't know if that is your problem. Double check the expiration
    dates on your cluster licenses, as well as the base and user licenses
    though.

    Rich

  7. Re: Cluster problems - or maybe license problems?

    Rich Jordan wrote:
    > On May 2, 9:37 am, Gremlin wrote:
    >> Gremlin wrote:
    >>> Hi All
    >>> I have 3 alphas (alpha, beta and gamma - imaginative names eh!)-
    >>> (2*DS10L and one Personal Alpha v2) running hobbyist versions of VMS 8.3
    >>> and all the layered product licenses. DECnet Plus is operating
    >>> perfectly on all of them and I have used them fine for a long time. The
    >>> licenses have expiry dates of August. I decided to cluster them, so I
    >>> read the fine manuals to refresh my memory and then ran CLUSTER_CONFIG
    >>> on alpha.
    >>> I told it to boot locally, not serve MSCP or boot disks, use an
    >>> ALLOCLASS of 1, use LANCP for cluster comms etc., expected votes = 2
    >>> (three nodes, so any two are OK), no quorum disk.
    >>> When it reboots, all is fine *except* that it has now decided that the
    >>> OPENVMS-ALPHA license is expired. Checking the database it shows an
    >>> expiry of August. The LMF logical points to SYS$COMMON:[SYSEXE] as I
    >>> think it should. So, some things won't start and I can only log in from
    >>> the console. Funny thing is that TCP/IP and everyhting else is fine -
    >>> the web server works and is accessible, FTP works - I can't log in.
    >>> Next problem - I ran CLUSTER_CONFIG on gamma, told it to join the
    >>> cluster, same configuration details etc. When it boots, it joins the
    >>> cluster and then fails back to the >>> with the message
    >>> OpenVMS (TM) Alpha Operating System, Version V8.3
    >>> © Copyright 1976-2006 Hewlett-Packard Development Company, L.P.
    >>> %DECnet-I-LOADED, network base image loaded, version = 05.13.00
    >>> %SYSINIT-I- waiting to form or join an OpenVMS Cluster
    >>> %VMScluster-I-LOADSECDB, loading the cluster security database
    >>> %CNXMAN, Sending VMScluster membership request to system ALPHA
    >>> %CNXMAN, Now a VMScluster member -- system GAMMA
    >>> %SYSINIT-E- volume already mounted on a differently-named device, status
    >>> = 00728
    >>> 0B4
    >>> **** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
    >>> ** Bugcheck code = 0000036C: PROCGONE, Process not in system
    >>> ** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: GAMMA
    >>> ** Supported CPU count: 00000001
    >>> ** Active CPUs: 00000000.00000001
    >>> ** Current Process: SYSINIT
    >>> ** Current PSB ID: 00000001
    >>> ** Image Name: SYSINIT.EXE
    >>> OK, what volume? There is only one disk in each box, MSCP_LOAD and
    >>> MSCP_SERVE_ALL are both 0....what have I done wrong (again)!
    >>> All help truly appreciated.
    >>> Cheers

    >> Fantastic - re-labelling fixed the second problem, any thoughts about
    >> why the license now seems invalid? Now both nodes nelieve that there is
    >> no valid OPENVMS_ALPHA license, but everything else (like TCP/IP etc)
    >> works fine!!

    >
    > I can't remember if this affects clusters without a common system disk
    > and/or license database. With a common database you have to set
    > certain licenses to EXCLUDE the nodes other than the one you want to
    > load them. If for example you have three OPENVMS-ALPHA-USER licenses,
    > one for each node, you had to LICENSE MODIFY OPENVMS-ALPHA-USER/
    > AUTH=node1licenseauthstring/EXCLUDE=(node2,node3), and do the same for
    > each of the other two licenses. Otherwise whichever node accessed
    > first would load all of the license PAKs and leave none for subsequent
    > boots.
    >
    > I don't know if that is your problem. Double check the expiration
    > dates on your cluster licenses, as well as the base and user licenses
    > though.
    >
    > Rich

    Hi Rich

    All licenses expire on the same data - 11-AUG-2008. The problem occurs
    even if only a single node is booted - the only way to stop it is to
    conversational boot, set VAXCLUSTER 0 then continue. Licenses work
    fine, but no cluster

    I will try your suggestion once I have settled the remaining tasks -
    seems a bit weird though and googling produces no help - than goodnes
    for cov!

  8. Re: Cluster problems - or maybe license problems?

    On Sat, May 03, 2008 at 01:11:57AM +1000, Gremlin wrote:
    > Rich Jordan wrote:
    > >
    > >I can't remember if this affects clusters without a common system disk
    > >and/or license database. With a common database you have to set
    > >certain licenses to EXCLUDE the nodes other than the one you want to
    > >load them. If for example you have three OPENVMS-ALPHA-USER licenses,
    > >one for each node, you had to LICENSE MODIFY OPENVMS-ALPHA-USER/
    > >AUTH=node1licenseauthstring/EXCLUDE=(node2,node3), and do the same for
    > >each of the other two licenses. Otherwise whichever node accessed
    > >first would load all of the license PAKs and leave none for subsequent
    > >boots.


    I think this should be /INCLUDE:

    $ help lic modify/include

    LICENSE

    MODIFY

    /INCLUDE

    /INCLUDE=(node-name[,node-name,...])

    Specifies that the named node or nodes in an OpenVMS Cluster
    environment can access the licensed product. Only the included
    nodes can load (with a LICENSE LOAD or LICENSE START command)
    the license registered in the License Database. Each node-name
    argument must be an SCS node name, or a system parameter set with
    SYSGEN. The node name might not be the same as the DECnet node
    name.

    Licenses for the OpenVMS operating system usually specify the
    NO_SHARE option on their PAKs. In a cluster environment you must
    restrict each of these OpenVMS licenses to a single node. If

    [etc.]

    I did this on my cluster.

    --
    Anton Shterenlikht
    Room 2.6, Queen's Building
    Mech Eng Dept
    Bristol University
    University Walk, Bristol BS8 1TR, UK
    Tel: +44 (0)117 928 8233
    Fax: +44 (0)117 929 4423

  9. Re: Cluster problems - or maybe license problems?

    In article , Gremlin writes:
    >
    > When it reboots, all is fine *except* that it has now decided that the
    > OPENVMS-ALPHA license is expired.


    Sounds like a clock problem. I had this for a while at the turn of
    the year, VMS and NTP were in disagreement over what year it wasa.


    > %SYSINIT-E- volume already mounted on a differently-named device, status
    > = 00728
    >
    > OK, what volume? There is only one disk in each box, MSCP_LOAD and
    > MSCP_SERVE_ALL are both 0....what have I done wrong (again)!


    The systems disks (in your case, only disks) on the nodes have the
    same volume name. That is not allowed in a cluster. Boot the first
    node, use "set volume/label" to change it's system disk label, boot
    the second, ...



  10. Re: Cluster problems - or maybe license problems?

    The two commands (/INCLUDE and /EXCLUDE) are totally different,
    and both work EXACTLY as they should:

    /INCLUDE=(node-name[,node-name,...])
    Only the listed node(s) can access the specified license.

    /EXCLUDE=(node-name[,node-name,...])
    Any node other than the listed node(s) can access the specified
    license.


    In your 3 node cluster,

    /INCLUDE=ALPHA

    Would be exactly the same as

    /EXCLUDE=(BETA,GAMMA)


  11. Re: Cluster problems - or maybe license problems?

    In article , Gremlin writes:
    >
    > When it reboots, all is fine *except* that it has now decided that the
    > OPENVMS-ALPHA license is expired. Checking the database it shows an
    > expiry of August. The LMF logical points to SYS$COMMON:[SYSEXE] as I
    > think it should. So, some things won't start and I can only log in from
    > the console. Funny thing is that TCP/IP and everyhting else is fine -
    > the web server works and is accessible, FTP works - I can't log in.


    Expired or not available? In a cluster the VMS license is node
    specific, and this must be designated on each license via
    /include= .


  12. Re: Cluster problems - or maybe license problems?

    DanO wrote:
    > The two commands (/INCLUDE and /EXCLUDE) are totally different,
    > and both work EXACTLY as they should:
    >
    > /INCLUDE=(node-name[,node-name,...])
    > Only the listed node(s) can access the specified license.
    >
    > /EXCLUDE=(node-name[,node-name,...])
    > Any node other than the listed node(s) can access the specified
    > license.
    >
    >
    > In your 3 node cluster,
    >
    > /INCLUDE=ALPHA
    >
    > Would be exactly the same as
    >
    > /EXCLUDE=(BETA,GAMMA)
    >


    But the base license is NO_SHARE, so (on a cluster) can only be
    loaded by a node on the /INCLUDE list, which was initially
    blank. For shareable licenses, I think it works exactly as you
    describe, but for NO_SHARE licenses, /EXLUDE is essentially
    useless.

    From other replies, it sounds like /EXCLUDE didn't help the OP,
    but /INCLUDE fixed the problem.

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  13. Re: Cluster problems - or maybe license problems?

    DanO wrote:
    > The two commands (/INCLUDE and /EXCLUDE) are totally different,
    > and both work EXACTLY as they should:
    >
    > /INCLUDE=(node-name[,node-name,...])
    > Only the listed node(s) can access the specified license.
    >
    > /EXCLUDE=(node-name[,node-name,...])
    > Any node other than the listed node(s) can access the specified
    > license.
    >
    >
    > In your 3 node cluster,
    >
    > /INCLUDE=ALPHA
    >
    > Would be exactly the same as
    >
    > /EXCLUDE=(BETA,GAMMA)
    >


    Except that on booting, the /EXCLUDE=(BETA,GAMMA) produces an error
    message whereas the /INCLUDE=ALPHA works!

+ Reply to Thread