Re: 4-hour MSU rolling average

[suresh chacko]

Mark,

Excellent one. I use the same. Regads, Suresh


On Tue, Oct 27, 2015 at 12:17 AM, Greg Shirey 
wrote:

> I use the following, which is similar to the REXX provided earlier in this
> thread (and liberally stolen from Mark Zelden).
>
> /*  REXX   */
>
> CVT = C2D(STORAGE(10,4))
> RMCT = C2D(STORAGE(D2X(CVT+604),4))
> RCT = C2D(STORAGE(D2X(RMCT+228),4))
> RCTLACS = C2D(STORAGE(D2X(RCT+196),4))
> RCTIMGWU = C2D(STORAGE(D2X(RCT+28),4))
> RCTCECWU = C2d(Storage(D2x(RCT+32),4))
> IF RCTCECWU <> 0 THEN DO
>   say   'The MSU capacity for this CEC is' rctcecwu'.'
>   say   'The defined MSU capacity for this LPAR is' rctimgwu'.'
> END
> IF RCTLACS <> 0 THEN DO
>   say   'The 4 hour msu average usage is' rctlacs'.'
>   IF RCTLACS = RCTIMGWU & RCTIMGWU <> RCTCECWU THEN ,
> say   ' ** LPAR may currently be "soft capped". **'
>   IF RCTLACS > RCTIMGWU & RCTIMGWU <> RCTCECWU THEN ,
> say   ' ** LPAR is currently "soft capped". **'
> END
>
> Regards,
> Greg Shirey
> Ben E. Keith Company
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, David Allen,Jr
> Sent: Monday, October 26, 2015 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 4-hour MSU rolling average
>
> Thank you. That is the total capacity of the CEC, 28 on my machine. For
> SCRT purposes, I cap at 16. Is there a variable which I can look at to see
> how far under this cap I am, or when I am experiencing capping?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
*SureshNc*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Jousma, David]

WE used to shutdown and wait the hour.   A few years ago we used some of our 
D/R system time to do some testing, and concluded we could dispense with the 
1-hour wait.

We do use the SET TIMEZONE command, not the SET CLOCK command however, and of 
course, run with GMT clock = GMT, not local.   Offset is still coordinated with 
local time, so all users *see* local time.

We only have two manual efforts:
- SET TIMEZONE=W.05 per lpar
- once completed, then issue CEMT P RESET for each CICS region, well actually a 
masked modify command to get them all at once.


I'd like to get to the point where the time change is automatic, but I fear we 
will never get to that point as there are a couple of app groups that are still 
afraid, and shut their applications down during the time we do this procedure.


_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, October 26, 2015 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE-IPL for the Daylight to Standard time conversion?

I'm a developer, not an operations guy. My boss has asked me why a datacenter 
we use would need to IPL for the daylight to standard time transition. He asks 
if the box does not use UTC, and I said that yes, the hardware clock is 
generally set to UTC but that perhaps the LPAR time zone change required an IPL.

Can anyone enlighten me? Why might our datacenter need or want to IPL for the 
Daylight to Standard time conversion?

Thanks,

Charles 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Paul Gilmartin]

On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
>
>Since UNIX and Windows platforms handle DST by just forcing the local
>time discontinuity, if an application has a problem with that, you don't
>have a choice other than tolerating the result or trying to find and fix
>any intolerable problems the discontinuity causes for the application.
>I'm sure there are cases on those platforms where a rare "strangeness"
>at time zone changes is just tolerated, since users in those environment
>traditionally seem to expect a higher level of s--- happens and some
>occasional apparent non-determinism..
> 
I'm trying to imagine my UNIX-oriented colleagues' snickering at the
idea of shutting down a system at the DST transition.  When they
stopped giggling, I'd expect them to ask, "But which time zone; which
country?  All?  Northern or Southern Hemisphere?  Both?"  UNIX
systems run their system clocks on UTC and an input to localtime()
is a time zone chosen by the programmer.  It would be absurd to
expect an hour's outage for each of several dozen time zones in
the world.  z/OS has a peculiar tunnel vision in its belief that there
are only two time zones.

Leap seconds are a different issue.  z/OS shuts down all applications
during a leap second.  Google and Amazon both steer their clocks
slow (less than 0.01 percent) for several hours centered on a leap
second.  And the two have chosen different steering durations.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Vince Coen]

Sunday is the *day *that clocks move forwards or back an hour or two. 
e.g., 02:00 etc.


Hardly a heavy work load period unless it is a system upgrade day !

On 27/10/15 11:35, Ted MacNEIL wrote:

What's so special about Sunday? I used to work for an international bank. 
Sunday. Was no excuse for an outage!

-
-teD
-
   Original Message
From: Vince Coen
Sent: Tuesday, October 27, 2015 07:11
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

I would have thought that all these issues would have been easy to be
resolved if all sites used UTC time on hardware level with
the adjustment for local set up at the software level then it only
requires simple job step to adjust if there is not one built in to the O/S.

Also and if needed that no job/processes was allowed to run over the
time period of time change where such a process might get upset.

Let face it as clock change occurs for most of us on a Sunday this
should not really be a major problem.

I am somewhat surprised that IBM does not have standard procedures /
processes / Job in place to handle this including checking the hardware
clock against an external source the same that Unix, Linux, Windows does
even if it has to go through a inhouse Intranet server for security.




On 27/10/15 06:14, Paul Gilmartin wrote:

On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:

Since UNIX and Windows platforms handle DST by just forcing the local
time discontinuity, if an application has a problem with that, you don't
have a choice other than tolerating the result or trying to find and fix
any intolerable problems the discontinuity causes for the application.
I'm sure there are cases on those platforms where a rare "strangeness"
at time zone changes is just tolerated, since users in those environment
traditionally seem to expect a higher level of s--- happens and some
occasional apparent non-determinism..


I'm trying to imagine my UNIX-oriented colleagues' snickering at the
idea of shutting down a system at the DST transition. When they
stopped giggling, I'd expect them to ask, "But which time zone; which
country? All? Northern or Southern Hemisphere? Both?" UNIX
systems run their system clocks on UTC and an input to localtime()
is a time zone chosen by the programmer. It would be absurd to
expect an hour's outage for each of several dozen time zones in
the world. z/OS has a peculiar tunnel vision in its belief that there
are only two time zones.

Leap seconds are a different issue. z/OS shuts down all applications
during a leap second. Google and Amazon both steer their clocks
slow (less than 0.01 percent) for several hours centered on a leap
second. And the two have chosen different steering durations.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Vince Coen]

I would have thought that all these issues would have been easy to be 
resolved if all sites used UTC time on hardware level with
the adjustment for local set up at the software level then it only 
requires simple job step to adjust if there is not one built in to the O/S.


Also and if needed that no job/processes was allowed to run over the 
time period of time change where such a process might get upset.


