Re: Resetting date

Jeffrey M. Carey wrote:
> 
> I know there was just recently a thread about this, but don't recall if
> there was a PTF or not.
> 
> This morning, IBM came in to do an engineering change on our 50S.  As
> people signed on, those with expiration intervals other than *NOMAX had
> to change their passwords.  Luckily, one of them asked me why.  I
> discovered that the system date was 08/23/28.  Very fortunately, this
> was on our development machine. I immediately changed the date on the
> system.
> 
> Is there a PTF?  Have IBM Hardware CE's been made aware of this?

Here's a repost of my earlier answer.
To eveyone out there - IF you have an IBM Support contract I urge you to
call and complain loudly about this problem.  Don't be fobbed off with
any wimpy excuse.  IBM has known about this problem for years and
there's absolutely NO excuse for an IBM CE (CSR, whtever the term du
jour is) for not knowing about this when doing maintenance on the
system.  As you can see from my note, there doesn't appear to be a PTF
for RISC systems available.  Again, COMPLAIN LOUDLY and OFTEN.  This
problem can cause SEVERE business interruption and IBM have NO excuse
for not doing something about it.   If even half the people on this list
complained about this problem it would soon attract a lot of attention
in Rochester.

Until then - I strongly advise you to make the first IPL a MANUAL IPL
and check the date/time carefully ANY time your system has been powered
down for maintenance.


----------------------------------------------------------------------

I found this one when I upgraded to an early release of V3R1 about 2.5
years ago and my nightly backup job failed.  It crashed when the backup
job issued a STRSBS QINTER and I suppose it didn't respond within 1
second and issued a CPF1001.
I had to complain several times before they finally relented and issued
the PTF.
They first claimed they couldn't PTF it because they might change the
default wait time back to 120 seconds for someone who had deliberately
changed it to something else.  My argument was, who would change it to 1
second ?  Set the PTF exit program to only change back to 120 seconds if
currently set to 1 second.  Besides, doesn't everyone read the PTF cover
letters anyway ?  :-)
(Maybe that's why they wouldn't put it on a cum package, so you would
probably read the cover letter if you ordered it individually).

I also questioned why there were two QBATCH classes, but who knows !
The problem could occur with either the QBATCH class in QSYS or QGPL.
I believe if you upgraded to V3R1 the default wait time for the
QGPL/QBATCH class was changed from 120 seconds to 1.  HOWEVER if you
took delivery of a new machine from Rochester with V3R1 pre-loaded, the
QSYS/QBATCH class came with a 1 second default wait time.

The APAR is SA46363 and the V3R1 PTF is SF32088.
They still won't put it on a cumulative PTF package, so you must order
it separately (or just check the DFTWAIT time for the two QBATCH classes
on your system and if they show 1 second change back to 120 seconds).



-- 
... Neil Palmer                                      AS/400~~~~~      
... NxTrend Technology -Canada       ____________          ___  ~     
... Markham,  Ontario,  Canada       |OOOOOOOOOO| ________  o|__||=   
... Phone: (905) 731-9000 x238       |__________|_|______|_|______)   
... url:http://www.NxTrend.com        oo      oo   oo  oo   OOOo=o\   
... mailto:NPalmer@NxTrend.com     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *