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.

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

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.

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

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

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.

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

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.

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