Watching P2 memory usage on an Alpha - VMS

This is a discussion on Watching P2 memory usage on an Alpha - VMS ; I have a program that uses a good deal of P2 space. While it is running properly and works, I was using the following call to watch its P2 space usage: $ write sys$output f$getjpi(the_programs_pid,"p2_first_free_va_64") This works fine until it ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Watching P2 memory usage on an Alpha

  1. Watching P2 memory usage on an Alpha

    I have a program that uses a good deal of P2 space. While it is
    running properly and works, I was using the following call to watch
    its P2 space usage:

    $ write sys$output f$getjpi(the_programs_pid,"p2_first_free_va_64")

    This works fine until it gets to FFFFFFFF then it rolls over to
    00000000. I know the program that it's monitoring is working because
    its page file quota continues to slowly decrement even after this
    overflow.

    I can certainly write a small c program to do the SYS$GETJPI system
    service call and display from there. That call does return a quad-word
    which is what is needed in this case. The DCL script was just easier
    and has worked up until this point.

    This problem exists on our VMS V7.3-2 and V8.3 systems so an upgrade
    is unlikely to fix the issue. There was mention of this in an April
    2004 DECUS Munchen Bonn presentation:

    http://www.decus.de/slides/sy2004/22_04/3k01.pdf

    They mentioned it as something that would need to be fixed after V8.2.
    Since our v8.3 system still has not been fixed, I assume this is on
    someone's "to do" list.

    Any thoughts or ideas?

  2. Re: Watching P2 memory usage on an Alpha

    VMS is Virus Free writes:

    > $ write sys$output f$getjpi(the_programs_pid,"p2_first_free_va_64")
    >
    > This works fine until it gets to FFFFFFFF then it rolls over to
    > 00000000. I know the program that it's monitoring is working because
    > its page file quota continues to slowly decrement even after this
    > overflow.
    >
    > Any thoughts or ideas?


    The problem is that DCL does not do 64-bit math, and that value is being
    returned as an integer.

    I would not expect to see DCL enhanced to support 64-bit integers.

    --

    Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com

  3. Re: Watching P2 memory usage on an Alpha

    Rob Brooks wrote:
    > VMS is Virus Free writes:
    >> $ write sys$output f$getjpi(the_programs_pid,"p2_first_free_va_64")
    >>
    >> This works fine until it gets to FFFFFFFF then it rolls over to
    >> 00000000. I know the program that it's monitoring is working because
    >> its page file quota continues to slowly decrement even after this
    >> overflow.
    >>
    >> Any thoughts or ideas?

    >
    > The problem is that DCL does not do 64-bit math, and that value is being
    > returned as an integer.
    >
    > I would not expect to see DCL enhanced to support 64-bit integers.


    I would call the example above a bug.

    Silently truncating 64 bit values to 32 bit is not good.

    Arne

  4. Re: Watching P2 memory usage on an Alpha

    Arne Vajh°j wrote:
    >
    > Rob Brooks wrote:
    > > VMS is Virus Free writes:
    > >> $ write sys$output f$getjpi(the_programs_pid,"p2_first_free_va_64")
    > >>
    > >> This works fine until it gets to FFFFFFFF then it rolls over to
    > >> 00000000. I know the program that it's monitoring is working because
    > >> its page file quota continues to slowly decrement even after this
    > >> overflow.
    > >>
    > >> Any thoughts or ideas?

    > >
    > > The problem is that DCL does not do 64-bit math, and that value is being
    > > returned as an integer.
    > >
    > > I would not expect to see DCL enhanced to support 64-bit integers.

    >
    > I would call the example above a bug.
    >
    > Silently truncating 64 bit values to 32 bit is not good.


    Agreed. The entire 64-bit value should be returned in a string suitable
    for use with F$CVUI().

    D.J.D.

+ Reply to Thread