Let face it as clock change occurs for most of us on a Sunday this 
should not really be a major problem.


I am somewhat surprised that IBM does not have standard procedures / 
processes / Job in place to handle this including checking the hardware 
clock against an external source the same that Unix, Linux, Windows does 
even if it has to go through a inhouse Intranet server for security.





On 27/10/15 06:14, Paul Gilmartin wrote:

On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:

Since UNIX and Windows platforms handle DST by just forcing the local
time discontinuity, if an application has a problem with that, you don't
have a choice other than tolerating the result or trying to find and fix
any intolerable problems the discontinuity causes for the application.
I'm sure there are cases on those platforms where a rare "strangeness"
at time zone changes is just tolerated, since users in those environment
traditionally seem to expect a higher level of s--- happens and some
occasional apparent non-determinism..


I'm trying to imagine my UNIX-oriented colleagues' snickering at the
idea of shutting down a system at the DST transition.  When they
stopped giggling, I'd expect them to ask, "But which time zone; which
country?  All?  Northern or Southern Hemisphere?  Both?"  UNIX
systems run their system clocks on UTC and an input to localtime()
is a time zone chosen by the programmer.  It would be absurd to
expect an hour's outage for each of several dozen time zones in
the world.  z/OS has a peculiar tunnel vision in its belief that there
are only two time zones.

Leap seconds are a different issue.  z/OS shuts down all applications
during a leap second.  Google and Amazon both steer their clocks
slow (less than 0.01 percent) for several hours centered on a leap
second.  And the two have chosen different steering durations.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Jousma, David]

IBM does have standard procedures/process etc.   It is still up to the local 
system administrators to choose to use them.  We keep our time sync's via NTP 
from the HMC's to the hardware with STP.   There are facilities available today 
to automatically adjust the time.   It is just a hard historical holdback for 
many to allow that to happen - including us.

Short of just changing time, there really is no reason the process couldn’t be 
automated to make it hands off.

Using automation you could
- shutdown the apps that feel they can't tolerate the change
- drain batch (if needed)
- adjust the time
- perform any refresh commands (CICS is one)
- startup any shutdown apps.


At this day of age, there is NO REASON why an installation should continue to 
run with GMT=LOCAL.   GMT must be set to UTC, no if's ands or but's.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vince Coen
Sent: Tuesday, October 27, 2015 7:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

I would have thought that all these issues would have been easy to be resolved 
if all sites used UTC time on hardware level with the adjustment for local set 
up at the software level then it only requires simple job step to adjust if 
there is not one built in to the O/S.

Also and if needed that no job/processes was allowed to run over the time 
period of time change where such a process might get upset.

Let face it as clock change occurs for most of us on a Sunday this should not 
really be a major problem.

I am somewhat surprised that IBM does not have standard procedures / processes 
/ Job in place to handle this including checking the hardware clock against an 
external source the same that Unix, Linux, Windows does even if it has to go 
through a inhouse Intranet server for security.




On 27/10/15 06:14, Paul Gilmartin wrote:
> On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
>> Since UNIX and Windows platforms handle DST by just forcing the local 
>> time discontinuity, if an application has a problem with that, you 
>> don't have a choice other than tolerating the result or trying to 
>> find and fix any intolerable problems the discontinuity causes for the 
>> application.
>> I'm sure there are cases on those platforms where a rare "strangeness"
>> at time zone changes is just tolerated, since users in those 
>> environment traditionally seem to expect a higher level of s--- 
>> happens and some occasional apparent non-determinism..
>>
> I'm trying to imagine my UNIX-oriented colleagues' snickering at the 
> idea of shutting down a system at the DST transition.  When they 
> stopped giggling, I'd expect them to ask, "But which time zone; which 
> country?  All?  Northern or Southern Hemisphere?  Both?"  UNIX systems 
> run their system clocks on UTC and an input to localtime() is a time 
> zone chosen by the programmer.  It would be absurd to expect an hour's 
> outage for each of several dozen time zones in the world.  z/OS has a 
> peculiar tunnel vision in its belief that there are only two time 
> zones.
>
> Leap seconds are a different issue.  z/OS shuts down all applications 
> during a leap second.  Google and Amazon both steer their clocks slow 
> (less than 0.01 percent) for several hours centered on a leap second.  
> And the two have chosen different steering durations.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Ted MacNEIL]

What's so special about Sunday? I used to work for an international bank. 
Sunday. Was no excuse for an outage!

-
-teD
-
  Original Message  
From: Vince Coen
Sent: Tuesday, October 27, 2015 07:11
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

I would have thought that all these issues would have been easy to be 
resolved if all sites used UTC time on hardware level with
the adjustment for local set up at the software level then it only 
requires simple job step to adjust if there is not one built in to the O/S.

Also and if needed that no job/processes was allowed to run over the 
time period of time change where such a process might get upset.

Let face it as clock change occurs for most of us on a Sunday this 
should not really be a major problem.

I am somewhat surprised that IBM does not have standard procedures / 
processes / Job in place to handle this including checking the hardware 
clock against an external source the same that Unix, Linux, Windows does 
even if it has to go through a inhouse Intranet server for security.




On 27/10/15 06:14, Paul Gilmartin wrote:
> On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
>> Since UNIX and Windows platforms handle DST by just forcing the local
>> time discontinuity, if an application has a problem with that, you don't
>> have a choice other than tolerating the result or trying to find and fix
>> any intolerable problems the discontinuity causes for the application.
>> I'm sure there are cases on those platforms where a rare "strangeness"
>> at time zone changes is just tolerated, since users in those environment
>> traditionally seem to expect a higher level of s--- happens and some
>> occasional apparent non-determinism..
>>
> I'm trying to imagine my UNIX-oriented colleagues' snickering at the
> idea of shutting down a system at the DST transition. When they
> stopped giggling, I'd expect them to ask, "But which time zone; which
> country? All? Northern or Southern Hemisphere? Both?" UNIX
> systems run their system clocks on UTC and an input to localtime()
> is a time zone chosen by the programmer. It would be absurd to
> expect an hour's outage for each of several dozen time zones in
> the world. z/OS has a peculiar tunnel vision in its belief that there
> are only two time zones.
>
> Leap seconds are a different issue. z/OS shuts down all applications
> during a leap second. Google and Amazon both steer their clocks
> slow (less than 0.01 percent) for several hours centered on a leap
> second. And the two have chosen different steering durations.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Tom Marchant]

On Tue, 27 Oct 2015 09:55:58 -0500, Paul Gilmartin wrote:

>On Tue, 27 Oct 2015 09:35:34 -0500, Tom Marchant wrote:
>
>>D T operator command. 
>>In the response, "UTC time" is the value in the TOD clock. ...
>>
>Not adjusted by CVTLSO?

Probably. The point is that you can easily see the difference between 
"Local" and "UTC" or "GMT" time and determine whether the system is 
running with the TOD clock set to local time

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Mike Schwab]

