Time waits for no one: 'leap seconds' may be cut
http://www.pcworld.idg.com.au/article/358024/time_waits_no_one_leap_seconds_may_cut/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: O/T IBM to Ship World's Fastest Computer Chip
--- On Fri, 9/3/10, Rick Fochtman rfocht...@ync.net wrote: From: Rick Fochtman rfocht...@ync.net Subject: Re: O/T IBM to Ship World's Fastest Computer Chip To: IBM-MAIN@bama.ua.edu Date: Friday, September 3, 2010, 2:08 PM --snip- Model 91, the high-end of IBM s popular System/360 family, Faux news seems to have written the 360/95 and 360/195 out of History. ---unsnip--- When have you EVER heard of a reporter that knew what he was talking about? Or an editor? Rick Rick: That is almost a guarentee. Two weeks ago an article appeared in one of the bristish computer rags. The author said that there was no need for more than 1 engine as the languages (2 or 3 mentioned) could not take advantage of more than one. While that is somewhat true the authore had no idea of MVS let alone WLM or any concept of the MVS operating system. This was a authorative author:.I wrote back and suggested he get some experiance under his belt before trying to write another article. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where doc for STORAGE LINKAGE=SYSTEM
At 09:26 -0700 on 09/02/2010, Edward Jaffe wrote about Re: Where doc for STORAGE LINKAGE=SYSTEM: We've been burned by that unintuitive CALLRKY= default more than once. Theoretically there is a solution. Add a CALLERKEY= Parm and have it checked for first. If it is set then in that path check for CALLRKY and MNOTE if both defined and has a different value (otherwise ignore the CALLRKY). If CALLERKEY has not been used then do the normal check for CALLRKY. There have been other depreciated parms that have been handled this way if I remember correctly. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where doc for STORAGE LINKAGE=SYSTEM
On 9/5/2010 2:51 AM, Robert A. Rosenberg wrote: At 09:26 -0700 on 09/02/2010, Edward Jaffe wrote about Re: Where doc for STORAGE LINKAGE=SYSTEM: We've been burned by that unintuitive CALLRKY= default more than once. Theoretically there is a solution. Add a CALLERKEY= Parm and have it checked for first. If it is set then in that path check for CALLRKY and MNOTE if both defined and has a different value (otherwise ignore the CALLRKY). If CALLERKEY has not been used then do the normal check for CALLRKY. There have been other depreciated parms that have been handled this way if I remember correctly. I wasn't clear. We weren't burned because the CALLRKY= keyword has no vowels. We were burned by the unexpected fact that the STORAGE OBTAIN service assigns key zero (by default) to storage acquired from key-specifiable subpools, thus requiring explicit specification of CALLRKY=YES in nearly every case. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
isolating sensitive data in coupling facility
Date:Fri, 3 Sep 2010 13:40:26 -0500 From:Walt Farrell wfarr...@us.ibm.com Subject: Re: isolating sensitive data in coupling facility Hello Walt- Actually this is it: it would exist somewhere an internal standard that used to prohibit highly sensitive data to coexist with lower classification ones on the same DASD. Hence my first attempt to map this restriction to the coupling facility technology. Now, as I said in another post: we are at a very early and foggy stage of the project and we did not get in touch yet with the clients's actual summit of the Security pyramid, where such standards would have been distilled from. I hope that we get a more precise view of this all within the next few weeks, and I may then come back posting again. Thanks a lot On Tue, 31 Aug 2010 10:43:55 -0500, Patrick Kappeler pkappe...@wanadoo.fr wrote: Thank you Radoslaw, interesting indeed, and unquestionable, viewpoint. In fact we are foreseeing some restrictions, brought by some standards, that would prohibit data with different security classes to reside in the same storage device. And how do they define a storage device, Patrick? The only time I've seen regulations like that it was intended for DASD volumes, though I can't pretend to have seen all such standards, of course. But it sounds like some kind of restriction based on a perceived problem, but where they are not telling you the problem they're trying to resolve. -- Walt Farrell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: where doc for STORAGE LINKAGE=SYSTEM
Edward Jaffe wrote: begin snippet I wasn't clear. We weren't burned because the CALLRKY= keyword has no vowels. We were burned by the unexpected fact that the STORAGE OBTAIN service assigns key zero (by default) to storage acquired from key-specifiable subpools, thus requiring explicit specification of CALLRKY=YES in nearly every case. /end snippet In such circumstances a usually innocuous framing macro can be used, as in | macro | STORAGE@ CALLRKY=YES, . . . | . . . | STORAGE CALLRKY=CALLRKY, . . . | . . . | mend to provide oneself with more congenial defaults without depriving someone else of the freedom to code something like | STORAGE@ CALLRKY=NO, . . . John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: O/T IBM to Ship World's Fastest Computer Chip
Shmuel Metz (Seymour J.) wrote: In 4c8147a8.7050...@ync.net, on 09/03/2010 at 02:08 PM, Rick Fochtman rfocht...@ync.net said: When have you EVER heard of a reporter that knew what he was talking about? Or an editor? I could probably name half a dozen; I certainly couldn't name a dozen. My father (zl) would kill a story if he couldn't verify every claim in it. I sometimes refer to him as The last of the journalists. - I'll give you another oxymoron: journalistic integrity Today, it's becoming rarer and rarer and I suspect will die out completely in our lifetimes. :-( Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Code names for zSeries
John McKown wrote: On Sat, 2010-09-04 at 16:04 -0700, Edward Jaffe wrote: On 9/3/2010 2:46 PM, Phil Smith wrote: Well, as of z9, they were System z, not zSeries, but: z900 - Freeway z800 - Raptor z990 - T-Rex z890 - Ptero z9 - Danu z10 - can't remember z196 - Gryphon aka zNext zNext is just the external name for the next hardware generation. All System z processors are zNext at some point. The next one after that is zFuture. For use on Fantasy Island, there is no-frills machine called zPlain! Don't yell at me. I'm ill. You sure are !!! :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
isolating sensitive data in coupling facility
Thanks all for your enlightening answers -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: O/T IBM to Ship World's Fastest Computer Chip
Rick Fochtman wrote: I'll give you another oxymoron: journalistic integrity Today, it's becoming rarer and rarer and I suspect will die out completely in our lifetimes. :-( Now, now. Lumping all journalists in one boat is as unfair as putting all computers into the same category. Some of us go to a fair amount of trouble to verify everything we write about. Having said that, I'll agree that *every* mainstream news story of which I've ever had first-hand knowledge got several significant and important facts wrong, such as names, ages, and confusing an employment address with a home address. Whether that's incompetence or just the rush to publish is unclear. None of them were malicious -- none of them improved (or hurt) the story for anyone who didn't already know those facts -- but it does speak to a certain lack of verification. ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Datamation issue coining term nybble?
Shmuel Metz asked: Does anybody still have the issue of Datamation coining the term nybble? What have you heard or what do you know about that story? -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: O/T IBM to Ship World's Fastest Computer Chip
On 09/05/2010 02:25 PM, Phil Smith III wrote: Rick Fochtman wrote: I'll give you another oxymoron: journalistic integrity Today, it's becoming rarer and rarer and I suspect will die out completely in our lifetimes. :-( Now, now. Lumping all journalists in one boat is as unfair as putting all computers into the same category. Some of us go to a fair amount of trouble to verify everything we write about. Having said that, I'll agree that *every* mainstream news story of which I've ever had first-hand knowledge got several significant and important facts wrong, such as names, ages, and confusing an employment address with a home address. Whether that's incompetence or just the rush to publish is unclear. None of them were malicious -- none of them improved (or hurt) the story for anyone who didn't already know those facts -- but it does speak to a certain lack of verification. ...phsiii I suspect the original sentiment was prompted by so many on cable news and talk shows that like to classify themselves as journalists when all they do is report the latest rumour without analysis as to validity, or referee opposing speakers as if all sides of an argument have equal validity. Not that infrequently these days, one side of an argument is just flat-out wrong and should be reported that way. A real journalist would not allow a guest speaker to build an argument from facts that are really falsehoods (lies) without immediately calling him to task - but that of course requires the journalist to have done his homework and know more than the person being interviewed - a rare quality now days. People who are notorious for promoting demonstrable falsehoods should not be given free air time merely for the entertainment value, because there are unfortunately at least 20% of the population that will believe anything they hear on the air, no matter how ridiculous. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: O/T IBM to Ship World's Fastest Computer Chip
On 5 Sep 2010 14:17:23 -0700, in bit.listserv.ibm-main you wrote: On 09/05/2010 02:25 PM, Phil Smith III wrote: Rick Fochtman wrote: I'll give you another oxymoron: journalistic integrity Today, it's becoming rarer and rarer and I suspect will die out completely in our lifetimes. :-( Now, now. Lumping all journalists in one boat is as unfair as putting all computers into the same category. Some of us go to a fair amount of trouble to verify everything we write about. Having said that, I'll agree that *every* mainstream news story of which I've ever had first-hand knowledge got several significant and important facts wrong, such as names, ages, and confusing an employment address with a home address. Whether that's incompetence or just the rush to publish is unclear. None of them were malicious -- none of them improved (or hurt) the story for anyone who didn't already know those facts -- but it does speak to a certain lack of verification. ...phsiii I suspect the original sentiment was prompted by so many on cable news and talk shows that like to classify themselves as journalists when all they do is report the latest rumour without analysis as to validity, or referee opposing speakers as if all sides of an argument have equal validity. Not that infrequently these days, one side of an argument is just flat-out wrong and should be reported that way. A real journalist would not allow a guest speaker to build an argument from facts that are really falsehoods (lies) without immediately calling him to task - but that of course requires the journalist to have done his homework and know more than the person being interviewed - a rare quality now days. People who are notorious for promoting demonstrable falsehoods should not be given free air time merely for the entertainment value, because there are unfortunately at least 20% of the population that will believe anything they hear on the air, no matter how ridiculous. As someone who was in a field where you can't get a consensus on whether JES2 is better than JES3 and who is a follower of transportation issues (and a member of Transport Action Atlantic), I doubt a reporter would be able to determine easily which side of an argument is flat out wrong, even with some hours of research. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Datamation issue coining term nybble?
On 4 Sep 2010 19:11:33 -0700, in bit.listserv.ibm-main you wrote: Does anybody still have the issue of Datamation coining the term nybble? If so, would you mind posting the details? Thanks. My 40+ plus year old recollection of the article is that they spelled it nibble and may have also had gulp and swallow as synonyms for half-word and word. I don't recall which was the gulp. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where doc for STORAGE LINKAGE=SYSTEM
On 5 Sep 2010 08:10:55 -0700, in bit.listserv.ibm-main you wrote: On 9/5/2010 2:51 AM, Robert A. Rosenberg wrote: At 09:26 -0700 on 09/02/2010, Edward Jaffe wrote about Re: Where doc for STORAGE LINKAGE=SYSTEM: We've been burned by that unintuitive CALLRKY= default more than once. Theoretically there is a solution. Add a CALLERKEY= Parm and have it checked for first. If it is set then in that path check for CALLRKY and MNOTE if both defined and has a different value (otherwise ignore the CALLRKY). If CALLERKEY has not been used then do the normal check for CALLRKY. There have been other depreciated parms that have been handled this way if I remember correctly. I wasn't clear. We weren't burned because the CALLRKY= keyword has no vowels. We were burned by the unexpected fact that the STORAGE OBTAIN service assigns key zero (by default) to storage acquired from key-specifiable subpools, thus requiring explicit specification of CALLRKY=YES in nearly every case. The vendor inappropriate default strikes again (I use the term vendor because the problem is not unique to IBM). Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
JES2 vs. JES3
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris Sent: Sunday, September 05, 2010 4:55 PM To: IBM-MAIN@bama.ua.edu Subject: Re: O/T IBM to Ship World's Fastest Computer Chip SNIPPAGE As someone who was in a field where you can't get a consensus on whether JES2 is better than JES3 and who is a follower of transportation issues (and a member of Transport Action Atlantic), I doubt a reporter would be able to determine easily which side of an argument is flat out wrong, even with some hours of research. SNIPPAGE I created a new thread out of this because I think this is a bit more important a topic -- so why let it get lost in O/T IBM blah blah? Why is JES2 better than JES3? Why is JES3 better than JES2? Why would JES3 be preferred over JES2? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time waits for no one: 'leap seconds' may be cut
On Sat, 4 Sep 2010 23:38:37 -0700, Ed Gould wrote: http://www.pcworld.idg.com.au/article/358024/time_waits_no_one_leap_seconds_may_cut/ Which says: In the revised ITU plan, the divergence between UTC and UT will be allowed to grow over the next few hundred years, and could be reconciled by a single leap hour at some point. We have recognized the problem and squarely turned our backs to it. z/OS now idles user tasks down for a second at positive leap seconds. Is this an impact? I'm sure an hour would be unacceptable. z/OS has a half-hearted approach to leap seconds in idling user tasks. They implemented leap seconds but simply didn't have the courage to allow the TIME functions to return times such as 23:59:60 as specifed by the definition of UTC. UT1 is smoother than UTC; corrections from UTC to UT1 are issued daily with a granularity of 0.1 second. I'd propose an even smoother approximation, a chordwise version of UT1, with parameters published sufficiently in advance to support conversion of smoothed UT1--TAI for those rare cases where TAI is required. Of course, the mapping is undefined for more than a few months in the future. UNIX is worse than MVS. POSIX effectively prohibits any recognition of leap seconds in common time manipulation functions. NTP has a bizarre but probably satisfactory accomodation to leap seconds in shifting the epoch origin forward whenever a leap second is inserted. and cites: For instance, NTP itself can accommodate leap seconds by use of a parsable file of leap seconds that can be downloaded from the National Institute of Standards and Technology. Our site jumped aboard leap seconds when we got a Sysplex Timer. We abandoned them a year or two later beause of incompatibilities with ISV software. The problem was not with the disruption every year or two, but because vendor products were inconsistent in employing the correction in CVTLSO. Here I blame not the design of leap seconds, but vendor carelessness in their adaptation. Somewhere I saw a quotation to the effect that It is unreasonable to expect that a time specified as a number of seconds since the epoch should reflect the actual number of seconds since that epoch. I've lost the source. I'd be delighted to recover it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Storage not freed in IPCS dump
I got to tell you VSM always keeps me guessing I went to area marked DQE in the dump Discriptor Queue element which is suppoused be a structure in which offset x'10' is a pointer to data that was allocated and what was at that address seemed to me data that was allocated -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Santosh Kandi Sent: Friday, September 03, 2010 11:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Storage not freed in IPCS dump It depends. It could be allocated and not getmained. The more accurate way to find out is to use: VERBX VSMDATA 'SUMMARY NOASIDS' (For global memory) or VERBX VSMDATA 'NOGLOBAL SUMM ASID()' (For local memory) From there you should be able to find out if its allocated or free. Look in MVS diag reference..there is a chapter on VSM. ABCs of z/OS system prog Volume 8 is also a great resource. Regards, Santosh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: O/T IBM to Ship World's Fastest Computer Chip
On Sun, 2010-09-05 at 11:49 -0500, Rick Fochtman wrote: Shmuel Metz (Seymour J.) wrote: snip I'll give you another oxymoron: journalistic integrity Today, it's becoming rarer and rarer and I suspect will die out completely in our lifetimes. :-( Rick The same with scientific freedom. Today, your science better back up the approved thought, where applicable. -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
