Handling large numbers in DCL - VMS

This is a discussion on Handling large numbers in DCL - VMS ; Same results on VAX 7.3 and Alpha 8.3 $ tot = f$getdvi("$11$dqa0","MAXBLOCK") $ show symbol tot TOT = 58633344 Hex = 037EAC80 Octal = 00337526200 $ used = tot - f$getdvi("$11$dqa0","FREEBLOCKS") $ show symbol used USED = 21928928 Hex = ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Handling large numbers in DCL

  1. Handling large numbers in DCL

    Same results on VAX 7.3 and Alpha 8.3

    $ tot = f$getdvi("$11$dqa0","MAXBLOCK")
    $ show symbol tot
    TOT = 58633344 Hex = 037EAC80 Octal = 00337526200

    $ used = tot - f$getdvi("$11$dqa0","FREEBLOCKS")
    $ show symbol used
    USED = 21928928 Hex = 014E9BE0 Octal = 00123515740

    $ percent = used * 100 / tot
    $ show symbol percent
    PERCENT = -35 Hex = FFFFFFDD Octal = 37777777735


    After some testing, I have found that the largest number DCL can handle is

    A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777
    (2^31 - 1)

    How do folks deal with this issue ? I am dealing with 18 gig drives
    here, and I suspect that those with bigger drives would encounter such
    issues much more.

    What happens when disks contain a MAXBLOCK value that is greater than
    2^31 - 1 ? Does it return a negative value ?

    In my case, I am thinking about testing the value of "used" against
    0x7FFFFFFF / 100, and if greater, then I know I can't multiply it by 100
    and would then need to divide both "used" and "tot" by 100 before
    executing the ration on them

  2. Re: Handling large numbers in DCL

    On Nov 24, 8:33 am, JF Mezei wrote:
    > Same results on VAX 7.3 and Alpha 8.3


    No duh! It's by law.

    > $ percent = used * 100 / tot
    > $ show symbol percent
    > PERCENT = -35 Hex = FFFFFFDD Octal = 37777777735
    >
    > After some testing, I have found that the largest number DCL can handle is
    >
    > A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777 (2^31 - 1)


    And you only now found out about this? Jeez....

    > How do folks deal with this issue ?


    We use 'advanced' math.

    > What happens when disks contain a MAXBLOCK value that is greater than
    > 2^31 - 1 ? Does it return a negative value ?


    That would be why the maximum volume size in OpenVMS is limited to 1TB
    (1024*1024*1024).

    >
    > In my case, I am thinking about testing the value of "used" against
    > 0x7FFFFFFF / 100, and if greater, then I know I can't multiply it by 100
    > and would then need to divide both "used" and "tot" by 100 before
    > executing the ration on them


    Think about it for a moment my friend.
    Think back to 4th grade primary school

    a*b/c = a*(b/b) / (c/b) = a / ( c / b )

    in your case:

    $ IF tot > 100000 ! MD, LD devices?
    $ THEN
    $ percent = used / ( tot / 100 )
    $ ELSE
    $ percent = used * 100 / tot
    $ ENDIF

    Cheers,
    Hein



  3. Re: Handling large numbers in DCL

    JF Mezei wrote:
    > Same results on VAX 7.3 and Alpha 8.3
    >
    > $ tot = f$getdvi("$11$dqa0","MAXBLOCK")
    > $ show symbol tot
    > TOT = 58633344 Hex = 037EAC80 Octal = 00337526200
    >
    > $ used = tot - f$getdvi("$11$dqa0","FREEBLOCKS")
    > $ show symbol used
    > USED = 21928928 Hex = 014E9BE0 Octal = 00123515740
    >
    > $ percent = used * 100 / tot
    > $ show symbol percent
    > PERCENT = -35 Hex = FFFFFFDD Octal = 37777777735
    > After some testing, I have found that the largest number DCL can handle is
    >
    > A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777
    > (2^31 - 1)
    >
    > How do folks deal with this issue ? I am dealing with 18 gig drives
    > here, and I suspect that those with bigger drives would encounter such
    > issues much more.


    I used to have some DCL to deal with this issue at my last IT job, and
    some of my customer sites had large disks to deal with. The DCL I was
    "given" was written with smaller disks in mind, and I know I had to make
    adjustments to deal with larger-disk "cases". I re-wrote the DCL to
    handle "all" cases, but unfortunately, I did not save a copy to take
    home with me after I was laid off.

    Check dcl.openvms.org for some examples of general-case disk capacity
    DCL that you could adapt for use (search for "disk" using the handy
    search facility provided).

    I have 72G drives, and I have no worries with this issue at present -
    then again, I'm just a hobbyist.

    > What happens when disks contain a MAXBLOCK value that is greater than
    > 2^31 - 1 ? Does it return a negative value ?
    >


    Well, by some rough "back of the envelope calculations", drives would
    have to be close to 1 TB each to approach this limit. Such drives are
    possible (especially with FC products like XP?), but the mind boggles
    trying to imagine a system that would approach, say, +10 (or +100) TB of
    data storage, and the system manager that would be concerned that
    his/her storage needs are approaching that capacity!

    > In my case, I am thinking about testing the value of "used" against
    > 0x7FFFFFFF / 100, and if greater, then I know I can't multiply it by 100
    > and would then need to divide both "used" and "tot" by 100 before
    > executing the ration on them


  4. Re: Handling large numbers in DCL

    On Nov 24, 1:33 pm, JF Mezei wrote:
    > Same results on VAX 7.3 and Alpha 8.3
    >
    > $ tot = f$getdvi("$11$dqa0","MAXBLOCK")
    > $ show symbol tot
    > TOT = 58633344 Hex = 037EAC80 Octal = 00337526200
    >
    > $ used = tot - f$getdvi("$11$dqa0","FREEBLOCKS")
    > $ show symbol used
    > USED = 21928928 Hex = 014E9BE0 Octal = 00123515740
    >
    > $ percent = used * 100 / tot
    > $ show symbol percent
    > PERCENT = -35 Hex = FFFFFFDD Octal = 37777777735
    >
    > After some testing, I have found that the largest number DCL can handle is
    >
    > A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777
    > (2^31 - 1)
    >
    > How do folks deal with this issue ? I am dealing with 18 gig drives
    > here, and I suspect that those with bigger drives would encounter such
    > issues much more.
    >
    > What happens when disks contain a MAXBLOCK value that is greater than
    > 2^31 - 1 ? Does it return a negative value ?
    >
    > In my case, I am thinking about testing the value of "used" against
    > 0x7FFFFFFF / 100, and if greater, then I know I can't multiply it by 100
    > and would then need to divide both "used" and "tot" by 100 before
    > executing the ration on them


    I would suggest NOT trying to do calculations using the DCL inbuilt.
    Instead, use this command line utility :-

    http://vms.process.com/scripts/files...serv.com?ICALC

    ALPHA_ROB$ TOT = 58633344
    ALPHA_ROB$ USED = 21928928
    ALPHA_ROB$ ws used * 100 / tot
    -35
    ALPHA_ROB$ icalc 'used' * 100 / 'tot'
    37.4000978
    ALPHA_ROB$ sh sym icalc_out
    ICALC_OUT = "37.4000978"
    ALPHA_ROB$

  5. Re: Handling large numbers in DCL

    In article , JF Mezei writes:
    > Same results on VAX 7.3 and Alpha 8.3
    >
    >
    > After some testing, I have found that the largest number DCL can handle is
    >
    > A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777
    > (2^31 - 1)
    >


    Yep, DCL has 32 bit integers. Always has. Probably always will.
    The rest of us get around it by programming in one of the many
    3GL than can handle floating point or 64 bit integers. On VAXen,
    we long ago learned how to use things like EMULx to work very
    long integers on a 32 bit machine.

    You can call LIB$ routines to access these instructions on VAXen
    and their mathematically equivalent routines on Alpha and IA-64 so
    you don't have to work in Macro-32.


  6. Re: Handling large numbers in DCL

    If you're willing to use a Freeware solution, the latest
    version of the OpenVMS Freeware collection has ICALCV on it. I
    fixed a number of compilation problems, and wrote a replacement
    for the one module that was written in FORTRAN, so it's all in C
    now. I use it regularly, but like all Freeware there is no
    official support. I use it to calculate the percentage of free
    space remaining on very large disk drives, because it can do
    floating point as well as very large integers, trig, logs, dates,
    etc.

    There are also older versions of it floating around.

    --
    B. Z. Lederman. My personal opinions.

+ Reply to Thread