The 24*7*365 companies have solved it.
Versus the 24*7*364.96 companies that haven't.


On Tue, Oct 27, 2015 at 10:14 AM, Ted MacNEIL  wrote:
> How about internationally?
> Not all companies close on weekends!
>
> -
> -teD
> -
>   Original Message
> From: Vince Coen
> Sent: Tuesday, October 27, 2015 08:54
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: Re: RE-IPL for the Daylight to Standard time conversion?
>
> Sunday is the *day *that clocks move forwards or back an hour or two.
> e.g., 02:00 etc.
>
> Hardly a heavy work load period unless it is a system upgrade day !
>
> On 27/10/15 11:35, Ted MacNEIL wrote:
>> What's so special about Sunday? I used to work for an international bank. 
>> Sunday. Was no excuse for an outage!
>>
>> -
>> -teD
>> -
>> Original Message
>> From: Vince Coen
>> Sent: Tuesday, October 27, 2015 07:11
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Reply To: IBM Mainframe Discussion List
>> Subject: Re: RE-IPL for the Daylight to Standard time conversion?
>>
>> I would have thought that all these issues would have been easy to be
>> resolved if all sites used UTC time on hardware level with
>> the adjustment for local set up at the software level then it only
>> requires simple job step to adjust if there is not one built in to the O/S.
>>
>> Also and if needed that no job/processes was allowed to run over the
>> time period of time change where such a process might get upset.
>>
>> Let face it as clock change occurs for most of us on a Sunday this
>> should not really be a major problem.
>>
>> I am somewhat surprised that IBM does not have standard procedures /
>> processes / Job in place to handle this including checking the hardware
>> clock against an external source the same that Unix, Linux, Windows does
>> even if it has to go through a inhouse Intranet server for security.
>>
>>
>>
>>
>> On 27/10/15 06:14, Paul Gilmartin wrote:
>>> On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
 Since UNIX and Windows platforms handle DST by just forcing the local
 time discontinuity, if an application has a problem with that, you don't
 have a choice other than tolerating the result or trying to find and fix
 any intolerable problems the discontinuity causes for the application.
 I'm sure there are cases on those platforms where a rare "strangeness"
 at time zone changes is just tolerated, since users in those environment
 traditionally seem to expect a higher level of s--- happens and some
 occasional apparent non-determinism..

>>> I'm trying to imagine my UNIX-oriented colleagues' snickering at the
>>> idea of shutting down a system at the DST transition. When they
>>> stopped giggling, I'd expect them to ask, "But which time zone; which
>>> country? All? Northern or Southern Hemisphere? Both?" UNIX
>>> systems run their system clocks on UTC and an input to localtime()
>>> is a time zone chosen by the programmer. It would be absurd to
>>> expect an hour's outage for each of several dozen time zones in
>>> the world. z/OS has a peculiar tunnel vision in its belief that there
>>> are only two time zones.
>>>
>>> Leap seconds are a different issue. z/OS shuts down all applications
>>> during a leap second. Google and Amazon both steer their clocks
>>> slow (less than 0.01 percent) for several hours centered on a leap
>>> second. And the two have chosen different steering durations.
>>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Paul Gilmartin]

On Tue, 27 Oct 2015 10:22:48 -0500, Tom Marchant wrote:

>On Tue, 27 Oct 2015 09:55:58 -0500, Paul Gilmartin wrote:
>
>>On Tue, 27 Oct 2015 09:35:34 -0500, Tom Marchant wrote:
>>
>>>D T operator command. 
>>>In the response, "UTC time" is the value in the TOD clock. ...
>>>
>>Not adjusted by CVTLSO?
>
>Probably. The point is that you can easily see the difference between 
>"Local" and "UTC" or "GMT" time and determine whether the system is 
>running with the TOD clock set to local time
>
Sigh.  I broke Robert's Rule, "State your question in the affirmative."
Do you mean, "Probably adjusted" or "Probably unadjusted"?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Mike Schwab]

One solution would be for them to create a new LPAR that runs on GMT.
Customers would be requested to move their apps to the new LPAR and
would benefit by non-disruptive DST changes.
Adjust LPARs as the workload balance changes (memory, processors).

On Tue, Oct 27, 2015 at 8:52 AM, Charles Mills  wrote:
>
>
> Thanks all. Failed to say that we did ask the service bureau why, and were 
> told "because of the time change. " You all have given me the knowledge 
> necessary to push back for a better answer.
> Summarizing, there are three possible reasons:
> 1. The hardware clock is set to local time and it is necessary to stop for an 
> hour to avoid duplicate timestamps.
> 2. There are one or more applications that use civil time, are difficult to 
> restart without an IPL, and have a  potential duplicate or incorrect time 
> problem.
> 3. Neither of the above, but operations management is in the habit of 
> behaving as though one or both were true.
> With regard to 1, this is less than a best practice, and should be relatively 
> easy to correct, as UTC is ahead of their local time and no duplicate times 
> eould result.
> 2 is more difficult. We are all familiar with unmaintainable applications. 
> Further, they are a service bureau and for all I know the application belongs 
> to their largest customer who has said "deal with it or we will find a 
> service bureau that can."
> With regard to 3, what can I say.
> Fair enough summary?
> CharlesSent from a mobile; please excuse the brevity
>
>  Original message 
> From: Vince Coen 
> Date: 10/27/2015  5:54 AM  (GMT-08:00)
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RE-IPL for the Daylight to Standard time conversion?
>
> Sunday is the *day *that clocks move forwards or back an hour or two.
> e.g., 02:00 etc.
>
> Hardly a heavy work load period unless it is a system upgrade day !
>
> On 27/10/15 11:35, Ted MacNEIL wrote:
>> What's so special about Sunday? I used to work for an international bank. 
>> Sunday. Was no excuse for an outage!
>>
>> -
>> -teD
>> -
>>Original Message
>> From: Vince Coen
>> Sent: Tuesday, October 27, 2015 07:11
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Reply To: IBM Mainframe Discussion List
>> Subject: Re: RE-IPL for the Daylight to Standard time conversion?
>>
>> I would have thought that all these issues would have been easy to be
>> resolved if all sites used UTC time on hardware level with
>> the adjustment for local set up at the software level then it only
>> requires simple job step to adjust if there is not one built in to the O/S.
>>
>> Also and if needed that no job/processes was allowed to run over the
>> time period of time change where such a process might get upset.
>>
>> Let face it as clock change occurs for most of us on a Sunday this
>> should not really be a major problem.
>>
>> I am somewhat surprised that IBM does not have standard procedures /
>> processes / Job in place to handle this including checking the hardware
>> clock against an external source the same that Unix, Linux, Windows does
>> even if it has to go through a inhouse Intranet server for security.
>>
>>
>>
>>
>> On 27/10/15 06:14, Paul Gilmartin wrote:
>>> On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
 Since UNIX and Windows platforms handle DST by just forcing the local
 time discontinuity, if an application has a problem with that, you don't
 have a choice other than tolerating the result or trying to find and fix
 any intolerable problems the discontinuity causes for the application.
 I'm sure there are cases on those platforms where a rare "strangeness"
 at time zone changes is just tolerated, since users in those environment
 traditionally seem to expect a higher level of s--- happens and some
 occasional apparent non-determinism..

