Re: SMP/E packaging of maintence / products (was: FMID descriptions)
Your can divide this storage up in any format you like 3’s 24’s, what not. Why the operate with mod 3’s is beyond me it cause more problems then it solves. Maybe because changing to bigger volumes costs downtime of the control unit? At least I was told it does, as the CU cannot be reconfigured while active IO is going on. And downtime of the control unit means downtime for x number of lpars behind that control unit, most of them IPL-able 4 times per year. And no, we don't have enough money to have two CUs per lpar. Actually, we do, but those are the mirrors. Regards, Barbara Nitz -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Chris Craddock On Sat, May 30, 2009 at 8:51 AM, John McKown joa...@swbell.net wrote: A good idea. However, we only have 3390-3 volumes. And, as I said in another post, if I have a large amount of unused space in a SMS pool, then management becomes unglued. Of course, I could just leave the entire space allocated to a zFS file. I'll see if I can talk my manager into that. Thanks for the idea. I don't know whether to be comforted or irritated to see people still suffering from the stupidity of ancient volume architectures. I have a bag full of cheap USB thumb drives that are bigger than a mod 3. Nobody has seen a real 3390 in at least a decade. Storage volumes are all virtual now. Why not just make 'em as big as you need and be done with all this nuttiness? Institutional[ized] Inertia. But we do have a handful of mod-9s now :-) -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: SMP/E packaging of maintence / products (was: FMID descriptions)
And in some cases such a connection is simply illegal. -Original Message- From: John McKown Sent: Saturday, May 30, 2009 4:28 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMP/E packaging of maintence / products (was: FMID descriptions) On Sat, 30 May 2009, Paul Gilmartin wrote: Someone here once suggested that all local storage of unloaded relative files should be eliminated: it shouldn't be RECEIVE FROMNETWORK, but APPLY FROMNETWORK, accessing the Great SMPPTS in the Sky. But I know of no vendor that avoids the two step process, separating transfer from install. Overlapping them vastly complicates recovery from network failures. -- gil Not all z/OS installations allow the z/OS system to access the Internet. We don't. It is regarded as too risky. I know, I know, but that is the opinion of those in charge. Today, 'my way or the high way' is just too likely to allow me (at least) to try to convince anybody of anything too strongly. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
I guess you guys never have to support a customer whose system doesn't even include TCP/IP, let alone anything modern. -Original Message- From: R.S. Sent: Sunday, May 31, 2009 12:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMP/E packaging of maintence / products (was: FMID descriptions) Chris Craddock pisze: On Sat, May 30, 2009 at 8:51 AM, John McKown joa...@swbell.net wrote: A good idea. However, we only have 3390-3 volumes. And, as I said in another post, if I have a large amount of unused space in a SMS pool, then management becomes unglued. Of course, I could just leave the entire space allocated to a zFS file. I'll see if I can talk my manager into that. Thanks for the idea. I don't know whether to be comforted or irritated to see people still suffering from the stupidity of ancient volume architectures. I have a bag full of cheap USB thumb drives that are bigger than a mod 3. Nobody has seen a real 3390 in at least a decade. Storage volumes are all virtual now. Why not just make 'em as big as you need and be done with all this nuttiness? This is not stupidity of ancient volume architecture. The architecture was quite OK in ancient times. The stupid thing is to conserve the ancient architecture. I'm aware it's often choice of management, not technical staff. When we talk about mainframe A.D. 2009 we simply don't have such problems! Think about EAV or NFS attached USB. 3390-3 is history, as BusTag, punched cards or other Dodo's. Yes, you can still use it - that's one of the mainframe strengths, but you don't have to. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
Because it would save a lot of money!!! And that is what gets points now where I work. It's an unfortunate fact that IS has gone from being the savior to being overhead. A lot of bad decisions are made in order to reduce cost. The old adage pay me now or pay me (more) later often prevails. Bob Shannon Rocket Software -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
I’ve been following this post and regarding 3390 mod 3’s, the bank I was working for has an EMC whatever box and I know it has a bunch of storage. Your can divide this storage up in any format you like 3’s 24’s, what not. Why the operate with mod 3’s is beyond me it cause more problems then it solves. Running out of space is a constant issue and could be solve by just creating storage pools for a bunch of mod 3’s but they just won’t do it. --- On Sat, 5/30/09, Chris Craddock crashlu...@gmail.com wrote: From: Chris Craddock crashlu...@gmail.com Subject: Re: SMP/E packaging of maintence / products (was: FMID descriptions) To: IBM-MAIN@bama.ua.edu Date: Saturday, May 30, 2009, 3:00 PM On Sat, May 30, 2009 at 8:51 AM, John McKown joa...@swbell.net wrote: A good idea. However, we only have 3390-3 volumes. And, as I said in another post, if I have a large amount of unused space in a SMS pool, then management becomes unglued. Of course, I could just leave the entire space allocated to a zFS file. I'll see if I can talk my manager into that. Thanks for the idea. I don't know whether to be comforted or irritated to see people still suffering from the stupidity of ancient volume architectures. I have a bag full of cheap USB thumb drives that are bigger than a mod 3. Nobody has seen a real 3390 in at least a decade. Storage volumes are all virtual now. Why not just make 'em as big as you need and be done with all this nuttiness? CC -- 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 -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
My $0.02 regarding HFS files and Internet download and SMP/E. When you install CBPDO product downloaded from Internet you need rougly 4x times space than the product occupies! 1. HFS for downloads 2. HFS for unpack 3. Datasets for source (fake tape) 4. Datasets for relfiles. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
Chris Craddock pisze: On Sat, May 30, 2009 at 8:51 AM, John McKown joa...@swbell.net wrote: A good idea. However, we only have 3390-3 volumes. And, as I said in another post, if I have a large amount of unused space in a SMS pool, then management becomes unglued. Of course, I could just leave the entire space allocated to a zFS file. I'll see if I can talk my manager into that. Thanks for the idea. I don't know whether to be comforted or irritated to see people still suffering from the stupidity of ancient volume architectures. I have a bag full of cheap USB thumb drives that are bigger than a mod 3. Nobody has seen a real 3390 in at least a decade. Storage volumes are all virtual now. Why not just make 'em as big as you need and be done with all this nuttiness? This is not stupidity of ancient volume architecture. The architecture was quite OK in ancient times. The stupid thing is to conserve the ancient architecture. I'm aware it's often choice of management, not technical staff. When we talk about mainframe A.D. 2009 we simply don't have such problems! Think about EAV or NFS attached USB. 3390-3 is history, as BusTag, punched cards or other Dodo's. Yes, you can still use it - that's one of the mainframe strengths, but you don't have to. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Sat, 30 May 2009 18:25:25 +0200, R.S. wrote: My $0.02 regarding HFS files and Internet download and SMP/E. When you install CBPDO product downloaded from Internet you need rougly 4x times space than the product occupies! 1. HFS for downloads 2. HFS for unpack 3. Datasets for source (fake tape) 4. Datasets for relfiles. Aren't (2) and (3) dynamic, existing only for one relfile at a time, and deleted once the relfile is created. So you need somewhat more than 2x the space of the product: 1. HFS for downloads 2-3. unpack and IEBCOPY input for largest relfile. 4. Data sets for relfiles. A very simple enhancement to IEBCOPY would allow streaming directly from Internet (or local workstation), and eliminate (2) and (3) and relocate (1) to cheap squatty box storage. Sounds like a Requirement candidate. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Fri, 29 May 2009, Bobbie Jo wrote: good grief, why do you keep fighting with the storage admins? make one zFS download extended format dataset on ONE permanently mounted mod 54 volume, and be done with it. use that download file system for z/OS, cics, db2, program products, etc. Use skulker to keep it clean of old files. Bobbie Justice A good idea. However, we only have 3390-3 volumes. And, as I said in another post, if I have a large amount of unused space in a SMS pool, then management becomes unglued. Of course, I could just leave the entire space allocated to a zFS file. I'll see if I can talk my manager into that. Thanks for the idea. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
I'm not sure if this helps, but the z/OS pax command supports reading archives from an MVS dataset. On Fri, May 29, 2009 at 5:22 PM, Kurt Quackenbush ku...@us.ibm.com wrote: McKown, John wrote: Could I ask a question which I know you likely cannot answer. But, if possible, could you explain why the SMP/E Internet download stuff in SMP/E uses UNIX files to store the data rather than z/OS legacy type datasets (perhaps compressed with TERSE or XMIT'ed)? As a matter of fact I can answer that question. Mostly because the download FTP servers and their file systems are not necessarily z/OS, and non-z/OS systems do not typically play well with z/OS data sets. We wanted to keep the package and file structure Internet-friendly (platform agnostic?) so it wouldn't matter much what kind of system was used to serve, or download. Remember, for those that cannot or choose not to download directly to z/OS, we expect the package to be downloaded to a workstation. In addition, we wanted to use a supported and standard archive/compression utility. The UNIX pax command was our choice. Therefore, UNIX files seemed like a good choice all around. I'm sure we could have made other choices, and I'm sure some folks on this list will be more than happy to point them out to me. Be that as it may, the format we landed on was and is UNIX files. It is unfortunate you have to jump through hoops to get a set of volumes to use for the download. Can you work with your storage admins to avoid this in the future? Kurt Quackenbush -- IBM, SMP/E Development -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Fri, 29 May 2009, Howard Rifkind wrote: Kurt, I also find this a pain in the a__. Is it still IBM's purpose to 'Make this more difficult so we will understand it' You took something that worked real well and messed it up. How about two procedures, one for the z/OS-z/VM and one for HFS/OMVS/UNIX fixes??? For me, it is a mild pain. But, if I get the ax (and who knows who is next around here or why), it will be a major pain for the people left. They don't know UNIX. They don't like UNIX. They seem to regard UNIX on z/OS as an abomination. In fact, my boss has been known to ream out vendors who state that they cannot create a tape which is readable on a 3490E drive. He will make do with a CD or DVD so that he can ftp from his desktop, but it really gets him upset. He hates Internet delivery because our Internet connection is a bit slow (remote workers get priority). And he has a 14 Mb/s FiOS connection at his house. Anyway, we have two drives on a C22 just for software installation. They are not used for anything else. I hate them. Mainly because we have no operators. So, if I have more than two tapes, I get to sit in a cold machine room waiting for mounts and hoping that my job didn't abend. I can't monitor my job because there are no PCs in the machine room for me to have a 3270 session on. And no dangling ethernet cables to plug a laptop into. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Sat, 30 May 2009 10:07:28 -0500, Kirk Wolf k...@dovetail.com wrote: I'm not sure if this helps, but the z/OS pax command supports reading archives from an MVS dataset. Close, but not quite. SMP/E doesn't support SMPNTS resident in Classic data sets. Recent releases of SMP/E process relative files from the SMPNTS consecutively, discarding work files from SMPWKDIR as each relative file is loaded, somewhat relieving storage constraints that existed earlier. Wouldn't it be great if IEBCOPY could load from a Unix file, relieving SMP/E of the need to do the (rather simple) conversion to a RECFM=VBS Classic data set? And even better if that Unix file could be a pipe, so an unpacked copy of the unloaded relative file need never exist? (Hmmm. Would require a restructuring of the SMPNTS so compressed relative files would not reside in pax.Z archives, since pax can't extract to pipes.) Someone here once suggested that all local storage of unloaded relative files should be eliminated: it shouldn't be RECEIVE FROMNETWORK, but APPLY FROMNETWORK, accessing the Great SMPPTS in the Sky. But I know of no vendor that avoids the two step process, separating transfer from install. Overlapping them vastly complicates recovery from network failures. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Fri, 29 May 2009 20:58:21 -0400, Robert A. Rosenberg wrote: At 18:12 -0500 on 05/29/2009, Paul Gilmartin wrote about Re: SMP/E packaging of maintence / products (was: FMID desc: On Fri, 29 May 2009 16:00:47 -0700, Howard Rifkind wrote: I also find this a pain in the a__. Is it still IBM's purpose to 'Make this more difficult so we will understand it' You took something that worked real well and messed it up. Err... How did the earlier something work real well for Internet delivery? PTFs, perhaps, but not FUNCTIONs with Relative Files. Store the flattened PDS files in a PDS as members and export that as a Flat File. To recreate, you just Import the supplied Exported PDS, use supplied JCL to create a PUT Tape by copying the members which is then read into SMP/E as usual. Your remark appears to be in response to my question about how SMP/E formerly worked. Am I to understand that SMP/E formerly accomplished Internet delivery using nested TSO TRANSMIT files (else how else flattened?), and subsequently abandoned that technique in favor of pax.Z? I hadn't been aware of that. Is it so? I know that CBTTAPE.org delivers products in TSO TRANSMIT envelopes (sometimes nested?), but I know of no CBT product that's SMP/E installed. Is PDS compatible with RECFM=VBS (the IEBCOPY convention)? Will IEBCOPY unload to a PDS member, or will it get confused because the DSCB of both SYSUT1 and SYSUT2 says DSORG=PDS? -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Sat, May 30, 2009 at 8:51 AM, John McKown joa...@swbell.net wrote: A good idea. However, we only have 3390-3 volumes. And, as I said in another post, if I have a large amount of unused space in a SMS pool, then management becomes unglued. Of course, I could just leave the entire space allocated to a zFS file. I'll see if I can talk my manager into that. Thanks for the idea. I don't know whether to be comforted or irritated to see people still suffering from the stupidity of ancient volume architectures. I have a bag full of cheap USB thumb drives that are bigger than a mod 3. Nobody has seen a real 3390 in at least a decade. Storage volumes are all virtual now. Why not just make 'em as big as you need and be done with all this nuttiness? CC -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: Saturday, May 30, 2009 12:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMP/E packaging of maintence / products (was: FMID descriptions) On Sat, May 30, 2009 at 8:51 AM, John McKown joa...@swbell.net wrote: A good idea. However, we only have 3390-3 volumes. And, as I said in another post, if I have a large amount of unused space in a SMS pool, then management becomes unglued. Of course, I could just leave the entire space allocated to a zFS file. I'll see if I can talk my manager into that. Thanks for the idea. I don't know whether to be comforted or irritated to see people still suffering from the stupidity of ancient volume architectures. I have a bag full of cheap USB thumb drives that are bigger than a mod 3. Nobody has seen a real 3390 in at least a decade. Storage volumes are all virtual now. Why not just make 'em as big as you need and be done with all this nuttiness? 1. Not enough people/knowledge/time to learn/do local EMC configuration. 2. Adabas really was on mod-2 when we migrated to raid EMC damn near 2 decades ago, hasn't needed a reorg yet. Or time for such an outage. 3. Can't afford PAV :( Still, I have enough mod-9 to do what I need. 2 sets alternating sysres (4), 2 SMP/E target volumes (1.7 and 1.9) cause migration in progress. 1 each SMPNTS and a SMPWKDIR one to back-up target HFS when cloning. And a couple spares. 12 total. And yah, I also keep harping on the folks around here that still think small, both DASD and memory :) CC -- 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 -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Sat, 30 May 2009 11:43:13 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... Someone here once suggested that all local storage of unloaded relative files should be eliminated: it shouldn't be RECEIVE FROMNETWORK, but APPLY FROMNETWORK, accessing the Great SMPPTS in the Sky. ... That would be great for those shops with mainframe access to the internet, but it would not work for shops that limit such access - those shops that require workstations as an intermediate stage when getting maintenance. That would require getting a copy ofthe Great SMPPTS in the Sky and all other RECIEVE-built datasets to MVS. In those shops, RECEIVE FROMNETWORK (where network is a local Unix file) would still be required. And arguments that such restrictions are stupid doesn't make them go away. Pat O'Keefe -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Sat, 30 May 2009, Paul Gilmartin wrote: Someone here once suggested that all local storage of unloaded relative files should be eliminated: it shouldn't be RECEIVE FROMNETWORK, but APPLY FROMNETWORK, accessing the Great SMPPTS in the Sky. But I know of no vendor that avoids the two step process, separating transfer from install. Overlapping them vastly complicates recovery from network failures. -- gil Not all z/OS installations allow the z/OS system to access the Internet. We don't. It is regarded as too risky. I know, I know, but that is the opinion of those in charge. Today, 'my way or the high way' is just too likely to allow me (at least) to try to convince anybody of anything too strongly. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Sat, 30 May 2009, Chris Craddock wrote: On Sat, May 30, 2009 at 8:51 AM, John McKown joa...@swbell.net wrote: I don't know whether to be comforted or irritated to see people still suffering from the stupidity of ancient volume architectures. I have a bag full of cheap USB thumb drives that are bigger than a mod 3. Nobody has seen a real 3390 in at least a decade. Storage volumes are all virtual now. Why not just make 'em as big as you need and be done with all this nuttiness? CC But the 3390-3 is the perfect size! Everybody __knows__ that 3390-9 or larger volumes are just too slow. Oh, what? PAV? Doesn't that cost extra or something? Oh, and doesn't it require a more advanced storage array than our ancient 2105? NO MONEY! NO MONEY! HH!!! HERESY The above is not my opinion. One manager two levels above me is trying to figure out how to outsource our z/OS from our z9BC-T02 to a shared z800 which is about 1/4 its power. Because it would save a lot of money!!! And that is what gets points now where I work. Everything is about cost. Not value. Not investment. Not ROI. Cost. Period. End of discussion. Does not make me confident in our future. Polish it up and sell it fast! (we are owned by an Investment group right now). -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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
SMP/E packaging of maintence / products (was: FMID descriptions)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kurt Quackenbush Sent: Friday, May 29, 2009 1:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions ... I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. You could do UNLOAD FUNCTIONS instead of LIST and that output should be much easier to parse. Kurt Q, feel free to jump in here and tell me that it is possible run some report that just provides these two pieces of information. Just provides FMID and DESCRIPTION? Nope, nothing that simple exists. What fun would that be? You could of course write a program (a real program, not REXX) that uses GIMAPI to read the zone and extract exactly this info, but I dare say its not for the faint of heart. Kurt Quackenbush -- IBM, SMP/E Development Kurt, Could I ask a question which I know you likely cannot answer. But, if possible, could you explain why the SMP/E Internet download stuff in SMP/E uses UNIX files to store the data rather than z/OS legacy type datasets (perhaps compressed with TERSE or XMIT'ed)? The reason that I ask is that to download z/OS 1.10 and install it was a bother due to the fact that I need a single zFS filesystem which required 10 SMS managed volumes. That's because zFS files cannot be multivolume unless they are also SMS managed. What I would do in the past was just use some offline, unused, volumes for this sort of thing. My usual method of doing this is to NFS mount a USB drive on my Linux desktop to z/OS. Weird, but it keeps the storage admins off my case. Just very curious. 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: SMP/E packaging of maintence / products (was: FMID descriptions)
So far, I've been able to use one mod-9 for SMPNTS and one mod-9 for SMPWKDIR, both HFS. But it does take 3 mod-3's to hold all the various roots for z/OS. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kurt Quackenbush Sent: Friday, May 29, 2009 3:22 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMP/E packaging of maintence / products (was: FMID descriptions) McKown, John wrote: Could I ask a question which I know you likely cannot answer. But, if possible, could you explain why the SMP/E Internet download stuff in SMP/E uses UNIX files to store the data rather than z/OS legacy type datasets (perhaps compressed with TERSE or XMIT'ed)? As a matter of fact I can answer that question. Mostly because the download FTP servers and their file systems are not necessarily z/OS, and non-z/OS systems do not typically play well with z/OS data sets. We wanted to keep the package and file structure Internet-friendly (platform agnostic?) so it wouldn't matter much what kind of system was used to serve, or download. Remember, for those that cannot or choose not to download directly to z/OS, we expect the package to be downloaded to a workstation. In addition, we wanted to use a supported and standard archive/compression utility. The UNIX pax command was our choice. Therefore, UNIX files seemed like a good choice all around. I'm sure we could have made other choices, and I'm sure some folks on this list will be more than happy to point them out to me. Be that as it may, the format we landed on was and is UNIX files. It is unfortunate you have to jump through hoops to get a set of volumes to use for the download. Can you work with your storage admins to avoid this in the future? Kurt Quackenbush -- IBM, SMP/E Development -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Fri, 29 May 2009 18:22:11 -0400, Kurt Quackenbush wrote: McKown, John wrote: Could I ask a question which I know you likely cannot answer. But, if possible, could you explain why the SMP/E Internet download stuff in SMP/E uses UNIX files to store the data rather than z/OS legacy type datasets (perhaps compressed with TERSE or XMIT'ed)? As a matter of fact I can answer that question. Mostly because the download FTP servers and their file systems are not necessarily z/OS, and non-z/OS systems do not typically play well with z/OS data sets. We wanted to keep the package and file structure Internet-friendly (platform agnostic?) so it wouldn't matter much what kind of system was used to serve, or download. Remember, for those that cannot or choose not to download directly to z/OS, we expect the package to be downloaded to a workstation. In addition, we wanted to use a supported and standard archive/compression utility. The UNIX pax command was our choice. Therefore, UNIX files seemed like a good choice all around. I'm sure we could have made other choices, and I'm sure some folks on this list will be more than happy to point them out to me. Be that as it may, the format we landed on was and is UNIX files. It is unfortunate you have to jump through hoops to get a set of volumes to use for the download. Can you work with your storage admins to avoid this in the future? We've had similar complaints relayed from our customers. Fortunately, I can dispel them by saying we're following IBM's lead. Fortunately none of our products is so large as to encounter the multi-volume constraint. There's a diachronic component: TERSE, perhaps not standard in the same sense as pax, is now supported, but it was not supported in the time frame in which IBM wanted to provide Internet delivery. XMIT is bulky. But IBM uses XMIT to deliver the Rational product suite. Both TERSE and XMIT are Internet-friendly. They can't be extracted on workstations (well, shareware (unsupported) exists for XMIT; I don't know about TERSE). But there's no need to extract on the workstations. That happens on the Z. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
McKown, John wrote: Could I ask a question which I know you likely cannot answer. But, if possible, could you explain why the SMP/E Internet download stuff in SMP/E uses UNIX files to store the data rather than z/OS legacy type datasets (perhaps compressed with TERSE or XMIT'ed)? As a matter of fact I can answer that question. Mostly because the download FTP servers and their file systems are not necessarily z/OS, and non-z/OS systems do not typically play well with z/OS data sets. We wanted to keep the package and file structure Internet-friendly (platform agnostic?) so it wouldn't matter much what kind of system was used to serve, or download. Remember, for those that cannot or choose not to download directly to z/OS, we expect the package to be downloaded to a workstation. In addition, we wanted to use a supported and standard archive/compression utility. The UNIX pax command was our choice. Therefore, UNIX files seemed like a good choice all around. I'm sure we could have made other choices, and I'm sure some folks on this list will be more than happy to point them out to me. Be that as it may, the format we landed on was and is UNIX files. It is unfortunate you have to jump through hoops to get a set of volumes to use for the download. Can you work with your storage admins to avoid this in the future? Kurt Quackenbush -- IBM, SMP/E Development -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
Kurt, I also find this a pain in the a__. Is it still IBM's purpose to 'Make this more difficult so we will understand it' You took something that worked real well and messed it up. How about two procedures, one for the z/OS-z/VM and one for HFS/OMVS/UNIX fixes??? --- On Fri, 5/29/09, Kurt Quackenbush ku...@us.ibm.com wrote: From: Kurt Quackenbush ku...@us.ibm.com Subject: Re: SMP/E packaging of maintence / products (was: FMID descriptions) To: IBM-MAIN@bama.ua.edu Date: Friday, May 29, 2009, 6:22 PM McKown, John wrote: Could I ask a question which I know you likely cannot answer. But, if possible, could you explain why the SMP/E Internet download stuff in SMP/E uses UNIX files to store the data rather than z/OS legacy type datasets (perhaps compressed with TERSE or XMIT'ed)? As a matter of fact I can answer that question. Mostly because the download FTP servers and their file systems are not necessarily z/OS, and non-z/OS systems do not typically play well with z/OS data sets. We wanted to keep the package and file structure Internet-friendly (platform agnostic?) so it wouldn't matter much what kind of system was used to serve, or download. Remember, for those that cannot or choose not to download directly to z/OS, we expect the package to be downloaded to a workstation. In addition, we wanted to use a supported and standard archive/compression utility. The UNIX pax command was our choice. Therefore, UNIX files seemed like a good choice all around. I'm sure we could have made other choices, and I'm sure some folks on this list will be more than happy to point them out to me. Be that as it may, the format we landed on was and is UNIX files. It is unfortunate you have to jump through hoops to get a set of volumes to use for the download. Can you work with your storage admins to avoid this in the future? Kurt Quackenbush -- IBM, SMP/E Development -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Fri, 29 May 2009 16:00:47 -0700, Howard Rifkind wrote: I also find this a pain in the a__. Is it still IBM's purpose to 'Make this more difficult so we will understand it' You took something that worked real well and messed it up. Err... How did the earlier something work real well for Internet delivery? PTFs, perhaps, but not FUNCTIONs with Relative Files. How about two procedures, one for the z/OS-z/VM and one for HFS/OMVS/UNIX fixes??? Yukk! You would have the z/OS customer deal with two procedures, since z/OS sooner or later involves HFS/OMVS/UNIX fixes? That's two PITAs. However, since everything going into SMP/E, even for the HFS/OMVS/UNIX fixes funnels through SMPPTFIN or RELFILEs, both of which are Classic data sets, a single procedure could work for both. Likewise, the current procedure works for both. There's little cause to change 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: SMP/E packaging of maintence / products (was: FMID descriptions)
Wasn't IBM going to, at one point, wrap something around SMP/E so that it essentially ran under the covers and the user had a *much* simpler interface (so to speak)?? -- All the best, Scott T. Harder On 5/29/09, Paul Gilmartin paulgboul...@aim.com wrote: On Fri, 29 May 2009 16:00:47 -0700, Howard Rifkind wrote: I also find this a pain in the a__. Is it still IBM's purpose to 'Make this more difficult so we will understand it' You took something that worked real well and messed it up. Err... How did the earlier something work real well for Internet delivery? PTFs, perhaps, but not FUNCTIONs with Relative Files. How about two procedures, one for the z/OS-z/VM and one for HFS/OMVS/UNIX fixes??? Yukk! You would have the z/OS customer deal with two procedures, since z/OS sooner or later involves HFS/OMVS/UNIX fixes? That's two PITAs. However, since everything going into SMP/E, even for the HFS/OMVS/UNIX fixes funnels through SMPPTFIN or RELFILEs, both of which are Classic data sets, a single procedure could work for both. Likewise, the current procedure works for both. There's little cause to change 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 -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
On Fri, 29 May 2009, Kurt Quackenbush wrote: snip I'm sure we could have made other choices, and I'm sure some folks on this list will be more than happy to point them out to me. Be that as it may, the format we landed on was and is UNIX files. It is unfortunate you have to jump through hoops to get a set of volumes to use for the download. Can you work with your storage admins to avoid this in the future? Kurt Quackenbush -- IBM, SMP/E Development Kurt, Thanks for the information. I really was just curious. I only had to use z/OS resident UNIX files once, but it was to install z/OS 1.10. That was due to something, which was never determined, on my Linux desktop causing a huge spike in Internet traffic. The LAN security gestapo disconnected my ethernet port, so no NFS to my z/OS system. I wanted to expand the UNIX filesystem SMS pool, but management is weird around here. They don't mind offline, unused, volumes. But they track how many DASD volumes are allocated to a storage pool and get upset if the usage in a pool is too low. I just don't understand them at all. As to working with the storage admins, well, we really only had one storage admin. He was in our group (we are all multifunction). He was let go this last Tuesday in our ongoing downsizing of the entire company. He had a lot of ways of doing things that I disagreed with, but he also did 99.99% of the work, so I did things his way. In the future, I will simply take some offline volumes and put them in a temporary storage group when I need short term UNIX filesystem space and can't use NFS mounting for some reason. He didn't do that because his method was to pick an offline volume pretty much at random when he needed to expand a pool, and didn't bother to ask if anybody was using it, or look to see if it had any DSNs on it. He just nuked it. Oh, just for information, he was an older gentleman in his early 70s. He was already retired from IBM and was considering leaving due to the stress of the job (high blood pressure - went away on vacation, came back when he came back to work). So, thankfully, he is still doing well financially. My retirement account contains a Glock and a bullet. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
At 18:12 -0500 on 05/29/2009, Paul Gilmartin wrote about Re: SMP/E packaging of maintence / products (was: FMID desc: On Fri, 29 May 2009 16:00:47 -0700, Howard Rifkind wrote: I also find this a pain in the a__. Is it still IBM's purpose to 'Make this more difficult so we will understand it' You took something that worked real well and messed it up. Err... How did the earlier something work real well for Internet delivery? PTFs, perhaps, but not FUNCTIONs with Relative Files. Store the flattened PDS files in a PDS as members and export that as a Flat File. To recreate, you just Import the supplied Exported PDS, use supplied JCL to create a PUT Tape by copying the members which is then read into SMP/E as usual. -- 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: SMP/E packaging of maintence / products (was: FMID descriptions)
good grief, why do you keep fighting with the storage admins? make one zFS download extended format dataset on ONE permanently mounted mod 54 volume, and be done with it. use that download file system for z/OS, cics, db2, program products, etc. Use skulker to keep it clean of old files. Bobbie Justice -Original Message- From: McKown, John jmck...@healthmarkets.com Sent: May 29, 2009 3:45 PM To: IBM-MAIN@bama.ua.edu Subject: SMP/E packaging of maintence / products (was: FMID descriptions) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kurt Quackenbush Sent: Friday, May 29, 2009 1:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions ... I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. You could do UNLOAD FUNCTIONS instead of LIST and that output should be much easier to parse. Kurt Q, feel free to jump in here and tell me that it is possible run some report that just provides these two pieces of information. Just provides FMID and DESCRIPTION? Nope, nothing that simple exists. What fun would that be? You could of course write a program (a real program, not REXX) that uses GIMAPI to read the zone and extract exactly this info, but I dare say its not for the faint of heart. Kurt Quackenbush -- IBM, SMP/E Development Kurt, Could I ask a question which I know you likely cannot answer. But, if possible, could you explain why the SMP/E Internet download stuff in SMP/E uses UNIX files to store the data rather than z/OS legacy type datasets (perhaps compressed with TERSE or XMIT'ed)? The reason that I ask is that to download z/OS 1.10 and install it was a bother due to the fact that I need a single zFS filesystem which required 10 SMS managed volumes. That's because zFS files cannot be multivolume unless they are also SMS managed. What I would do in the past was just use some offline, unused, volumes for this sort of thing. My usual method of doing this is to NFS mount a USB drive on my Linux desktop to z/OS. Weird, but it keeps the storage admins off my case. Just very curious. 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 PeoplePC Online A better way to Internet http://www.peoplepc.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
