Announcing Availability Manager V2.4-1

[Barry Kierstein]

The Availability Manager team is pleased to announce the release of the availability Manager Version 2.4-1. The kit
is now available on the Web at the following URL:

http://h71000.www7.hp.com/openvms/products/availman/


The main new feature of this kit is support for OpenVMS V8.2 on both the I64 and Alpha platforms. Other new features and changes are described in the release notes.

A couple of additional notes:

o If you are running on OpenVMS Version 6.2 through Version 7.2-n, and you have installed the Availability Manager,
you will need to install the Availability Manager Data Collector Version 2.4 before you install the Version 2.4-1 Data Collector.
This is necessary to correct various irregularities that existed in previous Availability Manager kits.

o Because the Availability Manager Data Collector for I64 is part of the Enterprise Operating Environment (EOE) licensing tier, there are upcoming changes in how this software will be distributed.
See the I64 licensing link near the top of the Availability Manager home page, and the Product Support page farther down on the home page.

Thank you for using our products. If you have any questions or comments, please let the team know.

The Availability Manager Team
OpenVMS Engineering

[Ian Miller.]

Thank you Barry for this indespensible tool and I look forward to the version that allows remote monitoring :-)

For those reading this and wondering what it is I urge you to go read the doc at the the web site referenced. Availability Manager is the sucessor to AMDS and allows realtime resource montitoring and fixes to VMS systems from a VMS (or windows) system.

[Tom O'Toole]

I am currently using amds avail/motif to monitor over 20 vms boxes. I just installed and tried avail/avail, and it uses 40-75% of my pws/600 cpu (vs about 1% for avail/motif).
The display also won't show multiple groups at a time. Anyone have any ideas about how to mitigate these problems?

I tried setting the 'fast JVM' setting, (via logical name), but it didn't seem to do anything.

Since it looks the future is that we will
be stuck with this, does anyone have any ideas about how to mitigate this? In particular, I'd like to customize it to get rid of the warnings display completely (the bottom pane of the main screen), if that would improve performance.

By copying the vms 7.3-2 library to the 8.2 name, I'm able to monitor 8.2 hosts (some of the detailed stuff gets mangled, but I'm mostly interested in the one line display) with avail/motif, but this doesn't work for itanium.

I'm not sure where HP is going with stuff like this.

[Karl Rohwedder]

Tom,

on a (quite old) Alphaserver 2100 (5/300) AVAILMAN uses 10-50% CPU when monitoring 6 systems. That's why I use a PC as frontend and I think that's the way HP wants us to work :-(

mfg Kalle

[Martin Vorlaender]

Hi,

could it be the case that the CPUs are occupied with memory management tasks? Java *is* resource-hungry, but in my experience more for memory than for the CPU.

Does http://h71000.www7.hp.com/ebusiness/OptimizingSDKGuide/OptimizingSDKGuide.html apply to systems having the RTE only? Some of the basic recommendations should hold.

cu,
Martin

[Barry Kierstein]

Hello all,

Here are some answers to some of the concerns brought up so far.
True, Java takes more resources than a complied C program using Motif, so some of the resource consumption is due to that. However, some of it is due to the program itself. The team here has tried to run various Java performance analyzers with a small amount of success to find various AM-related performance issues. Now with the profiler that comes with NetBeans, the team will pursue this avenue more in earnest now that the port to I64 is done, etc. With work in this area, the performance and hopefully the memory footprint will be less.
As far as the OptimizingSDKGuide is concerned, I haven't looked at it, but if it mentions things about accounts and logical names, etc., then it should help. Just remember that AM does very little file I/O (just to the log files), so any I/O-related improvements aren't going to help.
I hope that this perspective helps.

Barry

[Alan Tucker]

Down loaded the collector but can't run the EXE to create the PCSI file on the Alpha.

%DCL-W-ACTIMAGE, error activating image HP-AXPVMS-AVAIL_MAN_ANA-V0204-1-1.EXE;1
-CLI-E-IMGNAME, image file DSA2:[USERS]HP-AXPVMS-AVAIL_MAN_ANA-V0204-1-1.EXE;1
-IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha image

[Richard Brodie_1]

Alan,

The file I see is in PCSI compressed format; try renaming it to .PCSI$COMPRESSED and PCSI should handle it, if it is recent enough.

[Alan Tucker]

Thanks

I did find it actually told me when I dumped the file..Loaded AOK now.

Regards Alan.

[Steve Reece_3]

I installed the 2.4 kit a while back on a DS20E. It was sufficiently slow and resource hungry that I installed the PC version on my laptop and use that instead. It's a darned sight quicker than the VMS version!

[Willem Grooters]

Barry,

Please give me a good reason why JAVA is used for the Availability manager, when it requires these amounts of resources - memory and CPU (as any JAVA application).
"Mission critical" environment does not automatically mean "Big site". Small sites have few small machines, and need to use their equipment as efficiently as possible, and I found that JAVA applications can have quit noticable negative influence on overall performance. If that could be avoided, using an architecture that is more VMS-friendly, it would be appreciated; buying more memory, a bigger system or another box is not always an option.

(Personal opinion)

[Jan van den Ende]

@ Barry:

Willem presented the previous entry as "Personal opinion"

Well, he definitely is NOT alone in that opinion! I fully share that view.

Proost.

Have one on me.

jpe

[Barry Kierstein]

Hello!

A comment or two about the use of Java for the Availability Manager.
The original decision to use Java for AM was to make supporting both the OpenVMS and Windows platform feasible. Many managers only have a Windows box on their desk as mandated by their company policy, and thus the decision. The ability to run on both platforms has been an advantage to most people.
Now, about the performance. This will be looked at in the next development cycle later this year. The team here is well aware that there are performance issues, and we now have some tools to work on this problem.
Running as a native .EXE would definitely be run more efficiently, but would have made supporting both platforms much more resource intensive, and it would be much harder to keep the application current. With some work on performance, this should help the resource problems in running the Data Analyzer.

Barry Kierstein