>>> I'm trying to imagine my UNIX-oriented colleagues' snickering at the
>>> idea of shutting down a system at the DST transition. When they
>>> stopped giggling, I'd expect them to ask, "But which time zone; which
>>> country? All? Northern or Southern Hemisphere? Both?" UNIX
>>> systems run their system clocks on UTC and an input to localtime()
>>> is a time zone chosen by the programmer. It would be absurd to
>>> expect an hour's outage for each of several dozen time zones in
>>> the world. z/OS has a peculiar tunnel vision in its belief that there
>>> are only two time zones.
>>>
>>> Leap seconds are a different issue. z/OS shuts down all applications
>>> during a leap second. Google and Amazon both steer their clocks
>>> slow (less than 0.01 percent) for several hours centered on a leap
>>> second. And the two have chosen different steering durations.
>>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> 

PL/I and optional parameters

[Janet Graff]

I have a PL/I subroutine call that has 297 optional parameters.  That is the 
function has a parameter list with up to 100 tuples of parameters.  The first 
tuple is required, and tuple 2 through 100 are optional.

In C the function signature looks like this

int myFunc( int *numDescriptorEntries,
   int *numBufferEntries,
   char *errorBuffer,
   char *descriptor,
   char *Buffer,
   int  *Length,
   ...);

In PL/I I'd like to do this

   Declare myFunc External('VSHPARR') Entry(
   Fixed Bin(31) byaddr, /* Number of Descriptors */
   Fixed Bin(31) byaddr,/* Number of Entries */
   Char(*) byaddr,   /* Error msg buffer */
   Char (*) byaddr,   /* descriptor*/
   Char (*) byaddr,  /*Buffer */
   Fixed Bin(31) byaddr,  /*  Length */
* optional,
   )
   returns( byvalue Fixed Bin(31) )   /* Return code */
   options ( nodescriptor, linkage(system) );


But PL/I flags this call as an error because I need all three "*optional" 
declarations

   rc = myFunc (numDescriptorEntries,
numBufferEntries,
error,
Descriptor1,
Buffer1,
Length1,
Descriptor2,
Buffer2,
Length2);

Which means I have to declare this

   Declare myFunc External('VSHPARR') Entry(
   Fixed Bin(31) byaddr, /* Number of Descriptors */
   Fixed Bin(31) byaddr,/* Number of Entries */
   Char(*) byaddr,   /* Error msg buffer */
   Char (*) byaddr,   /* descriptor*/
   Char (*) byaddr,  /*Buffer */
   Fixed Bin(31) byaddr,  /*  Length */
* optional,
* optional,
* optional
   )
   returns( byvalue Fixed Bin(31) )   /* Return code */
   options ( nodescriptor, linkage(system) );

So for 100 repeats of the tuple, this function declaration is going to get 
quite lengthy with loads of "* optional" parameters.
Is there a shorter way of declaring 297 optional parameters in PL/I?

Thank you!
Janet

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Vince Coen]

Never said close but workload is usually a lot lower - excluding bank 
system running ATM's etc.
In which case you have to work with other strategies and that depends on 
what/when etc.


However all that it is pointed out to ensure that system uses UTC time 
and that ALL logging for all and that means both system and application 
s/w uses it and just adjusts if local time is really required.


In the various shops / sites I have worked in and that includes a lot 
when working as a freelance / contractor most if not all used UTC and 
yes in the UK we have summer time which is +1 so software has to deal 
with that.


Should point out that even bank system running ATM's have procedures in 
place for maintenance of any kind that needs to occur even if the have 
secondary system in use as parallel processing & backup.


Heck what banks only use one mainframe these days and here I will 
exclude Barclay's RBS etc, that seem to do updates over a w/e and manage 
to break the system stopping customers getting their cash.


Here I just blame very poor system testing - but I would as a Test 
Manager (among other roles). Absolutely no excuse of it and banks can 
afford to have back up systems run in parallel along with a m/f used for 
testing and development.


Sorry my age is showing ...



.On 27/10/15 15:14, Ted MacNEIL wrote:

How about internationally?
Not all companies close on weekends!

-
-teD
-
   Original Message
From: Vince Coen
Sent: Tuesday, October 27, 2015 08:54
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

Sunday is the *day *that clocks move forwards or back an hour or two.
e.g., 02:00 etc.

Hardly a heavy work load period unless it is a system upgrade day !

On 27/10/15 11:35, Ted MacNEIL wrote:

What's so special about Sunday? I used to work for an international bank. 
Sunday. Was no excuse for an outage!

-
-teD
-
Original Message
From: Vince Coen
Sent: Tuesday, October 27, 2015 07:11
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

I would have thought that all these issues would have been easy to be
resolved if all sites used UTC time on hardware level with
the adjustment for local set up at the software level then it only
requires simple job step to adjust if there is not one built in to the O/S.

Also and if needed that no job/processes was allowed to run over the
time period of time change where such a process might get upset.

Let face it as clock change occurs for most of us on a Sunday this
should not really be a major problem.

I am somewhat surprised that IBM does not have standard procedures /
processes / Job in place to handle this including checking the hardware
clock against an external source the same that Unix, Linux, Windows does
even if it has to go through a inhouse Intranet server for security.




On 27/10/15 06:14, Paul Gilmartin wrote:

On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:

Since UNIX and Windows platforms handle DST by just forcing the local
time discontinuity, if an application has a problem with that, you don't
have a choice other than tolerating the result or trying to find and fix
any intolerable problems the discontinuity causes for the application.
I'm sure there are cases on those platforms where a rare "strangeness"
at time zone changes is just tolerated, since users in those environment
traditionally seem to expect a higher level of s--- happens and some
occasional apparent non-determinism..


I'm trying to imagine my UNIX-oriented colleagues' snickering at the
idea of shutting down a system at the DST transition. When they
stopped giggling, I'd expect them to ask, "But which time zone; which
country? All? Northern or Southern Hemisphere? Both?" UNIX
systems run their system clocks on UTC and an input to localtime()
is a time zone chosen by the programmer. It would be absurd to
expect an hour's outage for each of several dozen time zones in
the world. z/OS has a peculiar tunnel vision in its belief that there
are only two time zones.

Leap seconds are a different issue. z/OS shuts down all applications
during a leap second. Google and Amazon both steer their clocks
slow (less than 0.01 percent) for several hours centered on a leap
second. And the two have chosen different steering durations.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Vince Coen]

