Re: IDCAMS delete with mask
john.mck...@healthmarkets.com (McKown, John) writes: > Well, in a sense it is dying. The installed capacity is going up, but > it appears that the number of companies actually using it is > declining. In the past, IBM went after the "small business" with the > 135 or 4341. There is no longer a machine which is cost effective for > that demographic, mainly due to software costs. If I had a 10 person > company, I'd be a Linux/Intel user. I would not even consider Linux on > a small z due to the other hardware costs. I.e. a DASD array is much > more expensive than a small NAS box or even AOE arrays. If I were > somewhat bigger and needed better performance and reliability, then a > pSeries running Linux or perhaps even an iSeries would be more > affordable. And the iSeries is very impressive! 43xx (and vax) saw big explosion in the entry & mid-range starting 1979 ... large number ... bascially distributed/departmental servers ... some large companies ordered them in hundreds at a time. some old email discussing that 43xx period: http://www.garlic.com/~lynn/lhwemail.html#4341 recent reference to STL as example ... which in the early 80s they were installing them on every floor in every tower ... basically in the departmental "stock" room or in conference room. http://www.garlic.com/~lynn/2009n.html#15 Mainframe Hall of Fame: Three New Members Added another example is this old reference http://www.garlic.com/~lynn/2001m.html#15 departmental servers to customer initially looking at getting 20 4341s ... but order grew to 210 4341s (over six month period): http://www.garlic.com/~lynn/2001m.html#email790404b 43xx competed against vax in the entry and midrange market for customers buying single or few number of machines (compareable number of sales) ... but 43xx were also sold in quantities to large customers ordering multiple hundred at a time. this is vax sales sliced & diced by year, model, US & non-US ... and it is easy to see that by mid-80s, that market was moving to workstations & large PCs. http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction followon 4361/4381 anticipated to see equally large explosion in orders ... but by that time ... workstations & PCs were starting to move up the value chain and take over the entry & mid-range market segment (similar fate as what happened to vax). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: IDCAMS delete with mask
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Guy Gardoit > Sent: Thursday, October 01, 2009 3:13 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: IDCAMS delete with mask > > On Sun, Sep 27, 2009 at 10:21 PM, Barbara Nitz > wrote: > > > ...snip > > And you ask why the platform is dying? > > ... snip > > > -- > > > > > Hmm, must be because Windose, Unix, HP and other platforms > are designed and > implemented so perfectly, right? > Please, give me a break. "the platform is dying" - what a ridiculous > statement. > > -- > Guy Gardoit > z/OS Systems Programming Well, in a sense it is dying. The installed capacity is going up, but it appears that the number of companies actually using it is declining. In the past, IBM went after the "small business" with the 135 or 4341. There is no longer a machine which is cost effective for that demographic, mainly due to software costs. If I had a 10 person company, I'd be a Linux/Intel user. I would not even consider Linux on a small z due to the other hardware costs. I.e. a DASD array is much more expensive than a small NAS box or even AOE arrays. If I were somewhat bigger and needed better performance and reliability, then a pSeries running Linux or perhaps even an iSeries would be more affordable. And the iSeries is very impressive! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: IDCAMS delete with mask
On Sun, Sep 27, 2009 at 10:21 PM, Barbara Nitz wrote: > ...snip > And you ask why the platform is dying? > ... snip > -- > > Hmm, must be because Windose, Unix, HP and other platforms are designed and implemented so perfectly, right? Please, give me a break. "the platform is dying" - what a ridiculous statement. -- Guy Gardoit z/OS Systems Programming -- 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
"A clear violation of the principle of least astonishment" was a phrase first used in my presence by Jim Doody (then) of Marine Midland Bank at a GUIDE meeting in 1975. It was obvious what it meant, but I cornered him afterwards to ask him about it. He did not claim originality. It stuck in my mind, so I wrote wrote it on a 5081 punched card, and displayed it on the cork boards above my desk for a number of years afterwards (along with a number of other great quotes from Jim and others). Jim told me, perhaps in jest (but you never knew), that he stole it from Ron Higgin. Regardless, in 1975 both Jim and Ron (and as far as the audience reaction [laughter] evidenced, a number of others) considered it to be in the vernacular. Since I had the habit of writing the (current) date on all of my cute "card notes" I know for a fact that the year was 1975. -- 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
On Mon, Sep 28, 2009 at 3:15 PM, Paul Gilmartin wrote: > On Mon, 28 Sep 2009 12:07:35 -0700, Edward Jaffe wrote: > > >Pinnacle wrote: > >> ... They violated Lionel Dyck's "principle of least astonishment". > > > >The Principle of Least Astonishment is attributable to Lionel Dyck? > > > Cowlishaw uses "astonishment factor" regularly. I don't know > that he claims primacy. Folks I've worked with for going on two decades have been using "principle of least astonishment" for at least that long. Ron Higgin, Thom Scrutchin, Bill Blair and on and on. I am pretty sure it goes back before them too. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
On Mon, 28 Sep 2009 12:07:35 -0700, Edward Jaffe wrote: >Pinnacle wrote: >> ... They violated Lionel Dyck's "principle of least astonishment". > >The Principle of Least Astonishment is attributable to Lionel Dyck? > Cowlishaw uses "astonishment factor" regularly. I don't know that he claims primacy. -- 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
- Original Message - From: "Edward Jaffe" Newsgroups: bit.listserv.ibm-main Sent: Monday, September 28, 2009 3:09 PM Subject: Principle of Least Astonishment (Was: IDCAMS delete with mask) Pinnacle wrote: ... They violated Lionel Dyck's "principle of least astonishment". The Principle of Least Astonishment is attributable to Lionel Dyck? Ed, Lionel was the first person I ever heard use these words to describe the effect. I've spent the last hour researching this and cannot find an attribution for who created this little gem, but it's clear that its use is widespread. Wikipedia does mention Occam's Razor. Two other references are made to "The Humane Interface" by Jeff Raskin, and E.S. Raymond's "The Art of Unix Programming", which has a section entitled "Applying the rule of least surprise". Tom -- 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
Bill Fairchild wrote: Did Lionel Dyck predate William of Ockham (1288-1327)? Obviously not. But, what has that got to do with my question? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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
Re: Principle of Least Astonishment (Was: IDCAMS delete with mask)
Ockham (aka Occam) wrote what we now call his Razor: "Never is a plurality to be multiplied without necessity" (except that he wrote it in Latin). This has been interpreted as meaning the simplest explanation should be chosen when faced with multiple alternatives. To hone the razor even further, I can imagine that a user would think the least astonishing result of a computer command would be the simplest explanation. Some logicians might argue contrariwise. At the very least, the computer principle is a corollary of the Razor. Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Monday, September 28, 2009 2:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Principle of Least Astonishment (Was: IDCAMS delete with mask) Darn ... I was laying 2:1 odds. On Mon, Sep 28, 2009 at 8:18 PM, Scott Rowe wrote: > I don't think he's quite that old. > > >>> Bill Fairchild 9/28/2009 3:13 PM >>> > Did Lionel Dyck predate William of Ockham (1288-1327)? > > Bill Fairchild > > Software Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 > Email: bi...@mainstar.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Edward Jaffe > Sent: Monday, September 28, 2009 2:08 PM > To: IBM-MAIN@bama.ua.edu > Subject: Principle of Least Astonishment (Was: IDCAMS delete with mask) > > Pinnacle wrote: > > ... They violated Lionel Dyck's "principle of least astonishment". > > The Principle of Least Astonishment is attributable to Lionel Dyck? > > -- > Edward E Jaffe > Phoenix Software International, Inc > 5200 W Century Blvd, Suite 800 > Los Angeles, CA 90045 > 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 > > -- > 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 > > > > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains > confidential and privileged information intended only for the addressee. If > you are not the intended recipient, please be advised that you have received > this material in error and that any forwarding, copying, printing, > distribution, use or disclosure of the material is strictly prohibited. If > you have received this material in error, please (i) do not read it, (ii) > reply to the sender that you received the message in error, and (iii) erase > or destroy the material. Emails are not secure and can be intercepted, > amended, lost or destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by email. Thank you. > > > -- > 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 -- 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
Darn ... I was laying 2:1 odds. On Mon, Sep 28, 2009 at 8:18 PM, Scott Rowe wrote: > I don't think he's quite that old. > > >>> Bill Fairchild 9/28/2009 3:13 PM >>> > Did Lionel Dyck predate William of Ockham (1288-1327)? > > Bill Fairchild > > Software Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 > Email: bi...@mainstar.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Edward Jaffe > Sent: Monday, September 28, 2009 2:08 PM > To: IBM-MAIN@bama.ua.edu > Subject: Principle of Least Astonishment (Was: IDCAMS delete with mask) > > Pinnacle wrote: > > ... They violated Lionel Dyck's "principle of least astonishment". > > The Principle of Least Astonishment is attributable to Lionel Dyck? > > -- > Edward E Jaffe > Phoenix Software International, Inc > 5200 W Century Blvd, Suite 800 > Los Angeles, CA 90045 > 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 > > -- > 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 > > > > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains > confidential and privileged information intended only for the addressee. If > you are not the intended recipient, please be advised that you have received > this material in error and that any forwarding, copying, printing, > distribution, use or disclosure of the material is strictly prohibited. If > you have received this material in error, please (i) do not read it, (ii) > reply to the sender that you received the message in error, and (iii) erase > or destroy the material. Emails are not secure and can be intercepted, > amended, lost or destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by email. Thank you. > > > -- > 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
I don't think he's quite that old. >>> Bill Fairchild 9/28/2009 3:13 PM >>> Did Lionel Dyck predate William of Ockham (1288-1327)? Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, September 28, 2009 2:08 PM To: IBM-MAIN@bama.ua.edu Subject: Principle of Least Astonishment (Was: IDCAMS delete with mask) Pinnacle wrote: > ... They violated Lionel Dyck's "principle of least astonishment". The Principle of Least Astonishment is attributable to Lionel Dyck? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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 -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: Principle of Least Astonishment (Was: IDCAMS delete with mask)
Did Lionel Dyck predate William of Ockham (1288-1327)? Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, September 28, 2009 2:08 PM To: IBM-MAIN@bama.ua.edu Subject: Principle of Least Astonishment (Was: IDCAMS delete with mask) Pinnacle wrote: > ... They violated Lionel Dyck's "principle of least astonishment". The Principle of Least Astonishment is attributable to Lionel Dyck? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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 -- 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
Principle of Least Astonishment (Was: IDCAMS delete with mask)
Pinnacle wrote: ... They violated Lionel Dyck's "principle of least astonishment". The Principle of Least Astonishment is attributable to Lionel Dyck? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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
Re: IDCAMS delete with mask
Maybe they're one APAR short of a deck. The test I posted used data sets in the master catalog, and a delete with a trailing .** did not find data sets that should have matched the mask. Stuart Holland wrote: The delete with mask feature currently defaults to only looking in the master catalog. You have to code the CATALOG parameter to have it look anywhere else. There is an APAR open to remove this restriction. It also does not work under TSO. There is a separate APAR for that. -- 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: IDCAMS delete with mask
Okay wise guy. :-) Shortcomings exist in the entire platform, but let's not go there. The major shortcomings that prevented IFASMFDL from even being usable were fixed. (I didn't change the subject yet, but if you want to continue on this one, please do). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Mon, 28 Sep 2009 06:08:37 -0400, Richards, Robert B. wrote: >Mark, > >Did? To the best of my knowledge, shortcomings *still* exist. Maybe 1.12 will resolve the remainder. > >Bob > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden >Sent: Sunday, September 27, 2009 11:07 AM >To: IBM-MAIN@bama.ua.edu >Subject: Re: IDCAMS delete with mask > >> At least it is getting rectified a lot quicker than the shortcomings of the SMF logger dump program (IFASMFDL) did. > >-- >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: IDCAMS delete with mask
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz > Sent: Monday, September 28, 2009 12:22 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: IDCAMS delete with mask > > >So this half-a$$ed masking was put in there by DESIGN? WOW! > Incredibly > >brain dead. They violated Lionel Dyck's "principle of least > astonishment". > >It should have been designed to work like standard dataset > masking in SMS. > >Designer: "Should we use DFDSS rules? Nahhh! (and now for > something > >COMPLETELY DIFFERENT, cue the Liberty Bell march). At least > they're not > >making us submit SHARE requirements to fix it. > > This is the future of z/OS, in my opinion: > 1. Think about a feature (preferably one that customers had > submitted lots of > requirements for) > 2. Design it > 3. Realise that this design cannot be programmed/tested with > the budget > 4. Shorten the design to make it brain-dead. The only goal is > to get a short > code path so it fits the 3$-budget allotted for it > 5. Wait for customers to scream after GA > 6. Maybe fix it via apar (probably because parts of the > 'real' design were > already in, just not tested yet to make them GA-eligible) > 7. Ask customers to open a requirement for the BAD design > which will then go > through 1 to 6. > > And you ask why the platform is dying? > > I feel better now, too. > Barbara But the above applies quite often to all commercial software. What is developed is what is thought to make the greatest profit. Now that which makes the best product. Another interesting reason to like FOSS software such as *BSD and Linux. They are generally developed by people who love to program and want "good" software. Not that FOSS software is alway the best! But it is developed according to a different mind set than "make money". -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: IDCAMS delete with mask
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Barbara Nitz > > >So this half-a$$ed masking was put in there by DESIGN? WOW! Incredibly > >brain dead. They violated Lionel Dyck's "principle of least astonishment". > >It should have been designed to work like standard dataset masking in SMS. > >Designer: "Should we use DFDSS rules? Nahhh! (and now for something > >COMPLETELY DIFFERENT, cue the Liberty Bell march). At least they're not > >making us submit SHARE requirements to fix it. > > This is the future of z/OS, in my opinion: > 1. Think about a feature (preferably one that customers had submitted lots of > requirements for) > 2. Design it > 3. Realise that this design cannot be programmed/tested with the budget > 4. Shorten the design to make it brain-dead. The only goal is to get a short > code path so it fits the 3$-budget allotted for it > 5. Wait for customers to scream after GA > 6. Maybe fix it via apar (probably because parts of the 'real' design were > already in, just not tested yet to make them GA-eligible) > 7. Ask customers to open a requirement for the BAD design which will then go > through 1 to 6. > > And you ask why the platform is dying? Indeed. Once upon a time, "good enough" wasn't; "excellent" was sought and frequently achieved. Nowadays, too often "good enough" is a bonus: "Here, this sort of does that. Now go bother somebody else." -jc- -- 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: IDCAMS delete with mask
Mark, Did? To the best of my knowledge, shortcomings *still* exist. Maybe 1.12 will resolve the remainder. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Sunday, September 27, 2009 11:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IDCAMS delete with mask > At least it is getting rectified a lot quicker than the shortcomings of the > SMF logger dump program (IFASMFDL) did. -- 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: IDCAMS delete with mask
Barbara, Someone need a hug? ***HUG*** I agree with you. But think about the inverse. Stuff like this is why they need to keep us around! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Monday, September 28, 2009 1:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IDCAMS delete with mask >So this half-a$$ed masking was put in there by DESIGN? WOW! Incredibly >brain dead. They violated Lionel Dyck's "principle of least astonishment". >It should have been designed to work like standard dataset masking in SMS. >Designer: "Should we use DFDSS rules? Nahhh! (and now for something >COMPLETELY DIFFERENT, cue the Liberty Bell march). At least they're not >making us submit SHARE requirements to fix it. This is the future of z/OS, in my opinion: 1. Think about a feature (preferably one that customers had submitted lots of requirements for) 2. Design it 3. Realise that this design cannot be programmed/tested with the budget 4. Shorten the design to make it brain-dead. The only goal is to get a short code path so it fits the 3$-budget allotted for it 5. Wait for customers to scream after GA 6. Maybe fix it via apar (probably because parts of the 'real' design were already in, just not tested yet to make them GA-eligible) 7. Ask customers to open a requirement for the BAD design which will then go through 1 to 6. And you ask why the platform is dying? I feel better now, too. Barbara -- 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: IDCAMS delete with mask
>So this half-a$$ed masking was put in there by DESIGN? WOW! Incredibly >brain dead. They violated Lionel Dyck's "principle of least astonishment". >It should have been designed to work like standard dataset masking in SMS. >Designer: "Should we use DFDSS rules? Nahhh! (and now for something >COMPLETELY DIFFERENT, cue the Liberty Bell march). At least they're not >making us submit SHARE requirements to fix it. This is the future of z/OS, in my opinion: 1. Think about a feature (preferably one that customers had submitted lots of requirements for) 2. Design it 3. Realise that this design cannot be programmed/tested with the budget 4. Shorten the design to make it brain-dead. The only goal is to get a short code path so it fits the 3$-budget allotted for it 5. Wait for customers to scream after GA 6. Maybe fix it via apar (probably because parts of the 'real' design were already in, just not tested yet to make them GA-eligible) 7. Ask customers to open a requirement for the BAD design which will then go through 1 to 6. And you ask why the platform is dying? I feel better now, too. Barbara -- 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: IDCAMS delete with mask
- Original Message - From: "Mark Zelden" Newsgroups: bit.listserv.ibm-main Sent: Sunday, September 27, 2009 11:08 AM Subject: Re: IDCAMS delete with mask On Sat, 26 Sep 2009 21:17:52 -0400, Robert A. Rosenberg wrote: At 17:05 -0700 on 09/26/2009, Stuart Holland wrote about IDCAMS delete with mask: The delete with mask feature currently defaults to only looking in the master catalog. You have to code the CATALOG parameter to have it look anywhere else. There is an APAR open to remove this restriction. It also does not work under TSO. There is a separate APAR for that. IMO that restriction should not exist in the first place (so long a the mask does not affect which catalog you are referencing). IOW: If the unmasked part of the name leads to a catalog by following the alias chain, that should be enough for it to work without needing to alter IDCAMS's processing by supplying it with a CATALOG parm. You would think. I think most if not all the room (who hadn't already worked with 1.11 via ESP or vendor programs) was surprised at the session I was in at SHARE when this (illogical?) behavior was described.At least it is getting rectified a lot quicker than the shortcomings of the SMF logger dump program (IFASMFDL) did. So this half-a$$ed masking was put in there by DESIGN? WOW! Incredibly brain dead. They violated Lionel Dyck's "principle of least astonishment". It should have been designed to work like standard dataset masking in SMS. Designer: "Should we use DFDSS rules? Nahhh! (and now for something COMPLETELY DIFFERENT, cue the Liberty Bell march). At least they're not making us submit SHARE requirements to fix it. There, I feel better. Regards, Tom Conley -- 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: IDCAMS delete with mask
On Sat, 26 Sep 2009 21:17:52 -0400, Robert A. Rosenberg wrote: >At 17:05 -0700 on 09/26/2009, Stuart Holland wrote about IDCAMS >delete with mask: > >>The delete with mask feature currently defaults to only looking in the >>master catalog. You have to code the CATALOG parameter to have it look >>anywhere else. There is an APAR open to remove this restriction. It also >>does not work under TSO. There is a separate APAR for that. > >IMO that restriction should not exist in the first place (so long a >the mask does not affect which catalog you are referencing). IOW: If >the unmasked part of the name leads to a catalog by following the >alias chain, that should be enough for it to work without needing to >alter IDCAMS's processing by supplying it with a CATALOG parm. > You would think. I think most if not all the room (who hadn't already worked with 1.11 via ESP or vendor programs) was surprised at the session I was in at SHARE when this (illogical?) behavior was described.At least it is getting rectified a lot quicker than the shortcomings of the SMF logger dump program (IFASMFDL) did. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: IDCAMS delete with mask
At 17:05 -0700 on 09/26/2009, Stuart Holland wrote about IDCAMS delete with mask: The delete with mask feature currently defaults to only looking in the master catalog. You have to code the CATALOG parameter to have it look anywhere else. There is an APAR open to remove this restriction. It also does not work under TSO. There is a separate APAR for that. IMO that restriction should not exist in the first place (so long a the mask does not affect which catalog you are referencing). IOW: If the unmasked part of the name leads to a catalog by following the alias chain, that should be enough for it to work without needing to alter IDCAMS's processing by supplying it with a CATALOG parm. -- 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
IDCAMS delete with mask
The delete with mask feature currently defaults to only looking in the master catalog. You have to code the CATALOG parameter to have it look anywhere else. There is an APAR open to remove this restriction. It also does not work under TSO. There is a separate APAR for that. -- 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
