RFC: Cluster status on a mobile handset - VMS

This is a discussion on RFC: Cluster status on a mobile handset - VMS ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: RFC: Cluster status on a mobile handset

  1. RFC: Cluster status on a mobile handset

    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.

  2. Re: RFC: Cluster status on a mobile handset

    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

  3. Re: RFC: Cluster status on a mobile handset

    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.

  4. Re: RFC: Cluster status on a mobile handset

    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



  5. 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.

    > 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).

  6. RE: RFC: Cluster status on a mobile handset



    -----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


  7. Re: RFC: Cluster status on a mobile handset

    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*.


+ Reply to Thread