HP3000-L Archives

December 2000, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Barry Lake <[log in to unmask]>
Reply To:
Barry Lake <[log in to unmask]>
Date:
Mon, 11 Dec 2000 11:11:46 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
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.

ATOM RSS1 RSS2