My original point was that a program was using the HPCIGETVAR to obtain
system information.  The problem was that a new feature was used in an
environment that does not always have all machines at the same operating
system level.  I had not read Stan's explanation when I posted my message
and now realize that I should have stayed with the rule of waiting until all
machines are at the same level to use a function.  My first instinct when I
found that the variable was queried and unavailable was to change the
program.  I would have done that had the system kept me from creating a 'HP'
variable.  A little more work at the front end can avoid problems later on.

I agree with Stan that the HPxxxx variable names should only be created by
HP.

Alan Wyman
Programming Manager - Information Systems
Alliant Foodservice - Minneapolis
2864 Eagandale Boulevard
Eagan, MN 55121
(651) 683-4253
(651) 683-4438 fax
e-mail: [log in to unmask] <mailto:[log in to unmask]>

        -----Original Message-----
        From:   Barry Lake [SMTP:[log in to unmask]]
        Sent:   Monday, December 11, 2000 1:12 PM
        To:     [log in to unmask]
        Subject:        Re: [HP3000-L] jobq - user job queues

        At 9:35 AM -0800 12/11/00, Barry Lake wrote:
        >At 6:56 AM -0700 12/11/00, Wyman, Alan wrote:
        >>...I just had a contractor code a program using the
        >>HPYYYYMMDD variable.  This was made available in a 6.0 powerpatch.
The
        >>contractor checked the two local machines and they had it.  We
installed on
        >>a remote machine that hadn't been patched (long story there) and
the program
        >>failed.
        >
        >A possible solution to that problem is to do something like
        >
        >  if bound(HPYYYYMMDD)
        >     setvar MY_yyyymmdd HPYYYYMMDD
        >  else
        >     setvar MY_yyyymmdd "!HPYYYY" + &
        >                        rht("0"+"!HPMONTH",2) + &
        >                        rht("0"+"!HPDAY",2)
        >  endif


        Ok, sorry about that. After posting my previous reply (while still
half
        asleep!)  I realized that this isn't the best solution. While it
would
        certainly work, it is neither elegant nor practical: you'd have to
add this
        klunky code to every job, and change all occurrences of "HPYYYYMMDD"
to
        "MY_yyyymmdd" in order to reference your new variable.

        Better would be to do

          if not bound(HPYYYYMMDD)
             setvar HPYYYYMMDD...
          endif

        And rather than add this to any or all jobs that might need
HPYYYYMMDD,
        instead put it in a system wide logon udc. That way the variable
would
        exist transparently for all jobs on all systems, regardless of the
OS level.

        I consider this to be a reasonable compromise between Stan's (and
others')
        position that the CI should not allow users to set variables
beginning with
        "HP" and the position of those who believe "it's *my* system and I
should
        be able to set any variable I please".

        If we would all agree to check for the existence of an "HP" variable
before
        setting it, then we'd never run into problems such as those that
have been
        mentioned in this thread. Of course, that's a big "IF".

        There's one additional detail worth mentioning. On systems where the
        HPYYYYMMDD variable is provided by the OS, it is a dynamic variable.
That
        is, if your job or session stradles the midnight barrier, then
before
        midnight you'll get one value and after midnight you'll get a
different
        value. On the other hand, the value of the variable set by the logon
udc
        under earlier versions of the OS will not change after midnight.


        Barry Lake                              [log in to unmask]
        Allegro Consultants, Inc.               www.bogus.allegro.com
        (408)252-2330
        --------
        Attempting to reduce spam influx.
        Remove ".bogus" to create valid address.