The term GMT has been replaced with UTC (from the French and translated 
to Coordinated Universal Time) but it is the same thing.


GMT these days refers to a very few countries and here is an noted 
explanation:




Coordinated Universal Time (UTC) is the basis for civil time today. This 
24-hour time standard is kept using highly precise atomic clocks 
combined with the Earth's rotation.



   A Standard, Not a Time Zone

UTC is the time standard commonly used across the world. The world's 
timing centers have agreed to keep their time scales closely 
synchronized - or coordinated - therefore the name Coordinated Universal 
Time.



   Atomic and Solar Time

Two components are used to determine UTC:

 * *International Atomic Time* (TAI)
   : A
   time scale that combines the output of some 400 highly precise
   atomic clocks worldwide, and provides the exact speed for our clocks
   to tick.
 * *Universal Time* (UT1), also known as astronomical time or solar
   time, refers to the Earth's rotation. It is used to compare the pace
   provided by TAI with the actual length of a day on Earth
   .


   UT Started in 1884

Universal Time (UT) was created at the Washington Meridian Conference in 
1884. This is the basis for the 24-hour time zone system we know today.


At the time, Greenwich Mean Time (GMT) was chosen as the world’s time 
standard. The reference line or starting point, the Prime Meridian, was 
determined to be the transit circle at the Royal Observatory in 
Greenwich, London. The transit circle is a part of the telescope's 
mechanics and it is still cited as the Prime Meridian's original reference.



From GMT to UTC

In 1960, the International Radio Consultative Committee formalized the 
concept of UTC, and it was put into practice the year after. The name 
Coordinated Universal Time was officially adopted in 1967.


Why UTC – not CUT or TUC? 



UTC was adjusted several times until 1972, when leap seconds 
 were introduced to 
keep UTC in line with the Earth's rotation, which is not entirely even, 
and less exact than atomic clocks.



   GMT is now a Time Zone

Until 1972, Greenwich Mean Time (also known as Zulu time 
) was the same as Universal 
Time (UT).


The difference between GMT and UTC 



Since then, GMT is no longer a time standard. Today, Greenwich Mean Time 
 is only the name of a time 
zone that is used by a few countries in Africa and Western Europe, 
including the UK during winter 
 and all year 
in Iceland. 




Above comes from url - http://www.timeanddate.com/time/aboututc.html


V.


On 27/10/15 15:20, Mike Schwab wrote:

One solution would be for them to create a new LPAR that runs on GMT.
Customers would be requested to move their apps to the new LPAR and
would benefit by non-disruptive DST changes.
Adjust LPARs as the workload balance changes (memory, processors).

On Tue, Oct 27, 2015 at 8:52 AM, Charles Mills  wrote:


Thanks all. Failed to say that we did ask the service bureau why, and were told 
"because of the time change. " You all have given me the knowledge necessary to 
push back for a better answer.
Summarizing, there are three possible reasons:
1. The hardware clock is set to local time and it is necessary to stop for an 
hour to avoid duplicate timestamps.
2. There are one or more applications that use civil time, are difficult to 
restart without an IPL, and have a  potential duplicate or incorrect time 
problem.
3. Neither of the above, but operations management is in the habit of behaving 
as though one or both were true.
With regard to 1, this is less than a best practice, and should be relatively 
easy to correct, as UTC is ahead of their local time and no duplicate times 
eould result.
2 is more difficult. We are all familiar with unmaintainable applications. Further, they 
are a service bureau and for all I know the application belongs to their largest customer 
who has said "deal with it or we will find a service bureau that can."
With regard to 3, what can I say.
Fair enough summary?
CharlesSent from a mobile; please excuse the brevity

 Original message 
From: Vince Coen 
Date: 10/27/2015  5:54 AM  (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

Sunday is the *day *that clocks move forwards or back an hour or two.
e.g., 02:00 etc.

Hardly a heavy work load period unless it is a system upgrade day !

On 27/10/15 11:35, Ted 

Re: RE-IPL for the Daylight to Standard time conversion?

[Paul Gilmartin]

On Tue, 27 Oct 2015 18:17:25 +, Vince Coen wrote:

>The term GMT has been replaced with UTC (from the French and translated
>to Coordinated Universal Time) but it is the same thing.
>
>GMT these days refers to a very few countries ...
>
So except in those very few countries it's incorrect to say "GMT=LOCAL".
It's certainly incorrect in the United States.  And if a site runs its (E)TOD
clock on local time, TIME TZ=GMT will give incorrect results except in those
few countries.

And IBM is entitled to say, "You broke it; we don't have to fix it."

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Paul Gilmartin]

On 2015-10-26 17:25, Tim Brown wrote:
> How does one handle a 1 hour back time change within a monoplex or sysplex. 
> We have always had in issue with the SYS1 xcf , wlm and logr files and the 
> fall time change. We just shutdown, wait one hour and come back up.
> 
> I would like to see how others handle this!
> 
Keep timestamps in GMT/UTC or POSIX format?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create zIIP workload

[Tony Thigpen]

IBM's big issue with Neon zPrime was because it allowed people to run 
work from other vendors on zIIPs.


If you (as a licensed vendor) have authorization to run your code on 
zIIPs, and another vendor gives you a letter saying 'Yes, you can call 
my software from a zIIP', then again IBM is not concerned. Now, the 
chances of you getting that letter from the 'other guy' which charges a 
flat fee, is fairly good, but the chance of you getting that letter from 
someone like Adabas or CA which charge based on MSUs is 'slim to none'.


On the reverse side, if your software running on a zIIP calls Adabas, 
and you don't have a letter of agreement from them, IBM will use it's 
big boot to make sure you stop. That was the Neon zPrime issue.


Tony Thigpen

Paul Gilmartin wrote on 10/26/2015 10:45 AM:

On Mon, 26 Oct 2015 08:27:29 -0400, Tony Thigpen wrote:


It has to do with how the other guy prices his software. For example, if
he is mips based on a specific box, and you then start running his
software on a much faster zIIP, he would be loosing revenue and the
customer could be in violation of the use agreement.


I see.  But if the "other guy" charges a flat rate or even supplies FOSS
and doesn't care, this creates a side door to the zIIP and I'd expect
IBM to care, as IBM surely cared about Neon zPrime.



On Sun, 25 Oct 2015 20:53:13 -0400, Peter Relson wrote:


Once properly licensed, I believe that there is very little of your own
code that you are not allowed to make zIIP eligible.

The main thing that you are not allowed to do is to make someone else's
code zIIP-eligible (which includes calling them from a zIIP-eligible
state), without their approval.


-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ServerPac install

[Mark Pace]

I'm confused, nothing new, about installing via FSR.  Running the ALLOCDS
job.
READY
 PROFILE PREFIX(MARPACE) MSGID
READY
 ISPSTART CMD(%CPPEDSN NOTEXIST F )
