z/OS 1.9 ISPF or SMS irritant
We have a test sysplex with completely separate DASD from our production plex, but its DASD is online to the prod plex for our convenience in copying stuff over to it (we're willing to take our chances with the lack of serialization; also, no prod packs are ever online to test!). The test plex has its own GRS and SMS setups, and a lot of datasets over there are named the same as in the prod plex. Until a short time ago, I was able to go into option 3.4 on a test plex volume and edit datasets, or copy members from identically named datasets by specifying volser. We recently upgraded to z/OS 1.9, and now I can't do that any more. If I try to edit an SMS-managed test plex dataset by using the volser, it tells me Duplicate data set name if that dataset name is cataloged on the prod plex. This seems excessively restrictive, and is extremely inconvenient to us. Has anyone else noticed this? Is there a workaround? Thanks, Cathy Taddei -- 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: LISTDSI alternative?
Not sure how I would use ISRDDN in a clist? I've considered parsing LISTALC output, but was just wondering if there was an easier way. Thanks, Cathy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LISTDSI alternative?
Thanks, Mark. The problem is with a vendor-provided clist. They've given me a workaround that involves locally modifying a bunch of their clists, which I'll have to track and refit if they should provide PTF's (it's not SMP-maintained). I thought I'd make it easier on myself by updating the one exec that has the listdsi in it. It looks like listalc is my best bet. Although I am starting to question the value of VIO... Cathy On Thu, 19 Jun 2008 15:28:09 -0500, Mark Zelden [EMAIL PROTECTED] wrote: What about (TSO) LISTALC STATUS? What exactly is the problem / issue? I ask, because I ran into a problem with VIO and IPLINFO using LISTDSI a while back. I changed my ISPF panel data set to a temp PDS and then used LISTDSI to find the DDNAME so I could write to it with REXX EXECIO. This failed in some environments that changed the allocation to VIO (via SMS rules). I then changed the allocation of the library to PDSE and that worked in some environments that checked for PDSE and didn't try to allocated it to VIO. But since PDSE can't be in VIO, it failed in other environments. Eventually I did it the correct way and used ISPF services (LM*) to write to the temp PDS (as opposed to EXECIO). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LISTDSI alternative?
Thanks, Lionel. Nice and compact! Cathy On Thu, 19 Jun 2008 13:30:56 -0700, Lionel B Dyck [EMAIL PROTECTED] wrote: Cathy - try this simple exec that you can call from your exec. If you get a return code of 0 then it is allocated and if you get a 4 then it is not allocated /* rexx to test if a dd is allocated */ arg ddname call outtrap 'isa.' 'listalc sta sys' call outtrap 'off' do i = 1 to isa.0 select when word(isa.i,2) = ddname then exit 0 when word(isa.i,1) = ddname then exit 0 otherwise nop end end /* * * DD Not Found * * */ exit 4 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LISTDSI alternative?
Hi Binyamin. LISTDSI only works on DASD -- it gives RC=16 for VIO. Cathy On Thu, 19 Jun 2008 23:58:33 +0300, Binyamin Dissen [EMAIL PROTECTED] wrote: ALLOC F(ddname) DA(*) will generate RC0 if the DDNAME is already allocated. What happens when LISTDSI is issued against VIO? RC=4 would indicate that the DDNAME is allocated. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LISTDSI alternative?
Thanks for your feedback, Ted. I have passed it along to my MVS systems programmers. Cathy On Thu, 19 Jun 2008 22:00:23 +, Ted MacNEIL [EMAIL PROTECTED] wrote: Although I am starting to question the value of VIO... As well you should. As a performance/capacity analyst for over 27 years, I used to recommend VIO for small datasets (small has increased over that period), but now I don't think it's worth it, any more. DASD is so fast, cache and channels are fast and we can do in memory buffering, so VIO is (mostly) a thing of the past. Especially for overhead-fetishists, since the CPU to do VIO is higher than that to do real I/O. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-level Alias
Hi Dave. I too have an unpleasant taste in my mouth from multi-level aliases. I don't remember a lot of the details, but they were a PITA when I was merging two master catalogs. It didn't help that the shop I was in also made extensive use of dataset aliases, which I detest. One question for you: why are you considering MLA's? Do you recall reading this in z/OS DFSMS: Managing Catalogs: ... the multilevel alias facility should only be used when a better solution cannot be found. The need for the multilevel alias facility can indicate poor data set naming conventions. Before defining multilevel aliases, review your data set naming conventions. If MLA's will solve a problem for you, great, but I wouldn't do it lightly. Regards, Cathy Taddei On Fri, 21 Apr 2006 13:10:04 -0400, Jousma, David [EMAIL PROTECTED] wrote: All, We are evaluating making a change from MLA(1) to MLA(2). I've read through Managing Catalogs, and there seem to be a few issues that could present themselves in a MLA environment. I'm looking for some real world experience, both the good things, and the pitfalls. I'm also hoping Mark Thomen might chime in. I've worked in other environments that had a MLA of 2, and ran into some issues, and didn't come out with a good taste in my mouth. It's Friday, I hope to get some good feedback. Thanks, Dave Dave Jousma Principal Systems Programmer [EMAIL PROTECTED] 616.653.8429 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Migrating me from linux/bsd to zOS
Aaron, I don't post here often, but I want you to know that z/OS Sysprogging is not a world of men with grey beards and hairy chests. Although we are definitely in the minority, there are plenty of female expert sysprogs, and I have had the good fortune of working with several of them. On the other hand, IBM-Main IS full of, well, I'd rather not go there. ;) Cathy Taddei On Sun, 9 Apr 2006 11:43:35 -0500, Sebastian Welton [EMAIL PROTECTED] wrote: On Sat, 8 Apr 2006 09:13:43 -0400, Aaron Peterson [EMAIL PROTECTED] wrote: I am reasonably competent with Perl, and I have looked over some C, although Thats a good start and to really help you in the mainframe arean I would suggest then to learn REXX which with the above noted skills will really make your job easier (you can get versions for any platform, including Windows so you can start now.) Welcome to the world of men with hairy chests and beards! Seb. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3590 shared between systems.
No...but we are just about to flip the switch to share an STK SL8500 silo between z/OS and Solaris (their only tape application is NetBackup). We will use completely separate tape drives and media between the platforms, but the mainframe will control the silo. Solaris will access it via LibStation running under z/OS. Are you going to share tapes between z/OS and Intel??? Sounds a little scary to me. Cathy Taddei On Wed, 8 Feb 2006 11:07:46 -0200, Bodra - Pessoal [EMAIL PROTECTED] wrote: Hi, Anyone using 3590 shared between z/OS (z800) and Intel servers? Please contact me. Thanks Carlos A. Bodra -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z890 CF LPAR
Oh really? I'm not familiar with the 2086-450 minus 25% model. According to the aforementioned zSeries 890 and z/OS Reference Guide, you can put a Coupling Facility in a standard LPAR (i.e., using CPs instead of ICFs), but whether those CPs are dedicated or shared, IBM software charges apply. And if IBM is charging me, you can bet CA, BMC, etc. will be charging me. Regards, Cathy On Mon, 30 Jan 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: The down side of using CP's instead of IFL's is that the CPU capacity used by the Coupling Facility are counted in the total size of the machine for software licensing purposes. NOT true! If you have dedicated CP's to the CF, they don't count. - -teD Im an enthusiastic proselytiser of the universal panacea I believe in! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z890 CF LPAR
Well, one reason why is that I only want to bring up my CF LPAR in case of an extended outage on my external CF. We investigated all kinds of combinations and permutations, one of them being to upgrade our 2086-450, having 4 engines and 650 mips, to 2 engines and 700 mips, and convert one of the spare engines to an ICF. The charge for converting a PU from CP to ICF was over $100k. The cost of a used z900 CF is slightly over $100k. We decided the cost of a couple of sysplex timers was worth it to not have to give up 2 engines and the parallelism that they enable. Regards, Cathy On Tue, 31 Jan 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: Oh really? I'm not familiar with the 2086-450 minus 25% model. ... OOPS! Mind you, I've never used CP's for CF's. Why would you? The ICF engine is cheaper than a general purpose engine. - -teD Im an enthusiastic proselytiser of the universal panacea I believe in! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z890 CF LPAR
My research tells me you can do this with General Purpose CP's as well as IFL's. The down side of using CP's instead of IFL's is that the CPU capacity used by the Coupling Facility are counted in the total size of the machine for software licensing purposes. You can even share CP's between an Internal Coupling Facility (ICF) and z/OS LPAR's, but that is very highly not recommended. Check out the IBM @eserver zSeries 890 and z/OS Reference Guide, particularly page 43. We're planning for parallel sysplex (current configuration is 3 z/OS LPAR's on a z890), and intend to buy a single z900 coupling facility, and define an ICF on our z890 using shared CP's as a backup in case of hardware failure on the z900. We would never try to run duplexed CF's with this configuration -- the z890 ICF would remain down except in the case of a catastrophic failure of the z900. We're not going for redundancy, just trying to reduce planned outages via Parallel Sysplex. Regards, Cathy On Fri, 27 Jan 2006 08:30:02 -0600, McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rich Tabor Sent: Friday, January 27, 2006 8:27 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Z890 CF LPAR Is it possible to partition a Z890 into an LPAR that functions as a coupling facility? Yes. I've done it. It is not recommended by IBM. But I had a spare IFL that I could dedicate to the CF partition and it works just fine. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
