On Nov 26, 2007 10:53 AM, JF Mezei
wrote (in part):
> http: // wap.vaxination.ca / clu
>
> pressing key 0 gets you to the top,
> 1 gets you to general cluster status
> 2 gets you to list of nodes
> 3 gets you list of disks
> 4 gets you the list of queues.

I just took a look at this on my VerizonWireless LG-VX9400. Impressive.

>
> Would appreciate any comments you might have on the format, structure,
> how to make it easier to get to the data, and what data should be added
> (or removed) from it.

One thing I didn't like was that you load the all the information each
time and just go to the section requested. It would be much better
just to display to requested section and/or the menu. Also, when I
displayed the information for the VAX, the temperature shows a very
low temp, since the VAX can't show the temp. It would be better not to
display the temp on a VAX.

>
>
> (I'll be doing additional work for authentication later on since
> obviously, you don't want the world to look under the hood of your cluster).
>
> Am thinking about adding colours to the disk usage. Above what
> percentage of usage should a disk become yellow and above what
> percentage should it become red ?

This should be customizable for each installation and possibly
different for large disks vs. small disks.

>
> If there is interest, I would release it to the community. The DCL is
> generic enough to run an any machine.

I would be very interested in seeing/using the code.

Ken Robinson

Ken Robinson wrote:
> One thing I didn't like was that you load the all the information each
> time and just go to the section requested.


Yep. When it was in WML, it was much better organised into cards
(virtual pages). So with one transaction, you have the info and could
then very quickly access it.

But with XHTML, one is limited to 12 access keys (the numeric keypad).

First generation WAP required the use of a WAP gateway/proxy which
compiled the pages into compressed binary WML before being sent over the
air to the handsets. That WAP gateway also added plenty of HTTP headers
to the request being sent to the server, including a field identifying
the customer.

But newer handsets can now bypass the WAP gateway and make their own
HTTP requests to remote servers, so identifying information is no longer
necessarily available.

So I may end up having to have a page that requests your
username/password as well as check boxes on what content you are
interested in. It would add to the number of keystrokes needed to get to
the information though.


> displayed the information for the VAX, the temperature shows a very
> low temp, since the VAX can't show the temp.


"very low" is an understatement :-) My vax is very cool at -273°C :-)
I hardcoded the value more as a test of the logic. It started off with
"N/A" but that didn't really look cool. This script currently runs on
that VAX and obtaining temperatures was no so simple since they haven't
updated VAX-VMS to support F$GETSYI("TEMPERATURE_VECTOR") when
requesting info about other nodes. So it has to do decnet connections to
each node to obtain their temperatures.


> This should be customizable for each installation and possibly
> different for large disks vs. small disks.

Since it is DCL, it is customizable :-) Just wondering though if people
would just want some variables defined at the top do they don't have to
look at the code, or whether they would end up looking/modifying the
code anyways to fit their particular needs.

Some sites might wish to add code to check for particular stuff on their
cluster for instance, or flag certain thing with a colour etc etc.

Or perhaps adding more intelligence to it and displaying only
information that is "odd". For instance displaying stopped queues only,
or disks that have usage above X% and/or more than 0 errors.

JF Mezei wrote:
> For a while now, I have had a WAP/WML script that gave a status of my
> cluster over a mobile phone. This was the real WML, with cards. A single
> transactions brought all the info over and you could then easily
> nagivate from page to page with the navigation keys and quickly go
> through to system's status.
>
> Newphangled phones have abandonned the compact/efficient WML for the WAP
> 2.0 which is essentially XHTML with a mobile profile.
>
> I have therefore begun to convert the dcl procedure to generate that
> format, complete with neat colours (CSS styles are now supported).
>
> However, XHTML lacks the navigation capabilities of WML so it isn't as
> obvious how to structure that page.
>
> anyone with a modern handset can look at it:
>
> http: // wap.vaxination.ca / clu
>
> pressing key 0 gets you to the top,
> 1 gets you to general cluster status
> 2 gets you to list of nodes
> 3 gets you list of disks
> 4 gets you the list of queues.
>
> Would appreciate any comments you might have on the format, structure,
> how to make it easier to get to the data, and what data should be added
> (or removed) from it.
>
> Also, if you cannot view it, let me know your phone model. I've compared
> the developer documents for both Nokia and Ericsson and they seem quite
> similar. (they are both based on Symbian so I assume they may share a
> similar engine under the hood).
>
>
>
> (I'll be doing additional work for authentication later on since
> obviously, you don't want the world to look under the hood of your
> cluster).
>
> Am thinking about adding colours to the disk usage. Above what
> percentage of usage should a disk become yellow and above what
> percentage should it become red ?
>
> If there is interest, I would release it to the community. The DCL is
> generic enough to run an any machine.

Hi JF,

Really cool application! Works fine on my Nokia E90. I tested it with
WLAN and GPRS. No significant difference in speed.

My suggestion to the disk usage alarm level is that the yellow threshold
would be at 70% used space and red threshold at 90% used space. The
yellow level would tell that the filesystem has reached the point where
it will grow slower. That has been verified in many tests. Then the red
level would tell that the filesystem really needs attention as it soon
will cause problems if not taken care of quickly.

