Hasn't this variable, or a very similar one, been available under MPEX for
quite some time?

-dtd

> -----Original Message-----
> From: Barry Lake [mailto:[log in to unmask]]
> Sent: Monday, December 11, 2000 12:12 PM
> To: [log in to unmask]
> Subject: Re: 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.
>