On 2017-06-21 15:50, Tony Harminc wrote:
Muphry's law?
^ Murphy's Law in action.
Not this time, at least not yet. Muphry's is rather more specific
than Murphy's.
https://en.wikipedia.org/wiki/Muphry's_law
[typing very carefully] Interesting...thanks!
--
Regards, Gord Tomlin
Action Softwar
On 21 June 2017 at 14:10, Gord Tomlin wrote:
> On 2017-06-21 11:58, Tony Harminc wrote:
>>
>> Muphry's law?
>
> ^ Murphy's Law in action.
Not this time, at least not yet. Muphry's is rather more specific
than Murphy's.
https://en.wikipedia.org/wiki/Muphry's_law
Tony H.
---
ubject: Re: Store Clock Fast really can give duplicates
On 2017-06-21 11:58, Tony Harminc wrote:
> Muphry's law?
^ Murphy's Law in action.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-71
On 2017-06-21 11:58, Tony Harminc wrote:
Muphry's law?
^ Murphy's Law in action.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
--
Fo
Tony Harminc wrote:
>Or "trying to test STCKF and compare it to STCK"?
Sigh, yes. ONE OF THOSE! (Thanks for catching that. Must be a Monday.)
"220, 221, whatever it takes..."
--
For IBM-MAIN subscribe / signoff / archive access
On 21 June 2017 at 11:20, Phil Smith wrote:
> Of course I meant "trying to test STCKE and compare it to STCK".
Or "trying to test STCKF and compare it to STCK"?
Muphry's law? (No, I did *not* mean...)
Tony H.
--
For IBM-MAIN s
Of course I meant "trying to test STCKE and compare it to STCK".
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Tuesday, June 20, 2017 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Store Clock Fast really can give duplicates
On Tue, 20 Jun 2017 14:27:33 -0400, Tony Harminc wrote:
>There's a recent CICS APAR PI82188 that showed
Paul Gilmartin wrote:
>>If you're one in a million, and you live in a city of three million people...
>It may be far worse than that: https://en.wikipedia.org/wiki/Birthday_problem
Hm? This isn't the same thing, it's a monotonically increasing counter. It's
just a question of whether things are
On 20 June 2017 at 14:50, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> I've always thought of STCKF clashes as a
>>theoretical problem not likely to be encountered in one's lifetime.
>>The APAR description suggests, without clearly saying so, that this
>>has happened at
@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Tuesday, June 20, 2017 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Store Clock Fast really can give duplicates
On Tue, 20 Jun 2017 14:27:33 -0400, Tony Harminc wrote:
>There's a recent CICS APAR PI82188 that showed up in my R
On Tue, 20 Jun 2017 14:27:33 -0400, Tony Harminc wrote:
>There's a recent CICS APAR PI82188 that showed up in my Red Alert ...
>
>STCKF and friends have been discussed here and/or the assembler list
>in recent years, but I've always thought of STCKF clashes as a
>theoretical problem not likely to
Interesting.
ObAnecdote: I was trying to test STCK a couple of years ago, and compare it to
STCK. I ran a loop of 1M STCKs and another of STCKFs, and found that STCKF was
way *slower*. This was on a zPDT; IBM said "Ooops" and wrote a fix.
--
...phsiii
Phil Smith III
Senior Architect & Product
There's a recent CICS APAR PI82188 that showed up in my Red Alert
feed. Evidently CICS was using STCKF to obtain a "unique" value as a
Unit Of Work (UOW) identifier, and once in a while two STCKFs returned
the same value, with Very Bad consequences. The fix is to change it
(back, by the sound of th
14 matches
Mail list logo
