MONITOR with different architectures - VMS

This is a discussion on MONITOR with different architectures - VMS ; JF has been complaining that MONITOR CLUSTER doesn't work between the latest VAX and the latest ALPHA. I've seen the same between ALPHA and Itanium. In each of these cases, does it not work in general, are patches missing or ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: MONITOR with different architectures

  1. MONITOR with different architectures

    JF has been complaining that MONITOR CLUSTER doesn't work between the
    latest VAX and the latest ALPHA. I've seen the same between ALPHA and
    Itanium. In each of these cases, does it not work in general, are
    patches missing or does it "just depend"?


  2. RE: MONITOR with different architectures


    > -----Original Message-----
    > From: Phillip Helbig---remove CLOTHES to reply
    > [mailto:helbig@astro.multiCLOTHESvax.de]
    > Sent: August 29, 2007 7:48 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: MONITOR with different architectures
    >
    > JF has been complaining that MONITOR CLUSTER doesn't work between the
    > latest VAX and the latest ALPHA. I've seen the same between ALPHA and
    > Itanium. In each of these cases, does it not work in general, are
    > patches missing or does it "just depend"?


    While I have not tried monitor cluster with VMS V8.3 (my local V8.3 systemsare still
    standalone systems), when ever there is an issue reported with this command, the issue
    is often linked to a set-up issue.

    Fwiw, with OpenVMS Alpha V7.3-2, I setup a VAX, Integrity V8.2 and VAX V7.3cluster and
    The Monitor command worked fine. I even saved the screen shot to a PPT filefor
    presentations.

    Reference:
    http://h71000.www7.hp.com/wizard/wiz_8333.html (ask the wizard)
    http://h71000.www7.hp.com/wizard/wiz_8029.html (see vpm$startup.com)
    http://h71000.www7.hp.com/DOC/82FINA...48pro_044.html

    Issues I have seen include:
    - miss-matched passwords on accounts used for VPM inter system communication.
    - incorrectly defined VPM objects

    Note that you can establish a VPM log file for troubleshooting this error. See above
    links.

    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.




  3. Re: MONITOR with different architectures

    I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR
    server on remote node is an incompatible version) on a cluster
    consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR
    CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3
    nodes. If I try on the Alpha V7.3-2 node I also get
    the same error reported for the V8.3 nodes.


  4. Re: MONITOR with different architectures


    "IanMiller" wrote in message
    news:1188391833.245566.242860@d55g2000hsg.googlegr oups.com...
    >I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR
    > server on remote node is an incompatible version) on a cluster
    > consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR
    > CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3
    > nodes. If I try on the Alpha V7.3-2 node I also get
    > the same error reported for the V8.3 nodes.
    >


    I noted this in another non-monitor thread. I'll repost it in case it was
    missed:

    I upgraded to Alpha V8.2 last fall and ran into compatibility issues with
    MONITOR CLUSTER and VAX V7.3. I opened a call and received new VAX MONITOR
    images to fix MONITOR CLUSTER within a couple of months. Looking at the
    backup saveset I received, there are MONITOR/VPM fixes for VAX V7.3, Alpha
    V7.3-2/V8.3 and Itanium V8.3.

    I haven't seen these images available in a downloadable patch, but you
    should be able to get them from the Support Center.


    Specifically, this corrected the SRVMISMATCH mentioned above.

    -Jeff



  5. Re: MONITOR with different architectures

    On Wed, 29 Aug 2007 06:11:17 -0700, Jeff Goodwin
    wrote:

    >
    > "IanMiller" wrote in message
    > news:1188391833.245566.242860@d55g2000hsg.googlegr oups.com...
    >> I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR
    >> server on remote node is an incompatible version) on a cluster
    >> consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR
    >> CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3
    >> nodes. If I try on the Alpha V7.3-2 node I also get
    >> the same error reported for the V8.3 nodes.
    >>

    >
    > I noted this in another non-monitor thread. I'll repost it in case it
    > was
    > missed:
    >
    > I upgraded to Alpha V8.2 last fall and ran into compatibility issues with
    > MONITOR CLUSTER and VAX V7.3. I opened a call and received new VAX
    > MONITOR
    > images to fix MONITOR CLUSTER within a couple of months. Looking at the
    > backup saveset I received, there are MONITOR/VPM fixes for VAX V7.3,
    > Alpha
    > V7.3-2/V8.3 and Itanium V8.3.
    >
    > I haven't seen these images available in a downloadable patch, but you
    > should be able to get them from the Support Center.
    >
    >
    > Specifically, this corrected the SRVMISMATCH mentioned above.
    >
    > -Jeff
    >

    Jeff, could you please post the header from anal/image?



    --
    PL/I for OpenVMS
    www.kednos.com

  6. Re: MONITOR with different architectures

    Jeff Goodwin wrote:
    > I haven't seen these images available in a downloadable patch, but you
    > should be able to get them from the Support Center.


    So, that explains to total lack of action on HP's part. The patch is
    there, fixed and ready, but not being widely deployed.

    Considering that full interopability between 7.3 and 8.3 is specified in
    the SPD, I would have thought that HP would have posted that patch on
    the patch download area to remedy this very visible non-confirmance with
    the SPD.

  7. Re: MONITOR with different architectures


    "Tom Linden" wrote in message
    newsp.txtsaiolhv4qyg@murphus.linden...
    > On Wed, 29 Aug 2007 06:11:17 -0700, Jeff Goodwin
    > wrote:
    >
    >>
    >> "IanMiller" wrote in message
    >> news:1188391833.245566.242860@d55g2000hsg.googlegr oups.com...
    >>> I get a incompatable version error (MONITOR-E-SRVMISMATCH, MONITOR
    >>> server on remote node is an incompatible version) on a cluster
    >>> consisting of Alpha V8.3, V7.3-2, VAX V7.3, I64 V8.3 if I do MONITOR
    >>> CLUSTER on either of the V8.3 nodes. I see only the data for the V8.3
    >>> nodes. If I try on the Alpha V7.3-2 node I also get
    >>> the same error reported for the V8.3 nodes.
    >>>

    >>
    >> I noted this in another non-monitor thread. I'll repost it in case it
    >> was
    >> missed:
    >>
    >> I upgraded to Alpha V8.2 last fall and ran into compatibility issues with
    >> MONITOR CLUSTER and VAX V7.3. I opened a call and received new VAX
    >> MONITOR
    >> images to fix MONITOR CLUSTER within a couple of months. Looking at the
    >> backup saveset I received, there are MONITOR/VPM fixes for VAX V7.3,
    >> Alpha
    >> V7.3-2/V8.3 and Itanium V8.3.
    >>
    >> I haven't seen these images available in a downloadable patch, but you
    >> should be able to get them from the Support Center.
    >>
    >>
    >> Specifically, this corrected the SRVMISMATCH mentioned above.
    >>
    >> -Jeff
    >>

    > Jeff, could you please post the header from anal/image?
    >
    >


    Ident, etc are the same as the image was patched. Here's the patch date
    from the header:

    last patch date/time: 27-FEB-2007 19:09:40.64

    >
    > --
    > PL/I for OpenVMS
    > www.kednos.com




  8. Re: MONITOR with different architectures

    In article <62991$46d59568$cef8887a$24740@TEKSAVVY.COM>, JF Mezei
    writes:

    > Jeff Goodwin wrote:
    > > I haven't seen these images available in a downloadable patch, but you
    > > should be able to get them from the Support Center.

    >
    > So, that explains to total lack of action on HP's part. The patch is
    > there, fixed and ready, but not being widely deployed.
    >
    > Considering that full interopability between 7.3 and 8.3 is specified in
    > the SPD, I would have thought that HP would have posted that patch on
    > the patch download area to remedy this very visible non-confirmance with
    > the SPD.


    Surely the patch maintainer is reading this thread and the patch will be
    up within 24 hours?


  9. Re: MONITOR with different architectures

    In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    > In article <62991$46d59568$cef8887a$24740@TEKSAVVY.COM>, JF Mezei
    > writes:
    >
    >> Jeff Goodwin wrote:
    >> > I haven't seen these images available in a downloadable patch, but you
    >> > should be able to get them from the Support Center.

    >>
    >> So, that explains to total lack of action on HP's part. The patch is
    >> there, fixed and ready, but not being widely deployed.
    >>
    >> Considering that full interopability between 7.3 and 8.3 is specified in
    >> the SPD, I would have thought that HP would have posted that patch on
    >> the patch download area to remedy this very visible non-confirmance with
    >> the SPD.

    >
    > Surely the patch maintainer is reading this thread and the patch will be
    > up within 24 hours?


    What is the basis for your confidence that:

    1. The patch has been fully tested in all configurations

    2. The patch does not have some theoretical drawback known
    through methods other than testing

    3. The patch is not tied up with some other patches to the
    same image(s) with the above two problems

    4. The patch maintainer has not given up on comp.os.vms due
    to all the vitriol ?

  10. Re: MONITOR with different architectures

    On 08/30/07 06:14, Larry Kilgallen wrote:
    > In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >> In article <62991$46d59568$cef8887a$24740@TEKSAVVY.COM>, JF Mezei
    >> writes:
    >>
    >>> Jeff Goodwin wrote:
    >>>> I haven't seen these images available in a downloadable patch, but you
    >>>> should be able to get them from the Support Center.
    >>> So, that explains to total lack of action on HP's part. The patch is
    >>> there, fixed and ready, but not being widely deployed.
    >>>
    >>> Considering that full interopability between 7.3 and 8.3 is specified in
    >>> the SPD, I would have thought that HP would have posted that patch on
    >>> the patch download area to remedy this very visible non-confirmance with
    >>> the SPD.

    >> Surely the patch maintainer is reading this thread and the patch will be
    >> up within 24 hours?

    >
    > What is the basis for your confidence that:
    >
    > 1. The patch has been fully tested in all configurations
    >
    > 2. The patch does not have some theoretical drawback known
    > through methods other than testing
    >
    > 3. The patch is not tied up with some other patches to the
    > same image(s) with the above two problems
    >
    > 4. The patch maintainer has not given up on comp.os.vms due
    > to all the vitriol ?


    Boob-like faith in HP's innate goodness and competence?

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  11. Re: MONITOR with different architectures

    In article <34zBi.222977$BX3.127235@newsfe13.lga>, Ron Johnson writes:
    > On 08/30/07 06:14, Larry Kilgallen wrote:


    >> What is the basis for your confidence that:


    >> 4. The patch maintainer has not given up on comp.os.vms due
    >> to all the vitriol ?

    >
    > Boob-like faith in HP's innate goodness and competence?


    If HP is good and competent they will be working on real problems
    submitted by supported customers, rather than ewasting time on
    comp.os.vms.

  12. Re: MONITOR with different architectures

    >> Surely the patch maintainer is reading this thread and the patch will be
    >> up within 24 hours?



    1- The engineers would have known, at the time 8.3 came out, that they
    had put code in Monitor to prevent interoperability with Vax. By that
    time, it seemed pretty clear that the "roadmap" promise of an 8.* for
    VAX wasn't going to come, so they would have known that interoperability
    with VAX 7.3 was on the SPD.

    2- So, they release 8.3 anyways with a broken Monitor and non-adherance
    to SPDs. And they remained silent on the whole thing. We find out a
    secret patch was made available in february 2007.

    3- Compare this with an OS such as Linux where such a huge bug would not
    be tolerated and would be fixed very rapidly and the patch made very
    public. The real story here is that VMS engineering no longer has the
    resources to provide a proper , tested, patch for an important component
    of the OS that was released broken. And VMS management are perfectly
    happy to decided to not publically release the patch when it finally is
    made.

    As a hobbyist, I cannot complain. But the way this is handled certaintly
    doesn't give me confidence that VMS management still has access to
    enough engineering resources to fix problems in a timely fashion. They
    would rather hide them under a rug. I have yet to hear about whether the
    VMS version of Bind 8 (VAX) is immune from all the vulnerabilities that
    have been made public over the years.

    The does not do much good to the confidence level that VMS is still
    actively being developped.

  13. Re: MONITOR with different architectures

    Larry Kilgallen wrote:

    > If HP is good and competent they will be working on real problems
    > submitted by supported customers, rather than ewasting time on
    > comp.os.vms.



    My unfortunate experience with LD driver wiping off 25% of my files
    resulted in the now independant engineer fixing it, and perhaps warning
    real customers not to use LD driver in bound volume sets, preventing
    disasters at paying customers.

    Waste of time you say ?

    Hobbyists tend to be early adopters and they will spot problems often
    before paying customers get hit by them. Listening to hobbyists would
    make a lot of sense.

  14. RE: MONITOR with different architectures

    > -----Original Message-----
    > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca]
    > Sent: August 30, 2007 12:05 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: MONITOR with different architectures
    >
    > >> Surely the patch maintainer is reading this thread and the patch

    > will be
    > >> up within 24 hours?

    >
    >
    > 1- The engineers would have known, at the time 8.3 came out, that they
    > had put code in Monitor to prevent interoperability with Vax. By that
    > time, it seemed pretty clear that the "roadmap" promise of an 8.* for
    > VAX wasn't going to come, so they would have known that
    > interoperability
    > with VAX 7.3 was on the SPD.
    >


    Wow, better duck, here come the black helicopters again ....

    > 2- So, they release 8.3 anyways with a broken Monitor and non-adherance
    > to SPDs. And they remained silent on the whole thing. We find out a
    > secret patch was made available in february 2007.
    >


    You seem to be under the impression that all patches are and/or should be released to
    the public.

    Every vendor has both public patches and private patches that are availableunder certain
    Conditions to Customers who actually pay for support. Same goes for Microsoft, Red Hat,
    IBM, Sun etc. its not a matter of being secretive, but in being cautious asthe patch
    may not have gone through all of the rigorous testing that a public patch does.

    Once a fix has been sufficiently qualified, then it *may* be incorporated into a public
    fix or if the impact is minimal, then it may be just incorporated into the next release
    cycle.

    All the SW/OS/ISV vendors take this approach.

    > 3- Compare this with an OS such as Linux where such a huge bug would
    > not
    > be tolerated and would be fixed very rapidly and the patch made very
    > public.


    Do you naively think Red Hat releases all of their patches to their public web sites?
    Of course they have private "paying support" Cust patches as well.

    Huge bug? I don't know the specifics of this issue, but I would hardly classify this as
    a "huge" bug since you can always do a monitor cluster or monitor system from each node
    to see that nodes information.

    > The real story here is that VMS engineering no longer has the
    > resources to provide a proper , tested, patch for an important
    > component
    > of the OS that was released broken. And VMS management are perfectly
    > happy to decided to not publically release the patch when it finally is
    > made.
    >


    Here come more of the helicopters now ...

    > As a hobbyist, I cannot complain. But the way this is handled
    > certaintly
    > doesn't give me confidence that VMS management still has access to
    > enough engineering resources to fix problems in a timely fashion. They
    > would rather hide them under a rug. I have yet to hear about whether
    > the
    > VMS version of Bind 8 (VAX) is immune from all the vulnerabilities that
    > have been made public over the years.
    >
    > The does not do much good to the confidence level that VMS is still
    > actively being developed.


    The public and private patch processes have been around for many moons - likely
    dating back to V1 of OpenVMS.

    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.




  15. Re: MONITOR with different architectures

    Main, Kerry wrote:
    > You seem to be under the impression that all patches are and/or should be released to
    > the public.


    When it comes to non conformance to the SPD, I would say so.


    > Once a fix has been sufficiently qualified, then it *may* be incorporated into a public
    > fix or if the impact is minimal, then it may be just incorporated into the next release
    > cycle.


    There is no "next release cycle" for VAX-VMS. So a Patch is the only way
    to make this work and conform to SPD.


    > Huge bug? I don't know the specifics of this issue, but I would hardly classify this as
    > a "huge" bug since you can always do a monitor cluster or monitor system from each node
    > to see that nodes information.


    Then HP should modify the SPDs to include MONITOR CLUSTER as part of the
    features with limited inteoperability (similar to ODS-5 which has
    limited operability with VAX 7.3 nodes).

  16. Re: MONITOR with different architectures

    On 08/30/07 13:27, Main, Kerry wrote:
    [snip]
    >
    > Do you naively think Red Hat releases all of their patches to their public web sites?


    Big Red Flag that you know *squat* about the GPL and how the Linux
    universe (I despise the word "community").

    RH *must* release their patches (to any GPL or LGPL code that they
    fix) to anyone that they distribute their software to. And that
    means it percolates out to the rest of the world.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  17. Re: MONITOR with different architectures

    Rest assured that my fix for this issue has been applied to the masterpack
    in VMS engineering so that future VMS versions after V8.3 have the fix.

    Jur.


    JF Mezei wrote:
    > Larry Kilgallen wrote:
    >
    >> If HP is good and competent they will be working on real problems
    >> submitted by supported customers, rather than ewasting time on
    >> comp.os.vms.

    >
    >
    > My unfortunate experience with LD driver wiping off 25% of my files
    > resulted in the now independant engineer fixing it, and perhaps warning
    > real customers not to use LD driver in bound volume sets, preventing
    > disasters at paying customers.
    >
    > Waste of time you say ?
    >
    > Hobbyists tend to be early adopters and they will spot problems often
    > before paying customers get hit by them. Listening to hobbyists would
    > make a lot of sense.


  18. Re: MONITOR with different architectures

    In article <3QGx2DOob4Cv@eisner.encompasserve.org>,
    Kilgallen@SpamCop.net (Larry Kilgallen) writes:

    > > Surely the patch maintainer is reading this thread and the patch will be
    > > up within 24 hours?

    >
    > What is the basis for your confidence that:
    >
    > 1. The patch has been fully tested in all configurations


    The problem has been known long enough that there should have been
    enough time.

    > 2. The patch does not have some theoretical drawback known
    > through methods other than testing


    Whatever happened to DEC quality?

    > 3. The patch is not tied up with some other patches to the
    > same image(s) with the above two problems


    Without further evidence, that seems unlikely.

    > 4. The patch maintainer has not given up on comp.os.vms due
    > to all the vitriol ?


    Actually, without the discussion here the patch might never see the
    light of day.


  19. Re: MONITOR with different architectures

    In article ,
    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
    reply) wrote:

    > In article <3QGx2DOob4Cv@eisner.encompasserve.org>,
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >
    > > > Surely the patch maintainer is reading this thread and the patch will be
    > > > up within 24 hours?

    > >
    > > What is the basis for your confidence that:
    > >
    > > 1. The patch has been fully tested in all configurations

    >
    > The problem has been known long enough that there should have been
    > enough time.


    How do you think you know:
    1. What needs to be tested,
    2. How long it should take,
    3. What other work it must be balanced against?

    >
    > > 2. The patch does not have some theoretical drawback known
    > > through methods other than testing

    >
    > Whatever happened to DEC quality?


    Huh? If DEC had known about an incompatibility, do you think they'd
    have shipped it anyway?

    > > 3. The patch is not tied up with some other patches to the
    > > same image(s) with the above two problems

    >
    > Without further evidence, that seems unlikely.


    Again, how do you think you know this? Have you been gathering
    compatibility information about all the released (and unreleased)
    patches and images?


    > > 4. The patch maintainer has not given up on comp.os.vms due
    > > to all the vitriol ?

    >
    > Actually, without the discussion here the patch might never see the
    > light of day.


    Actually, VMS engineering has done all the coding, testing, kitting,
    re-testing, and documenting. The patch is ready and waiting to post.
    Then HP decided not to post it, JUST TO FORCE YOU TO MIGRATE TO
    HP-UX!!!!!!

    But now a few few zany posts here in c.o.v. will compel Mark Hurd to
    order VMS to release this patch!!!! Yay!!!

    Get real.

    Disclaimer: parts of this post are pure sarcasm.

  20. Re: MONITOR with different architectures

    In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    > In article <3QGx2DOob4Cv@eisner.encompasserve.org>,
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >
    >> > Surely the patch maintainer is reading this thread and the patch will be
    >> > up within 24 hours?

    >>
    >> What is the basis for your confidence that:
    >>
    >> 1. The patch has been fully tested in all configurations

    >
    > The problem has been known long enough that there should have been
    > enough time.


    How do you know it is the highest priority for those resources ?
    Some of us could hardly care less.

    >> 2. The patch does not have some theoretical drawback known
    >> through methods other than testing

    >
    > Whatever happened to DEC quality?


    I am very familiar with internal DEC quality techniques, and they
    certainly include being reticent to release software before it is
    ready.

    >> 3. The patch is not tied up with some other patches to the
    >> same image(s) with the above two problems

    >
    > Without further evidence, that seems unlikely.


    Take a look at some of the recent VMS patches that do get released -
    they include a whole lot of different changes in a single patch kit.

    >> 4. The patch maintainer has not given up on comp.os.vms due
    >> to all the vitriol ?

    >
    > Actually, without the discussion here the patch might never see the
    > light of day.


    I am not concerned about discussion of specific issue, I am talking
    about the general anti-VMS-development attitude in many posts. Some
    VMS development folks are reading these posts, but many fewer than
    would be if people stayed focused and on-topic.

+ Reply to Thread
Page 1 of 2 1 2 LastLast