IKJ56225I DATA SET SYS1.TSTZOS.HZSPDATA ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IKJ56225I DATA SET OMVS.SCFZHFS2 ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IKJ56225I DATA SET OMVS.SIGYROOT ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IKJ56225I DATA SET FNT.OMVS.HFS ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
ISPD117

So the manual says:
If the step fails then you must remove the user defined data set(s) which
are in
driving system master catalog from the configuration by going into Modify
System Layout panel, delete the data set(s) and then regenerate the install
jobs
by running GENSKEL job or using line command 'S' to select the install job.

So IF I go back and remove these datasets - How do they get defined on the
Target System?
I must be overlooking something fairly obvious.

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

I am looking for a new contract/job

[Binyamin Dissen]

As a long time member of this group, I hope I will not receive objections for
this personal ad.

I am looking for something where I can work remote most of the time from
Israel. Probably best with a software vendor.

I have more than 20 years of commercial systems software development, mostly
in assembler. Expert experience with AR mode, 64bit, FRRs, PCs, system exits,
SRBs, etc. Experience with hooking into MVS as well as CICS and DB2. 

Thank you.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ServerPac install

[Richard Pinion]

I'm just completing the z/OS 2.2 ServerPac install, and
everything is relatively smooth.  I only defined one
catalog, the new master.  The only problem I had was
with the new ZFS data sets.  Using the SSA of Z220
appended to the standard names, gave me fits, as the
ZFS format steps failed, stating the aggregate was not
found.  Turns out, the ZFS address space did not have access
to Z220.**.  The ServerPac generated job used the program
IOEAGFMT, which causes the ZFS address space to do the
work.  I didn't see any RACF violations in the joblog
of the job I submitted.  But after a couple of hours
I noticed the violations in syslog, and ultimately 
in the ZFS joblog.  Updated my RACF data set profile
for Z220.**, IPL'ed to cycle ZFS, and it worked fine.



--- 008d52e04f2e-dmarc-requ...@listserv.ua.edu wrote:

From: william janulin <008d52e04f2e-dmarc-requ...@listserv.ua.edu>
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ServerPac install
Date: Tue, 27 Oct 2015 22:39:12 +

Oh, don't get me started on Serverpac. I am wrestling with it altering dataset 
names and defining paths. When I try anOMVS MOUNT on the renamed dataset, it 
does not find it.That plus the way they describe defining catalogs is 
ludicrous. It is hard to tell where you should use a user catalog as oppposed 
to the Master catalog. Needless to say, I have a PMR open with IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 




_
Netscape.  Just the Net You Need.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ServerPac install

[william janulin]

Oh, don't get me started on Serverpac. I am wrestling with it altering dataset 
names and defining paths. When I try anOMVS MOUNT on the renamed dataset, it 
does not find it.That plus the way they describe defining catalogs is 
ludicrous. It is hard to tell where you should use a user catalog as oppposed 
to the Master catalog. Needless to say, I have a PMR open with IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 

Re: RE-IPL for the Daylight to Standard time conversion?

[Shmuel Metz (Seymour J.)]

In <562f5be4.8080...@gmail.com>, on 10/27/2015
   at 11:11 AM, Vince Coen  said:

>checking the hardware  clock against an external source

That wasn't originally part of STP, but it's been available for a long
time. 

You can handle shutting down and restarting applications through your
automation software. I don'[t see how IBM could do it automatically:
they don't know what applications at your shop can't tolerate
overlapping local times.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: I am looking for a new contract/job

[Lizette Koehler]

So do you go to the vendor sites you are interested in at look at their opening?

Or check out SPCI.NET, INDEED.COM, DICE.com, Monster.com

And if you use LINKEDIN, then start hooking up with the HR folks or others are 
the companies you are interested in.

Places like SYNCSORT, COMPUWARE, CA, IBM, etc

Most hiring managers probably do not subscribe to these lists.



Lizette



-Original Message-
>From: Binyamin Dissen 
>Sent: Oct 27, 2015 3:54 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: I am looking for a new contract/job
>
>As a long time member of this group, I hope I will not receive objections for
>this personal ad.
>
>I am looking for something where I can work remote most of the time from
>Israel. Probably best with a software vendor.
>
>I have more than 20 years of commercial systems software development, mostly
>in assembler. Expert experience with AR mode, 64bit, FRRs, PCs, system exits,
>SRBs, etc. Experience with hooking into MVS as well as CICS and DB2. 
>
>Thank you.
>
>--
>Binyamin Dissen 
>http://www.dissensoftware.com
>
>Director, Dissen Software, Bar & Grill - Israel
>
>
>Should you use the mailblocks package and expect a response from me,
>you should preauthorize the dissensoftware.com domain.
>
>I very rarely bother responding to challenge/response systems,
>especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: I am looking for a new contract/job

[michelbutz]

Each vendor ASG,SyncSort (in fact Chris B. Forgot his last name principle @ 
SyncSort said they were looking ) has careers would think with your experience 
they would take you with out question 
I'll be in Israel next May I am thinking of buying an apt in Jerusalem would 
like to make aliah retire there 

Sent from my iPhone

> On Oct 27, 2015, at 7:38 PM, Lizette Koehler  wrote:
> 
> So do you go to the vendor sites you are interested in at look at their 
> opening?
> 
> Or check out SPCI.NET, INDEED.COM, DICE.com, Monster.com
> 
> And if you use LINKEDIN, then start hooking up with the HR folks or others 
> are the companies you are interested in.
> 
> Places like SYNCSORT, COMPUWARE, CA, IBM, etc
> 
> Most hiring managers probably do not subscribe to these lists.
> 
> 
> 
> Lizette
> 
> 
> 
> -Original Message-
>> From: Binyamin Dissen 
>> Sent: Oct 27, 2015 3:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: I am looking for a new contract/job
>> 
>> As a long time member of this group, I hope I will not receive objections for
>> this personal ad.
>> 
>> I am looking for something where I can work remote most of the time from
>> Israel. Probably best with a software vendor.
>> 
>> I have more than 20 years of commercial systems software development, mostly
>> in assembler. Expert experience with AR mode, 64bit, FRRs, PCs, system exits,
>> SRBs, etc. Experience with hooking into MVS as well as CICS and DB2. 
>> 
>> Thank you.
>> 
>> --
>> Binyamin Dissen 
>> http://www.dissensoftware.com
>> 
>> Director, Dissen Software, Bar & Grill - Israel
>> 
>> 
>> Should you use the mailblocks package and expect a response from me,
>> you should preauthorize the dissensoftware.com domain.
>> 
>> I very rarely bother responding to challenge/response systems,
>> especially those from irresponsible companies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: I am looking for a new contract/job

[william janulin]

I am looking as well, same scenario as Bin. Mostly mainframe support or 
mainframe pre/post sales support.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 

