On Thursday, 4 February 2016 04:49:29 UTC, Gaur  wrote:
> Thanks Kolusu,
> 
> So here's the situation we have 5 way sysplex where 3 lpar's running with the 
> GMT timezone however 2 are running with separate asia time ...one is GMT -7 
> or 8 based on daylight saving and another is GMT +7 or 8  ...
> 
> Now requirement is to convert monthly collected the SMF Time and sync it 
> before get processed so that we do not compare apple with oranges 
> situation....
> 
> Now I could certainly used the ERBCHGMT utility however issue with this I see 
> is with every year we will have to make the JCL Changes and go through the 
> change management cycle ...so instead of this was looking DFSORT where I have 
> parm library mentioned with the Time/date so that with every daylight saving 
> we adjust an hour accordingly without going lot of hassle..
> 
> Now I ran the example you gave and used the ERBSCAN to look at the data 
> before and after and see SMFTIME is coming out same , Do we have some way to 
> ensure DFSORT is really converting the time?
> 
> Rec-Num Type    RecLn SMFDate  SMFTime  RMFDate  RMFTime  Int-Len   
> SMFId/Vers S
> ------- ------- ----- ----------------- ----------------- --------- 
> ---------- -
>       1 015        80 2015.306 00:00:19                             xxxx     
> 

Kolusu showed you how to do the type of calculation you'd need, using SYSIN 
data and plain-text dates and times (there are three SMF date formats 
available, and two SMF time formats, so without knowing which you are talking 
about, there was no point in his guessing).

"Since you haven't provided any kind of details of SMF records you are working 
with I am going to just show you an example of how it can be done."

No process is going to update the actual SMF records, so you can run ERBSCAN as 
much as you like, you'll never see the dates or times change.

If you have five systems, three on plain GMT, two in Asia using Daylight 
Saving, and one in the Americas using Daylight Saving (yes, I know that adds up 
to six) then "Sysplex reporting across time zones" already shows you how to do 
what you are asking (doesn't it?). You'd need three different processes, and 
then put all the adjusted data together. That's not exactly what the example 
shows, but you should be able to get there. 

With different parms at different times of the year? Isn't that a thing for 
your scheduler? Aren't you going to have some interesting "opportunities" when 
the time changes on three (or two) systems and not on the others?

System symbols for local dates and times can be easily accessed by DFSORT.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to