Unsupported three-architecture cluster - VMS

This is a discussion on Unsupported three-architecture cluster - VMS ; First, thanks HP for not properly supporting this as you should have. Makes the current situation just delightful. Customer has a two-node LAN based cluster, Alpha and VAX. No shared storage, all disks are local to one or the other. ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Unsupported three-architecture cluster

  1. Unsupported three-architecture cluster

    First, thanks HP for not properly supporting this as you should have.
    Makes the current situation just delightful.

    Customer has a two-node LAN based cluster, Alpha and VAX. No shared
    storage, all disks are local to one or the other. The Alpha is the
    master node in voting and holds the authoritative SYSUAF, rightslist,
    queue, etc shared files. The VAX keeps a local copy to boot
    standalone or if coming up first to the point of waiting to form a
    cluster.

    They are adding an itanium. They are not removing the VAX. I know
    its not supported but I also know it has worked in testing. Still LAN
    based, still no shared storage.

    The VAX is running the Process Software TCPware stack; the Alpha runs
    the HP stack. Currently the VAX is at VMS V7.3, the Alpha at V8.2,
    and the Itanium at V8.2-1. That is unlikely to change before summer.

    I plan on keeping the Alpha as the 'master' node and keeper of the
    shared files simply because of its excellent track record (actually
    the old VAX has the best uptime but its pretty old/slow (3100-30).
    Performance of the Itanium may make us move to it down the road but I
    want it to run for a while before making it top node.

    I've been refreshing on the cluster manual. Since we already have a
    cluster most of the code needed to set up 'master' files and such is
    in place, just needing tweaking for the new node. I'm also working
    out the PQL parameters for each node.

    Given the huge difference in account quota recommendations between the
    three architectures, and the significant number of shared accounts
    (user, system, tcpip, webserver, etc, most of which are shared between
    either two or three nodes) will they be best served by leaving the UAF
    account quotas at VAX levels and relying on the SYSGEN PQL settings
    for the two newer nodes? That would severely restrict the ability to
    customize account settings on the newer systems (not everyone on the
    Alpha/itanium needs to run Java or Mozilla).

    VAX usage is critical but not a lot of it goes on. PQL parameters
    can't set MAX settings (which would be awfully useful in this
    situation) but perhaps it would be better to use the Alpha as a
    baseline for UAF quotas anyway. The accounts that do need to run Java
    and Mozilla are not the ones generally used on the VAX (and we can
    enforce that if need be) and baseline Alpha quotas do not need to be
    overly large, so perhaps won't cause a problem for the VAX. That at
    least gives us some leeway on the Alpha account quotas, though the
    Itanium accounts will still end up one size fits all using PQL
    parameters.

    Thoughts appreciated. Thoughts about not putting all three
    architectures up in the cluster noted but not helpful.

    Thanks

    Rich

  2. Re: Unsupported three-architecture cluster

    Rich Jordan wrote:
    > Given the huge difference in account quota recommendations between the
    > three architectures, and the significant number of shared accounts
    > (user, system, tcpip, webserver, etc, most of which are shared between



    How much software runs on the vax ?

    In my case, I just upped the SYSUAF to match the alpha requirements. In
    the end, the big changes are with the pgflquota which alpha needs sagan> billions and billions of. On the VAX, you can use
    the sysgen WSMAX to limit working sets to a reasonable limit.

    If you don't have much software running on it, it may be sufficient, and
    just lest the process/memory manager decide how much working set each
    process really deserves.

    Another option would be to have an architecture specific SYSUAF during
    startup that includes only the necessary accounts with that
    architecture's quota, and once startup is complete, you then redirect
    SYSUAF to the shared one where all the usernames are defined. SOftware
    that is started at boot time would get "OK" quotas, but processes
    started after boot would get the exagerated quotas that would be allow
    one to run on any platform.


    Another approach is to look at the actual startup scripts for each
    layered product. Many would provide ways to specify quotas
    because in the end, they dur a RUN/DETACHED and provide the quotas in
    that command line.

  3. Re: Unsupported three-architecture cluster

    Rich Jordan wrote:
    > First, thanks HP for not properly supporting this as you should have.
    > Makes the current situation just delightful.


    > Customer has a two-node LAN based cluster, Alpha and VAX. No shared
    > storage, all disks are local to one or the other. The Alpha is the
    > master node in voting and holds the authoritative SYSUAF, rightslist,
    > queue, etc shared files. The VAX keeps a local copy to boot
    > standalone or if coming up first to the point of waiting to form a
    > cluster.
    >
    > They are adding an itanium. They are not removing the VAX. I know
    > its not supported but I also know it has worked in testing. Still LAN
    > based, still no shared storage.
    >
    > Given the huge difference in account quota recommendations between the
    > three architectures, and the significant number of shared accounts
    > (user, system, tcpip, webserver, etc, most of which are shared between
    > either two or three nodes) will they be best served by leaving the UAF
    > account quotas at VAX levels and relying on the SYSGEN PQL settings
    > for the two newer nodes? That would severely restrict the ability to
    > customize account settings on the newer systems (not everyone on the
    > Alpha/itanium needs to run Java or Mozilla).


    The main issue to consider is are there any applications that will cause
    problems on a specific architecture if they are given higher quotas than
    they currently need.

    In some cases, database and backup programs will adapt to take advantage
    of what ever quotas are available, which means the ones running a VAX
    may change behavior.

    One thing that you probably need to insure is that the sysgen channelcnt
    parameter is higher than the fillm account quota on any account. Some
    software will behave badly if it hit channelcnt before

    Working set extent is tied to sysgen parameter wsmax. You will get the
    lesser of the two. For most VMS systems that I have managed, setting
    wsextent to wsmax has been the norm. Setting wsextent higher than wsmax
    should not cause problems.

    In general, I have really seen no effect in changing wsquota, as long as
    wsextent and wsmax are sufficiently tuned.

    pagefilequota is one that may be greatly different between systems, so
    the PQL parameters may be of use there.

    I have seen the most drastic results from having freelim and freegoal
    too small on systems running VMS 5.4 and earlier.

    You should probably check to see that resources are being used on the
    systems now. If none of them are being limited by their current quotas,
    it is likely that they will not change if those quotas are increased.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  4. Re: Unsupported three-architecture cluster

    On Dec 31, 12:40 pm, JF Mezei wrote:
    > Rich Jordan wrote:
    > > Given the huge difference in account quota recommendations between the
    > > three architectures, and the significant number of shared accounts
    > > (user, system, tcpip, webserver, etc, most of which are shared between

    >
    > How much software runs on the vax ?
    >
    > In my case, I just upped the SYSUAF to match the alpha requirements. In
    > the end, the big changes are with the pgflquota which alpha needs > sagan> billions and billions of. On the VAX, you can use
    > the sysgen WSMAX to limit working sets to a reasonable limit.
    >
    > If you don't have much software running on it, it may be sufficient, and
    > just lest the process/memory manager decide how much working set each
    > process really deserves.
    >
    > Another option would be to have an architecture specific SYSUAF during
    > startup that includes only the necessary accounts with that
    > architecture's quota, and once startup is complete, you then redirect
    > SYSUAF to the shared one where all the usernames are defined. SOftware
    > that is started at boot time would get "OK" quotas, but processes
    > started after boot would get the exagerated quotas that would be allow
    > one to run on any platform.
    >
    > Another approach is to look at the actual startup scripts for each
    > layered product. Many would provide ways to specify quotas
    > because in the end, they dur a RUN/DETACHED and provide the quotas in
    > that command line.


    JF
    its not the startups and processes for same (like TCPIP) I'm
    concerned about; its actual interactive logins. The users run some
    critical (but old) SMG based apps on the VAX. They are not intensive
    (well, they can be somewhat I/O intensive). I don't want those users
    logging on with itanium+java/mozilla level quotas if that can be
    avoided.

    Good point about the time the SYSUAF/rightslist logicals are
    assigned though. The current code does it very early.

    Rich

  5. Re: Unsupported three-architecture cluster

    Rich Jordan wrote:

    > its not the startups and processes for same (like TCPIP) I'm
    > concerned about; its actual interactive logins. The users run some
    > critical (but old) SMG based apps on the VAX. They are not intensive
    > (well, they can be somewhat I/O intensive). I don't want those users
    > logging on with itanium+java/mozilla level quotas if that can be
    > avoided.


    If you limit wsmax on the vax, giving users extraordinary SYSUAF quotas
    may not be so disastrous. Remember that the process/memory manager will
    automatically limit working sets to whatever is available in memory.

    If the users run SMG applications, those apps may not even be aware that
    they have quotas 10 times greater than necessary and thus not abuse the
    system at all.

    The only time quotas become important is with application such as
    Mozilla have that serious memory leaks and they just keep on bunny mode> growing and growing and growing

  6. Re: Unsupported three-architecture cluster

    On Dec 31, 1:18 pm, Rich Jordan wrote:
    > First, thanks HP for not properly supporting this as you should have.
    > Makes the current situation just delightful.
    >
    > Customer has a two-node LAN based cluster, Alpha and VAX. No shared
    > storage, all disks are local to one or the other. The Alpha is the
    > master node in voting and holds the authoritative SYSUAF, rightslist,
    > queue, etc shared files. The VAX keeps a local copy to boot
    > standalone or if coming up first to the point of waiting to form a
    > cluster.
    >
    > They are adding an itanium. They are not removing the VAX. I know
    > its not supported but I also know it has worked in testing. Still LAN
    > based, still no shared storage.
    >
    > The VAX is running the Process Software TCPware stack; the Alpha runs
    > the HP stack. Currently the VAX is at VMS V7.3, the Alpha at V8.2,
    > and the Itanium at V8.2-1. That is unlikely to change before summer.
    >
    > I plan on keeping the Alpha as the 'master' node and keeper of the
    > shared files simply because of its excellent track record (actually
    > the old VAX has the best uptime but its pretty old/slow (3100-30).
    > Performance of the Itanium may make us move to it down the road but I
    > want it to run for a while before making it top node.
    >
    > I've been refreshing on the cluster manual. Since we already have a
    > cluster most of the code needed to set up 'master' files and such is
    > in place, just needing tweaking for the new node. I'm also working
    > out the PQL parameters for each node.
    >
    > Given the huge difference in account quota recommendations between the
    > three architectures, and the significant number of shared accounts
    > (user, system, tcpip, webserver, etc, most of which are shared between
    > either two or three nodes) will they be best served by leaving the UAF
    > account quotas at VAX levels and relying on the SYSGEN PQL settings
    > for the two newer nodes? That would severely restrict the ability to
    > customize account settings on the newer systems (not everyone on the
    > Alpha/itanium needs to run Java or Mozilla).
    >
    > VAX usage is critical but not a lot of it goes on. PQL parameters
    > can't set MAX settings (which would be awfully useful in this
    > situation) but perhaps it would be better to use the Alpha as a
    > baseline for UAF quotas anyway. The accounts that do need to run Java
    > and Mozilla are not the ones generally used on the VAX (and we can
    > enforce that if need be) and baseline Alpha quotas do not need to be
    > overly large, so perhaps won't cause a problem for the VAX. That at
    > least gives us some leeway on the Alpha account quotas, though the
    > Itanium accounts will still end up one size fits all using PQL
    > parameters.
    >
    > Thoughts appreciated. Thoughts about not putting all three
    > architectures up in the cluster noted but not helpful.
    >
    > Thanks
    >
    > Rich


    Rich,

    Using the PQL settings to set MINIMUM parameters is certainly useful,
    as is looking at whether it is safe to raise parameters such as
    CHANNELCNT on all of the systems.

    For situations where accounts are used, consider the fact that while
    it is normal practice for there to be one Account Name PER UIC, this
    is by no means mandatory. Also note that quotas and related settings
    are by Account Name, not by UIC (Protection, on the other hand IS by
    UIC).

    I would seriously take a look at using different account Names on the
    different nodes for the situations are different. I would consider
    creating a separate (for efficiency reasons) logical name table, not
    in the normal search path, that would store this information. Then
    each reference need only include a reference to the logical name using
    F$TRNLNM.

    Please let me know if I am not sufficiently clear.

    - Bob Gezelter, http://www.rlgsc.com

  7. Re: Unsupported three-architecture cluster

    On Dec 31, 1:28 pm, Bob Gezelter wrote:
    > On Dec 31, 1:18 pm, Rich Jordan wrote:
    >
    >
    >
    > > First, thanks HP for not properly supporting this as you should have.
    > > Makes the current situation just delightful.

    >
    > > Customer has a two-node LAN based cluster, Alpha and VAX. No shared
    > > storage, all disks are local to one or the other. The Alpha is the
    > > master node in voting and holds the authoritative SYSUAF, rightslist,
    > > queue, etc shared files. The VAX keeps a local copy to boot
    > > standalone or if coming up first to the point of waiting to form a
    > > cluster.

    >
    > > They are adding an itanium. They are not removing the VAX. I know
    > > its not supported but I also know it has worked in testing. Still LAN
    > > based, still no shared storage.

    >
    > > The VAX is running the Process Software TCPware stack; the Alpha runs
    > > the HP stack. Currently the VAX is at VMS V7.3, the Alpha at V8.2,
    > > and the Itanium at V8.2-1. That is unlikely to change before summer.

    >
    > > I plan on keeping the Alpha as the 'master' node and keeper of the
    > > shared files simply because of its excellent track record (actually
    > > the old VAX has the best uptime but its pretty old/slow (3100-30).
    > > Performance of the Itanium may make us move to it down the road but I
    > > want it to run for a while before making it top node.

    >
    > > I've been refreshing on the cluster manual. Since we already have a
    > > cluster most of the code needed to set up 'master' files and such is
    > > in place, just needing tweaking for the new node. I'm also working
    > > out the PQL parameters for each node.

    >
    > > Given the huge difference in account quota recommendations between the
    > > three architectures, and the significant number of shared accounts
    > > (user, system, tcpip, webserver, etc, most of which are shared between
    > > either two or three nodes) will they be best served by leaving the UAF
    > > account quotas at VAX levels and relying on the SYSGEN PQL settings
    > > for the two newer nodes? That would severely restrict the ability to
    > > customize account settings on the newer systems (not everyone on the
    > > Alpha/itanium needs to run Java or Mozilla).

    >
    > > VAX usage is critical but not a lot of it goes on. PQL parameters
    > > can't set MAX settings (which would be awfully useful in this
    > > situation) but perhaps it would be better to use the Alpha as a
    > > baseline for UAF quotas anyway. The accounts that do need to run Java
    > > and Mozilla are not the ones generally used on the VAX (and we can
    > > enforce that if need be) and baseline Alpha quotas do not need to be
    > > overly large, so perhaps won't cause a problem for the VAX. That at
    > > least gives us some leeway on the Alpha account quotas, though the
    > > Itanium accounts will still end up one size fits all using PQL
    > > parameters.

    >
    > > Thoughts appreciated. Thoughts about not putting all three
    > > architectures up in the cluster noted but not helpful.

    >
    > > Thanks

    >
    > > Rich

    >
    > Rich,
    >
    > Using the PQL settings to set MINIMUM parameters is certainly useful,
    > as is looking at whether it is safe to raise parameters such as
    > CHANNELCNT on all of the systems.
    >
    > For situations where accounts are used, consider the fact that while
    > it is normal practice for there to be one Account Name PER UIC, this
    > is by no means mandatory. Also note that quotas and related settings
    > are by Account Name, not by UIC (Protection, on the other hand IS by
    > UIC).
    >
    > I would seriously take a look at using different account Names on the
    > different nodes for the situations are different. I would consider
    > creating a separate (for efficiency reasons) logical name table, not
    > in the normal search path, that would store this information. Then
    > each reference need only include a reference to the logical name using
    > F$TRNLNM.
    >
    > Please let me know if I am not sufficiently clear.
    >
    > - Bob Gezelter,http://www.rlgsc.com


    Bob,
    I'm afraid the customer will insist on a single username across
    the cluster. They won't want to maintain multiple passwords in any
    case which is why we're aiming at a single SYSUAF file.

    Thanks for the input!

    Rich

  8. Re: Unsupported three-architecture cluster

    Bob Gezelter wrote:
    >
    > For situations where accounts are used, consider the fact that while
    > it is normal practice for there to be one Account Name PER UIC, this
    > is by no means mandatory. Also note that quotas and related settings
    > are by Account Name, not by UIC (Protection, on the other hand IS by
    > UIC).


    The C Runtime, and many programs ported from UNIX effectively require a
    one to one relationship between account names and UICs.

    This is because they use the ID to NAME lookup system service to convert
    a UID/UIC to a username, and then use the username to look up the
    account details using the sys$getuai calls.

    This is because there is no documented or supported API to return all
    the usernames in the SYSUAF that have a given UIC.

    If the name on the identifier for a UIC does not exist in the UAF, then
    many programs written in C will fail.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  9. Re: Unsupported three-architecture cluster

    Rich Jordan wrote in news:fb222d9d-040d-4170-8280-
    eed7202d25f8@v4g2000hsf.googlegroups.com:

    [..snip..]

    > The VAX is running the Process Software TCPware stack; the Alpha runs
    > the HP stack. Currently the VAX is at VMS V7.3, the Alpha at V8.2,
    > and the Itanium at V8.2-1. That is unlikely to change before summer.
    >
    > I plan on keeping the Alpha as the 'master' node and keeper of the
    > shared files simply because of its excellent track record (actually
    > the old VAX has the best uptime but its pretty old/slow (3100-30).
    > Performance of the Itanium may make us move to it down the road but I
    > want it to run for a while before making it top node.
    >


    Since this MicroVAX is so important, why not recommend moving to a 3100-95?
    If a move is even made to a 3100-80, I think Nemonix Engineering will sell
    upgrades to the system allowing a lot more memory, a faster processor, 100
    megabit network interface and ultraSCSI for disk I/O. All this might cost
    more than another Itanium, but it is quite the performance leap.

    [..snip..]

    > Thoughts appreciated. Thoughts about not putting all three
    > architectures up in the cluster noted but not helpful.
    >
    > Thanks
    >
    > Rich



  10. Re: Unsupported three-architecture cluster

    On Dec 31 2007, 5:12 pm, Rich Jordan wrote:
    > On Dec 31, 1:28 pm, Bob Gezelter wrote:
    >
    >
    >
    > > On Dec 31, 1:18 pm, Rich Jordan wrote:

    >
    > > > First, thanks HP for not properly supporting this as you should have.
    > > > Makes the current situation just delightful.

    >
    > > > Customer has a two-node LAN based cluster, Alpha and VAX. No shared
    > > > storage, all disks are local to one or the other. The Alpha is the
    > > > master node in voting and holds the authoritative SYSUAF, rightslist,
    > > > queue, etc shared files. The VAX keeps a local copy to boot
    > > > standalone or if coming up first to the point of waiting to form a
    > > > cluster.

    >
    > > > They are adding an itanium. They are not removing the VAX. I know
    > > > its not supported but I also know it has worked in testing. Still LAN
    > > > based, still no shared storage.

    >
    > > > The VAX is running the Process Software TCPware stack; the Alpha runs
    > > > the HP stack. Currently the VAX is at VMS V7.3, the Alpha at V8.2,
    > > > and the Itanium at V8.2-1. That is unlikely to change before summer.

    >
    > > > I plan on keeping the Alpha as the 'master' node and keeper of the
    > > > shared files simply because of its excellent track record (actually
    > > > the old VAX has the best uptime but its pretty old/slow (3100-30).
    > > > Performance of the Itanium may make us move to it down the road but I
    > > > want it to run for a while before making it top node.

    >
    > > > I've been refreshing on the cluster manual. Since we already have a
    > > > cluster most of the code needed to set up 'master' files and such is
    > > > in place, just needing tweaking for the new node. I'm also working
    > > > out the PQL parameters for each node.

    >
    > > > Given the huge difference in account quota recommendations between the
    > > > three architectures, and the significant number of shared accounts
    > > > (user, system, tcpip, webserver, etc, most of which are shared between
    > > > either two or three nodes) will they be best served by leaving the UAF
    > > > account quotas at VAX levels and relying on the SYSGEN PQL settings
    > > > for the two newer nodes? That would severely restrict the ability to
    > > > customize account settings on the newer systems (not everyone on the
    > > > Alpha/itanium needs to run Java or Mozilla).

    >
    > > > VAX usage is critical but not a lot of it goes on. PQL parameters
    > > > can't set MAX settings (which would be awfully useful in this
    > > > situation) but perhaps it would be better to use the Alpha as a
    > > > baseline for UAF quotas anyway. The accounts that do need to run Java
    > > > and Mozilla are not the ones generally used on the VAX (and we can
    > > > enforce that if need be) and baseline Alpha quotas do not need to be
    > > > overly large, so perhaps won't cause a problem for the VAX. That at
    > > > least gives us some leeway on the Alpha account quotas, though the
    > > > Itanium accounts will still end up one size fits all using PQL
    > > > parameters.

    >
    > > > Thoughts appreciated. Thoughts about not putting all three
    > > > architectures up in the cluster noted but not helpful.

    >
    > > > Thanks

    >
    > > > Rich

    >
    > > Rich,

    >
    > > Using the PQL settings to set MINIMUM parameters is certainly useful,
    > > as is looking at whether it is safe to raise parameters such as
    > > CHANNELCNT on all of the systems.

    >
    > > For situations where accounts are used, consider the fact that while
    > > it is normal practice for there to be one Account Name PER UIC, this
    > > is by no means mandatory. Also note that quotas and related settings
    > > are by Account Name, not by UIC (Protection, on the other hand IS by
    > > UIC).

    >
    > > I would seriously take a look at using different account Names on the
    > > different nodes for the situations are different. I would consider
    > > creating a separate (for efficiency reasons) logical name table, not
    > > in the normal search path, that would store this information. Then
    > > each reference need only include a reference to the logical name using
    > > F$TRNLNM.

    >
    > > Please let me know if I am not sufficiently clear.

    >
    > > - Bob Gezelter,http://www.rlgsc.com

    >
    > Bob,
    > I'm afraid the customer will insist on a single username across
    > the cluster. They won't want to maintain multiple passwords in any
    > case which is why we're aiming at a single SYSUAF file.
    >
    > Thanks for the input!
    >
    > Rich


    Rich,

    The user accounts are a different story. My solution, which I have
    used for various situations, was targeted at the "... significant
    number of shared accounts (user, system, tcpip, webserver, etc, most
    of which are shared between either two or three nodes) ..."

    Often, these processes and jobs using these accounts are initiated
    using SUBMIT/USER or RUN with explicit parameters.

    - Bob Gezelter, http://www.rlgsc.com

  11. Re: Unsupported three-architecture cluster

    I would even take this a step further and suggest running a VAX
    emulator on either of the other systems, freeing up the VAX hardware
    related dependencies.


    Sean

    On Dec 31 2007, 10:40*pm, Tad Winters
    wrote:
    > Rich Jordan wrote in news:fb222d9d-040d-4170-8280-
    > eed7202d2...@v4g2000hsf.googlegroups.com:
    >
    > *[..snip..]
    >
    > > The VAX is running the Process Software TCPware stack; the Alpha runs
    > > the HP stack. *Currently the VAX is at VMS V7.3, the Alpha at V8.2,
    > > and the Itanium at V8.2-1. *That is unlikely to change before summer.

    >
    > > I plan on keeping the Alpha as the 'master' node and keeper of the
    > > shared files simply because of its excellent track record (actually
    > > the old VAX has the best uptime but its pretty old/slow (3100-30).
    > > Performance of the Itanium may make us move to it down the road but I
    > > want it to run for a while before making it top node.

    >
    > Since this MicroVAX is so important, why not recommend moving to a 3100-95? *
    > If a move is even made to a 3100-80, I think Nemonix Engineering will sell
    > upgrades to the system allowing a lot more memory, a faster processor, 100
    > megabit network interface and ultraSCSI for disk I/O. *All this might cost
    > more than another Itanium, but it is quite the performance leap.
    >
    > *[..snip..]
    >
    >
    >
    > > Thoughts appreciated. *Thoughts about not putting all three
    > > architectures up in the cluster noted but not helpful.

    >
    > > Thanks

    >
    > > Rich- Hide quoted text -

    >
    > - Show quoted text -



  12. Re: Unsupported three-architecture cluster

    On 31 Dec 2007, 22:12, Rich Jordan wrote:
    > On Dec 31, 1:28 pm, Bob Gezelter wrote:
    >
    >
    >
    >
    >
    > > On Dec 31, 1:18 pm, Rich Jordan wrote:

    >
    > > > First, thanks HP for not properly supporting this as you should have.
    > > > Makes the current situation just delightful.

    >
    > > > Customer has a two-node LAN based cluster, Alpha and VAX. *No shared
    > > > storage, all disks are local to one or the other. *The Alpha is the
    > > > master node in voting and holds the authoritative SYSUAF, rightslist,
    > > > queue, etc shared files. *The VAX keeps a local copy to boot
    > > > standalone or if coming up first to the point of waiting to form a
    > > > cluster.

    >
    > > > They are adding an itanium. *They are not removing the VAX. *I know
    > > > its not supported but I also know it has worked in testing. *Still LAN
    > > > based, still no shared storage.

    >
    > > > The VAX is running the Process Software TCPware stack; the Alpha runs
    > > > the HP stack. *Currently the VAX is at VMS V7.3, the Alpha at V8.2,
    > > > and the Itanium at V8.2-1. *That is unlikely to change before summer..

    >
    > > > I plan on keeping the Alpha as the 'master' node and keeper of the
    > > > shared files simply because of its excellent track record (actually
    > > > the old VAX has the best uptime but its pretty old/slow (3100-30).
    > > > Performance of the Itanium may make us move to it down the road but I
    > > > want it to run for a while before making it top node.

    >
    > > > I've been refreshing on the cluster manual. *Since we already have a
    > > > cluster most of the code needed to set up 'master' files and such is
    > > > in place, just needing tweaking for the new node. *I'm also working
    > > > out the PQL parameters for each node.

    >
    > > > Given the huge difference in account quota recommendations between the
    > > > three architectures, and the significant number of shared accounts
    > > > (user, system, tcpip, webserver, etc, most of which are shared between
    > > > either two or three nodes) will they be best served by leaving the UAF
    > > > account quotas at VAX levels and relying on the SYSGEN PQL settings
    > > > for the two newer nodes? *That would severely restrict the ability to
    > > > customize account settings on the newer systems (not everyone on the
    > > > Alpha/itanium needs to run Java or Mozilla).

    >
    > > > VAX usage is critical but not a lot of it goes on. *PQL parameters
    > > > can't set MAX settings (which would be awfully useful in this
    > > > situation) but perhaps it would be better to use the Alpha as a
    > > > baseline for UAF quotas anyway. *The accounts that do need to run Java
    > > > and Mozilla are not the ones generally used on the VAX (and we can
    > > > enforce that if need be) and baseline Alpha quotas do not need to be
    > > > overly large, so perhaps won't cause a problem for the VAX. *That at
    > > > least gives us some leeway on the Alpha account quotas, though the
    > > > Itanium accounts will still end up one size fits all using PQL
    > > > parameters.

    >
    > > > Thoughts appreciated. *Thoughts about not putting all three
    > > > architectures up in the cluster noted but not helpful.

    >
    > > > Thanks

    >
    > > > Rich

    >
    > > Rich,

    >
    > > Using the PQL settings to set MINIMUM parameters is certainly useful,
    > > as is looking at whether it is safe to raise parameters such as
    > > CHANNELCNT on all of the systems.

    >
    > > For situations where accounts are used, consider the fact that while
    > > it is normal practice for there to be one Account Name PER UIC, this
    > > is by no means mandatory. Also note that quotas and related settings
    > > are by Account Name, not by UIC (Protection, on the other hand IS by
    > > UIC).

    >
    > > I would seriously take a look at using different account Names on the
    > > different nodes for the situations are different. I would consider
    > > creating a separate (for efficiency reasons) logical name table, not
    > > in the normal search path, that would store this information. Then
    > > each reference need only include a reference to the logical name using
    > > F$TRNLNM.

    >
    > > Please let me know if I am not sufficiently clear.

    >
    > > - Bob Gezelter,http://www.rlgsc.com

    >
    > Bob,
    > * * I'm afraid the customer will insist on a single username across
    > the cluster. *They won't want to maintain multiple passwords in any
    > case which is why we're aiming at a single SYSUAF file.
    >
    > * * *Thanks for the input!
    >
    > Rich- Hide quoted text -
    >
    > - Show quoted text -


    Why not consider a combination of the two - have the same usernames
    doing the initial login but, if the system is a VAX then use a proxy
    login using TCP/IP that magically switches to another VAX-specific
    username with lower quotas? that provides the best of both worlds.
    A similar approach could use a SET HOST 0 though DECnet would need to
    prompt for a password on the VAX-specific login.

+ Reply to Thread