queue manager and OpenVMS version dependencies - VMS

This is a discussion on queue manager and OpenVMS version dependencies - VMS ; I have a small cluster that I am trying to upgrade. OpenVMS V8.3 is on one node. Another is still running V7.2-2. I cannot start the queue manager on both nodes... only one. The opcom reposts: -RMS-E-FLK, file currently locked ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: queue manager and OpenVMS version dependencies

  1. queue manager and OpenVMS version dependencies

    I have a small cluster that I am trying to upgrade. OpenVMS V8.3 is on
    one node. Another is still running V7.2-2. I cannot start the queue
    manager on both nodes... only one. The opcom reposts:

    -RMS-E-FLK, file currently locked by another user
    -SYSTEM-W-ACCONFLICT, file access conflict
    %JBC-E-QMANDEL, unexpected queue manager process termination

    I vaguely recall some issues and even a patch kit to address some changes
    needed for the queue manager in the past. Can anyone refresh my memory?
    Perhaps point me to the kit. I checked the ITRC site but i can't see to
    locate a pertinent kit.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  2. Re: queue manager and OpenVMS version dependencies

    VAXman- wrote:
    > I have a small cluster that I am trying to upgrade. OpenVMS V8.3 is on
    > one node. Another is still running V7.2-2. I cannot start the queue
    > manager on both nodes... only one. The opcom reposts:
    >
    > -RMS-E-FLK, file currently locked by another user
    > -SYSTEM-W-ACCONFLICT, file access conflict
    > %JBC-E-QMANDEL, unexpected queue manager process termination
    >
    > I vaguely recall some issues and even a patch kit to address some changes
    > needed for the queue manager in the past. Can anyone refresh my memory?
    > Perhaps point me to the kit. I checked the ITRC site but i can't see to
    > locate a pertinent kit.
    >


    I thought that such a cluster was unsupported! Last I heard you could
    have a "one version difference" in a cluster; e.g. some nodes at 8.2 and
    others at 8.3.

    I would think that the fix would be to upgrade the other node to 8.3.


  3. Re: queue manager and OpenVMS version dependencies

    In article <46A26984.9020200@comcast.net>, "Richard B. Gilbert" writes:
    >
    >
    >VAXman- wrote:
    >> I have a small cluster that I am trying to upgrade. OpenVMS V8.3 is on
    >> one node. Another is still running V7.2-2. I cannot start the queue
    >> manager on both nodes... only one. The opcom reposts:
    >>
    >> -RMS-E-FLK, file currently locked by another user
    >> -SYSTEM-W-ACCONFLICT, file access conflict
    >> %JBC-E-QMANDEL, unexpected queue manager process termination
    >>
    >> I vaguely recall some issues and even a patch kit to address some changes
    >> needed for the queue manager in the past. Can anyone refresh my memory?
    >> Perhaps point me to the kit. I checked the ITRC site but i can't see to
    >> locate a pertinent kit.
    >>

    >
    >I thought that such a cluster was unsupported! Last I heard you could
    >have a "one version difference" in a cluster; e.g. some nodes at 8.2 and
    >others at 8.3.
    >
    >I would think that the fix would be to upgrade the other node to 8.3.


    That is the eventual goal; however, one of the nodes is production and
    the other is a test/development node. The idea is to upgrade the test/
    development node, get all of their in-house and third party apps up to
    snuff, and then, and only then, the development node can be updated.
    One of the things needing to be tested and verify as working for them
    is Advanced Server.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  4. Re: queue manager and OpenVMS version dependencies

    VAXman- @SendSpamHere.ORG wrote:
    >>> I have a small cluster that I am trying to upgrade. OpenVMS V8.3 is on
    >>> one node. Another is still running V7.2-2. I cannot start the queue
    >>> manager on both nodes... only one. The opcom reposts:


    Mr VAXMAN,

    When I got my first Alpha and put 8.3 on it, it would not cooperate with
    VAX 7.2 queue manager. Upon upgrading the VAXen to 7.3, they cooperated
    together without the need to apply a patch.

    MONITOR CLUSTER is still broken though.

    And remember that with 7.2 VAX, you cannot mount ODS5 disks. With 7.3
    VAX, you can mount ODS5 disks with some restrictions /caveats.

  5. Re: queue manager and OpenVMS version dependencies

    In article ,
    JF Mezei wrote:

    > When I got my first Alpha and put 8.3 on it, it would not cooperate with
    > VAX 7.2 queue manager. Upon upgrading the VAXen to 7.3, they cooperated
    > together without the need to apply a patch.


    I have no idea if the following will address this problem, but the
    wording says it should be checked anyway. From the V7.3 Release Notes:

    "5.9.5 Remedial Kits Needed for Cluster Compatibility

    V7.3

    Before you introduce an OpenVMS Version 7.3 system into an existing
    OpenVMS Cluster system, you must apply certain remedial kits to your
    systems running earlier versions of OpenVMS."

    http://h71000.www7.hp.com/doc/73fina...#rem_kits_need
    ed_h

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  6. Re: queue manager and OpenVMS version dependencies

    In article , JF Mezei writes:
    >
    >
    >VAXman- @SendSpamHere.ORG wrote:
    >>>> I have a small cluster that I am trying to upgrade. OpenVMS V8.3 is on
    >>>> one node. Another is still running V7.2-2. I cannot start the queue
    >>>> manager on both nodes... only one. The opcom reposts:

    >
    >Mr VAXMAN,
    >
    >When I got my first Alpha and put 8.3 on it, it would not cooperate with
    >VAX 7.2 queue manager. Upon upgrading the VAXen to 7.3, they cooperated
    >together without the need to apply a patch.


    This particular cluster is all Alpha; no VAX.


    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  7. Re: queue manager and OpenVMS version dependencies

    VAXman,

    the QUEUE_MANAGER process is only allowed to run on ONE node at a
    time, when sharing the queue manager database between multiple nodes
    within a cluster.

    You coordiate access to the queue manager database by using the SAME
    QMAN$MASTER file for all nodes sharing the queue manager database
    (define a QMAN$MASTER logical in SYLOGICALS.COM and MOUNT the disk
    this file resides on). Then - just once - issue a START/QUE/MANA/
    ON=(node1,node2)/NEW dev:[dir], where dev:[dir] specifies the shared
    disk and directory where to put the queue manager database.

    >From then on, JOB_CONTROL will take care of starting the QUEUE_MANAGER

    process during boot (or failover).

    Volker.


  8. Re: queue manager and OpenVMS version dependencies

    In article <1185102950.810151.305720@q75g2000hsh.googlegroups. com>, Volker Halle writes:
    >
    >
    >VAXman,
    >
    >the QUEUE_MANAGER process is only allowed to run on ONE node at a
    >time, when sharing the queue manager database between multiple nodes
    >within a cluster.
    >
    >You coordiate access to the queue manager database by using the SAME
    >QMAN$MASTER file for all nodes sharing the queue manager database
    >(define a QMAN$MASTER logical in SYLOGICALS.COM and MOUNT the disk
    >this file resides on). Then - just once - issue a START/QUE/MANA/
    >ON=(node1,node2)/NEW dev:[dir], where dev:[dir] specifies the shared
    >disk and directory where to put the queue manager database.


    Not... turned out to be a queue on the first node that was stuck in a
    perpetual starting state. The queue was no longered needed so it was
    deleted. I now have the queue manager started on both nodes.


    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  9. Re: queue manager and OpenVMS version dependencies

    On Jul 22, 7:34 pm, VAXman- @SendSpamHere.ORG wrote:
    > In article <1185102950.810151.305...@q75g2000hsh.googlegroups. com>, Volker Halle writes:
    >
    >
    >
    > >VAXman,

    >
    > >the QUEUE_MANAGER process is only allowed to run on ONE node at a
    > >time, when sharing the queue manager database between multiple nodes
    > >within a cluster.

    >
    > >You coordiate access to the queue manager database by using the SAME
    > >QMAN$MASTER file for all nodes sharing the queue manager database
    > >(define a QMAN$MASTER logical in SYLOGICALS.COM and MOUNT the disk
    > >this file resides on). Then - just once - issue a START/QUE/MANA/
    > >ON=(node1,node2)/NEW dev:[dir], where dev:[dir] specifies the shared
    > >disk and directory where to put the queue manager database.

    >
    > Not... turned out to be a queue on the first node that was stuck in a
    > perpetual starting state. The queue was no longered needed so it was
    > deleted. I now have the queue manager started on both nodes.
    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >
    > "Well my son, life is like a beanstalk, isn't it?"
    >
    > http://tmesis.com/drat.html



    isn't it possible to run multiple queue manager on a cluster, each
    with its own name ?

    Pierre.


  10. Re: queue manager and OpenVMS version dependencies

    In article <1185131334.347341.224720@r34g2000hsd.googlegroups. com>, Pierre writes:
    >
    >
    >On Jul 22, 7:34 pm, VAXman- @SendSpamHere.ORG wrote:
    >> In article <1185102950.810151.305...@q75g2000hsh.googlegroups. com>, Volker Halle writes:
    >>
    >>
    >>
    >> >VAXman,

    >>
    >> >the QUEUE_MANAGER process is only allowed to run on ONE node at a
    >> >time, when sharing the queue manager database between multiple nodes
    >> >within a cluster.

    >>
    >> >You coordiate access to the queue manager database by using the SAME
    >> >QMAN$MASTER file for all nodes sharing the queue manager database
    >> >(define a QMAN$MASTER logical in SYLOGICALS.COM and MOUNT the disk
    >> >this file resides on). Then - just once - issue a START/QUE/MANA/
    >> >ON=(node1,node2)/NEW dev:[dir], where dev:[dir] specifies the shared
    >> >disk and directory where to put the queue manager database.

    >>
    >> Not... turned out to be a queue on the first node that was stuck in a
    >> perpetual starting state. The queue was no longered needed so it was
    >> deleted. I now have the queue manager started on both nodes.
    >>
    >> --
    >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >>
    >> "Well my son, life is like a beanstalk, isn't it?"
    >>
    >> http://tmesis.com/drat.html

    >
    >
    >isn't it possible to run multiple queue manager on a cluster, each
    >with its own name ?


    Yes... but this is a cluster. The production node has most (all) of the
    queues. The other node is a development/test node which uses the produc-
    tion node's queues.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

+ Reply to Thread