Another suggestion is that it would be valuable to see if the nodes are
heavily loaded. E.g. CPU-time over 90% for more than 5 mins, would turn
the nodes colour red.

A third suggestion is to show the Cluster Interconnects somehow. If
there are any problems with them, it could show in yellow and if cut
completely, it could show in red.

Also queue states could be shown colour coded. E.g. paused queue in
yellow and stopped in red. Maybe a very busy queue could also be shown
in yellow.

These are just some thoughts, which I have been pondering, because I've
been planning to make an cluster monitoring application also (although
not in wap, but just in regular html). ;-)
You were there first. Good luck with the development!

Regards,

Kari

Uusimäki wrote:
> Really cool application! Works fine on my Nokia E90.

Thanks. Good to know that other handsets can handle it.

> WLAN and GPRS. No significant difference in speed.

The actual XHTML content is pretty small. No images. So it wouldn't
really make much of a differenceb in download speed. And the DCL needs
to do a decnet connection to every node to obtain its temperature, and I
suspect that this may be the limiting factor.


> My suggestion to the disk usage alarm level is that the yellow threshold
> would be at 70% used space and red threshold at 90% used space.

Ideally, you'd want to see some constantly running process monitor disk
usage and provide informaion on a trend instead of usage at one specific
moment (akaL: some application running wild and creating hundreds of
thousands of files)


> Another suggestion is that it would be valuable to see if the nodes are
> heavily loaded. E.g. CPU-time over 90% for more than 5 mins, would turn
> the nodes colour red.


Is there a way in DCL to obtain CPU utilisation ? Or would that require
writing the equivalent of MONITOR SYSTEM to get that percentage ?

> A third suggestion is to show the Cluster Interconnects somehow. If

Are those available from DCL ?


> Also queue states could be shown colour coded. E.g. paused queue in
> yellow and stopped in red. Maybe a very busy queue could also be shown
> in yellow.

There is no F$GETQUI item code for "very busy" :-) I guess this would
have to be some configurable parameter that is based on number of jobs
waiting to execute ?


One issue to consider is that if your cluster is pretty sick, chances
are that you won't be able to get to it from your mobile. So the ability
to download any content from your host indicates a certain health level
for the system, switches, routers, modem.


OK: Big question here. If there is interest in this, would excluding VAX
as a running node (the one executing that code) be acceptable ?
(This would allow me to use $ACM for instance as well as using
GETSYI/DVI/QUI item codes not available on VAX).

-----Original Message-----
From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca]
Sent: November 28, 2007 4:56 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: RFC: Cluster status on a mobile handset

Uusimäki wrote:
> Really cool application! Works fine on my Nokia E90.

Thanks. Good to know that other handsets can handle it.

..snip..


Cool -

Btw, way cool demo I remember was on of the Eng folks had a large Alpha GS1280
being controlled with iPaq. The demo showed the Engineer using the iPaq to move
CPU`s among different logical partitions in a Galaxy environment.

Regards

Kerry

On Wed, 28 Nov 2007 16:55:46 -0500, JF Mezei
wrote:



>OK: Big question here. If there is interest in this, would excluding VAX
> as a running node (the one executing that code) be acceptable ?
>(This would allow me to use $ACM for instance as well as using
>GETSYI/DVI/QUI item codes not available on VAX).


Hi JF,

You are not going to like my reply. :-(

I need/want/have to retire my VAX. :-(
It is holding me back. :-(
But the customer still sends in support cheques. :-)

Now that I have redesigned (and nearly qualified) a more flexible, more
powerful build environment on the Itanium (easily backported to the Alpha),
I am left with the exercise of *what to do about the VAX*?

Minimize the differences by making the necessary changes on the VAX in
hopes that after all these years, the customer gives up on the port?

Freeze the code and build environment on the VAX (possibly forcing me to
maintain edits across multiple code trees)?

Continue to maintain an increasing complex code and build environment
that is compatible with the 3 architectures?

I need/want/have to retire my VAX. :-(
Sad, but I got over the PDP retirement. :-)
So I know I will get over the VAX. :-)

JF, I encourage you to give up on the VAX.
Code for the future and never look back.

The hope for OpenVMS is to prepare for and to take on the future, not to
resurrect or rescue the past. The vendor is preparing, and so should we. As
mentioned above, I have used the port as an opportunity to strengthen my
code. I am also starting to get a grip on the MP (on the I-box) and hope to
find some time to explore it and some of my other ideas. Enhancements will
no doubt, eventually force me to want to retire the Alpha :-(, but each
generation of hardware has provided me with new capabilities that I find
hard not to exploit to my advantage. :-)

I cannot change the path that has led us to the current *Industry
Standard*, but I (as well as anybody else) can try to change the future.
(Even if it is already predetermined. :-)

Duane
(a platform/vendor agnostic, OpenVMS loyalist)


Btw JF, I do like the new direction your posts have taken and I look
forward to reading more of your adventures on the *leading* edge of
OpenVMS. I hope your efforts (and stories, as well as the effort and
stories of others) will encourage the next generation of developers that
are looking to do something different, that OpenVMS IS the
*Old School, New Cool*.