Re: I am looking for a new contract/job

[Binyamin Dissen]

Tried SPCI but they do not seem to want to bring my name since I am not living
in the US.

I hope some members of this list who know of open positions will bring it to
the attention of their management.

On Tue, 27 Oct 2015 16:38:54 -0700 Lizette Koehler 
wrote:

:>So do you go to the vendor sites you are interested in at look at their 
opening?
:>
:>Or check out SPCI.NET, INDEED.COM, DICE.com, Monster.com
:>
:>And if you use LINKEDIN, then start hooking up with the HR folks or others 
are the companies you are interested in.
:>
:>Places like SYNCSORT, COMPUWARE, CA, IBM, etc
:>
:>Most hiring managers probably do not subscribe to these lists.
:>
:>
:>
:>Lizette
:>
:>
:>
:>-Original Message-
:>>From: Binyamin Dissen 
:>>Sent: Oct 27, 2015 3:54 PM
:>>To: IBM-MAIN@LISTSERV.UA.EDU
:>>Subject: I am looking for a new contract/job
:>>
:>>As a long time member of this group, I hope I will not receive objections for
:>>this personal ad.
:>>
:>>I am looking for something where I can work remote most of the time from
:>>Israel. Probably best with a software vendor.
:>>
:>>I have more than 20 years of commercial systems software development, mostly
:>>in assembler. Expert experience with AR mode, 64bit, FRRs, PCs, system exits,
:>>SRBs, etc. Experience with hooking into MVS as well as CICS and DB2. 
:>>
:>>Thank you.
:>>
:>>--
:>>Binyamin Dissen 
:>>http://www.dissensoftware.com
:>>
:>>Director, Dissen Software, Bar & Grill - Israel
:>>
:>>
:>>Should you use the mailblocks package and expect a response from me,
:>>you should preauthorize the dissensoftware.com domain.
:>>
:>>I very rarely bother responding to challenge/response systems,
:>>especially those from irresponsible companies.
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Tom Marchant]

On Tue, 27 Oct 2015 06:52:46 -0700, Charles Mills wrote:

>possible reasons:
>1. The hardware clock is set to local time and it is necessary to 
>stop for an hour to avoid duplicate timestamps.

You can determine this yourself by issuing a D T operator command. 
In the response, "UTC time" is the value in the TOD clock. If you don't 
have the authority to do that, you can look at any SVC dump or 
SYSMDUMP with IPCS. Issue the IP ST SY command. "GMT" is the 
value in the TOD clock. There are probably lots of other ways.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create zIIP workload

[Peter Relson]

>Wouldn't IBM's approval be required also, or even instead?

I elieve that the extent of IBM's approval is intended to be identified in 
the license agreement.
Since that license agreement does not cover ISV's, in the absence of 
additional agreement, ISV billing is expected to remain unchanged (and 
therefore what you can do with respect to invoking ISV code from a 
zIIP-enabled work unit is limited).

Peter Relson
z/OS  Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Paul Gilmartin]

On 2015-10-27, at 05:24, Jousma, David wrote:

> IBM does have standard procedures/process etc.   It is still up to the local 
> system administrators to choose to use them.  We keep our time sync's via NTP 
> from the HMC's to the hardware with STP.   There are facilities available 
> today to automatically adjust the time.   It is just a hard historical 
> holdback for many to allow that to happen - including us.
> 
> Short of just changing time, there really is no reason the process couldn’t 
> be automated to make it hands off.
> 
> Using automation you could
> - shutdown the apps that feel they can't tolerate the change
> - drain batch (if needed)
> - adjust the time
> - perform any refresh commands (CICS is one)
> - startup any shutdown apps.
>  
Any discussion which mentions "changing" or "adjust" requires a
paradigm shift.  A proper implementation should have a function
that takes as input a system clock value and a time zone and returns
the corresponding civil time in that time zone.  For given
system clock and time zone inputs, that function should give
exactly the same value today that it will give a week from today.
nothing should need to change or be adjusted next Sunday.

This may have been the objective of STCKCONV and CONVTOD, but
they fall far short of it.  IBM refuses to document them.  I
suspect IBM is simply ashamed of their deficiencies.

> At this day of age, there is NO REASON why an installation should continue to 
> run with GMT=LOCAL.   GMT must be set to UTC, no if's ands or but's.
>  
Isn't GMT just an obsolete predecessor of UTC?  "GMT=LOCAL" is as
meaningless as saying "2+2=5" or "one mile is one kilometer."

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Dana Mitchell]

On Mon, 26 Oct 2015 23:25:36 +, Tim Brown  wrote:

>How does one handle a 1 hour back time change within a monoplex or sysplex. We 
>have always had in issue with the SYS1 xcf , wlm and logr files and the fall 
>time change. We just shutdown, wait one hour and come back up.
>

When you say 'monoplex or sysplex' do you mean system(s) without STP (or 
sysplex timers)?   At our DR site we have a single CEC that does not have STP.  
The hardware clock is still set to UTC, and the time change is accomplished by 
issuing SET TIMEZONE commands on each LPAR.

Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Charles Mills]

Thanks all. Failed to say that we did ask the service bureau why, and were told 
"because of the time change. " You all have given me the knowledge necessary to 
push back for a better answer. 
Summarizing, there are three possible reasons:
1. The hardware clock is set to local time and it is necessary to stop for an 
hour to avoid duplicate timestamps. 
2. There are one or more applications that use civil time, are difficult to 
restart without an IPL, and have a  potential duplicate or incorrect time 
problem. 
3. Neither of the above, but operations management is in the habit of behaving 
as though one or both were true.
With regard to 1, this is less than a best practice, and should be relatively 
easy to correct, as UTC is ahead of their local time and no duplicate times 
eould result.
2 is more difficult. We are all familiar with unmaintainable applications. 
Further, they are a service bureau and for all I know the application belongs 
to their largest customer who has said "deal with it or we will find a service 
bureau that can."
With regard to 3, what can I say.
Fair enough summary? 
CharlesSent from a mobile; please excuse the brevity

 Original message 
From: Vince Coen  
Date: 10/27/2015  5:54 AM  (GMT-08:00) 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RE-IPL for the Daylight to Standard time conversion? 

Sunday is the *day *that clocks move forwards or back an hour or two. 
e.g., 02:00 etc.

Hardly a heavy work load period unless it is a system upgrade day !

On 27/10/15 11:35, Ted MacNEIL wrote:
> What's so special about Sunday? I used to work for an international bank. 
> Sunday. Was no excuse for an outage!
>
> -
> -teD
> -
>    Original Message
> From: Vince Coen
> Sent: Tuesday, October 27, 2015 07:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: Re: RE-IPL for the Daylight to Standard time conversion?
>
> I would have thought that all these issues would have been easy to be
> resolved if all sites used UTC time on hardware level with
> the adjustment for local set up at the software level then it only
> requires simple job step to adjust if there is not one built in to the O/S.
>
> Also and if needed that no job/processes was allowed to run over the
> time period of time change where such a process might get upset.
>
> Let face it as clock change occurs for most of us on a Sunday this
> should not really be a major problem.
>
> I am somewhat surprised that IBM does not have standard procedures /
> processes / Job in place to handle this including checking the hardware
> clock against an external source the same that Unix, Linux, Windows does
> even if it has to go through a inhouse Intranet server for security.
>
>
>
>
> On 27/10/15 06:14, Paul Gilmartin wrote:
>> On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
>>> Since UNIX and Windows platforms handle DST by just forcing the local
>>> time discontinuity, if an application has a problem with that, you don't
>>> have a choice other than tolerating the result or trying to find and fix
>>> any intolerable problems the discontinuity causes for the application.
>>> I'm sure there are cases on those platforms where a rare "strangeness"
>>> at time zone changes is just tolerated, since users in those environment
>>> traditionally seem to expect a higher level of s--- happens and some
>>> occasional apparent non-determinism..
>>>
>> I'm trying to imagine my UNIX-oriented colleagues' snickering at the
>> idea of shutting down a system at the DST transition. When they
>> stopped giggling, I'd expect them to ask, "But which time zone; which
>> country? All? Northern or Southern Hemisphere? Both?" UNIX
>> systems run their system clocks on UTC and an input to localtime()
>> is a time zone chosen by the programmer. It would be absurd to
>> expect an hour's outage for each of several dozen time zones in
>> the world. z/OS has a peculiar tunnel vision in its belief that there
>> are only two time zones.
>>
>> Leap seconds are a different issue. z/OS shuts down all applications
>> during a leap second. Google and Amazon both steer their clocks
>> slow (less than 0.01 percent) for several hours centered on a leap
>> second. And the two have chosen different steering durations.
>>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Tim Brown]

Yes, systems without STP, we also have similar DR site, I can test this.

I was always concerned since we have Adabas and wasn’t sure how transaction 
logs (PLOGS)  would be affected.

Tim

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Tuesday, 27 October, 2015 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

On Mon, 26 Oct 2015 23:25:36 +, Tim Brown  wrote:

>How does one handle a 1 hour back time change within a monoplex or sysplex. We 
>have always had in issue with the SYS1 xcf , wlm and logr files and the fall 
>time change. We just shutdown, wait one hour and come back up.
>

When you say 'monoplex or sysplex' do you mean system(s) without STP (or 
sysplex timers)?   At our DR site we have a single CEC that does not have STP.  
The hardware clock is still set to UTC, and the time change is accomplished by 
issuing SET TIMEZONE commands on each LPAR.

Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RE-IPL for the Daylight to Standard time conversion?

[Blake, Daniel J [CTR]]

My two-cents.

I've worked in many sites with different takes on this.  

Some only IPL twice a year, for the time change.  They recognized it wasn't a 
requirement for the IPL, but continued to schedule it for 'clean-up' purposes.  
The time change gave them an excuse for the IPL.

I've also worked at sites who schedule monthly IPLs.  They will schedule the 
time change to coincide with the IPL, also for 'clean-up' and to implement 
changes.  They stuck to that sehedule so that the user community expects a 
monthly outage.

And then there are the sites that IPL weekly.  Once again they recognize it is 
not always needed but offers a chance for changes to be implemented if needed.  
They will take advantage of the fall-back to shutdown realtimes for a full 
hour.  One site was very concerned about overlapping timestamps in IDMS 
impacting forward recovery, even though I never saw a need for an actual 
forward recovery situation at that site and CA well documented a work-around.


Dan


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, October 27, 2015 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RE-IPL for the Daylight to Standard time conversion?



Thanks all. Failed to say that we did ask the service bureau why, and were told 
"because of the time change. " You all have given me the knowledge necessary to 
push back for a better answer. Summarizing, there are three possible reasons:
1. The hardware clock is set to local time and it is necessary to stop for an 
hour to avoid duplicate timestamps. 2. There are one or more applications that 
use civil time, are difficult to restart without an IPL, and have a  potential 
duplicate or incorrect time problem. 3. Neither of the above, but operations 
management is in the habit of behaving as though one or both were true.
With regard to 1, this is less than a best practice, and should be relatively 
easy to correct, as UTC is ahead of their local time and no duplicate times 
eould result.
2 is more difficult. We are all familiar with unmaintainable applications. 
Further, they are a service bureau and for all I know the application belongs 
to their largest customer who has said "deal with it or we will find a service 
bureau that can."
With regard to 3, what can I say.
Fair enough summary?
CharlesSent from a mobile; please excuse the brevity

 Original message 
From: Vince Coen 
Date: 10/27/2015  5:54 AM  (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RE-IPL for the Daylight to Standard time conversion? 

Sunday is the *day *that clocks move forwards or back an hour or two. 
e.g., 02:00 etc.

Hardly a heavy work load period unless it is a system upgrade day !

On 27/10/15 11:35, Ted MacNEIL wrote:
> What's so special about Sunday? I used to work for an international bank. 
> Sunday. Was no excuse for an outage!
>
> -
> -teD
> -
>    Original Message
> From: Vince Coen
> Sent: Tuesday, October 27, 2015 07:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: Re: RE-IPL for the Daylight to Standard time conversion?
>
> I would have thought that all these issues would have been easy to be 
> resolved if all sites used UTC time on hardware level with the 
> adjustment for local set up at the software level then it only 
> requires simple job step to adjust if there is not one built in to the O/S.
>
> Also and if needed that no job/processes was allowed to run over the 
> time period of time change where such a process might get upset.
>
> Let face it as clock change occurs for most of us on a Sunday this 
> should not really be a major problem.
>
> I am somewhat surprised that IBM does not have standard procedures / 
> processes / Job in place to handle this including checking the 
> hardware clock against an external source the same that Unix, Linux, 
> Windows does even if it has to go through a inhouse Intranet server for 
> security.
>
>
>
>
> On 27/10/15 06:14, Paul Gilmartin wrote:
>> On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
>>> Since UNIX and Windows platforms handle DST by just forcing the 
>>> local time discontinuity, if an application has a problem with that, 
>>> you don't have a choice other than tolerating the result or trying 
>>> to find and fix any intolerable problems the discontinuity causes for the 
>>> application.
>>> I'm sure there are cases on those platforms where a rare "strangeness"
>>> at time zone changes is just tolerated, since users in those 
>>> environment traditionally seem to expect a higher level of s--- 
>>> happens and some occasional apparent non-determinism..
>>>
>> I'm trying to imagine my UNIX-oriented colleagues' snickering at the 
>> idea of shutting down a system at the DST transition. When they 
>> stopped giggling, I'd expect them to ask, "But which time zone; which 
>> country? All? Northern or Southern Hemisphere? Both?" UNIX