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: Subject: FMID descriptions
Jim, Share with me too, please! Thanks, Linda Mooney - Original Message - From: Jim Holloway jhollo...@metlife.com To: IBM-MAIN@bama.ua.edu Sent: Saturday, May 30, 2009 6:10:25 AM GMT -08:00 US/Canada Pacific Subject: Re: Subject: FMID descriptions Bob, My shop does annual serverpacs and what I did was to generate the CPAC products report to a pre-allocated dataset. I then wrote an exec to parse out all the FMIDs and their plain English equivalents. We use this to provide dynamically generated web pages to publish what maintenence we've applied during a given maintenence cycle. I've also used GIMAPI and Rexx code to extract the same data from the CSI. I'd be happy to share so if you'd like so please let me know. Jim Holloway - MetLife jhollo...@metlife.com IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 05/30/2009 12:00:03 AM: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Thursday, May 28, 2009 12:16 PM To: IBM-MAIN@bama.ua.edu Subject: FMID descriptions Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) Bob The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- 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: FMID descriptions
Paul Gilmartin pisze: On Sun, 31 May 2009 07:49:12 -0700, Howard Rifkind wrote: Would it be wonderful if IBM could just figure out how to make the FMID's really directly relate the the software product name... Particularly, why not allow FMIDs to be much longer than 7 characters (say about 50 characters) so a meaningful product name could be embedded in the FMID? ROTFL! It's like, like allowing lowercase symbols in JCL! It could be even convenient - which is strictly forbidden in mainframe world! We have to live with SRELs (only historicians knows the root of the name and nobody know the reasons for that), 7-characters FMIDs and many other facilities. Coulldn't resist... -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: FMID descriptions
That rexx exec does not work for me. Where should it be executed? Option 6? From within the smp dialog? How does it find this table? Anything easier to use out there? -- 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: FMID descriptions
Ken,
Like me, you probably do not have the SMP/E ISPTLIB pre-allocated.
Add a LIBDEF statement before the TBOPEN
'LIBDEF ISPTLIB DATASET ID(''SYS1.GIM.SGIMTENU'')'
and after the TBCLOSE
'LIBDEF ISPTLIB'
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ken Klein
Sent: Monday, June 01, 2009 8:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FMID descriptions
That rexx exec does not work for me. Where should it be executed?
Option 6?
From within the smp dialog? How does it find this table?
Anything easier to use out there?
--
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: FMID descriptions
There's a hopeful note here. If you're correct in your plausible surmise that Kurt was engaging in (displaced) self-deprecation, it implies he's sensitive to the concern. I am sensitive to the concern. I'd like to provide a REXX interface to GIMAPI, but unfortunately its priority doesn't compare to other work. Next time I'll remember to include a smiley in my response. 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: FMID descriptions
Richards, Robert B. wrote: Unless I coded it wrong SET BDY(TARGET). UNLOAD SYSMODS FUNCTIONS., why do you think it is easier? Both UNLOAD and LIST are multi-line reports. To me having the values delineated by subentrytype(value) seems a bit easier to parse and pick off the stuff you want. Yes you still have to parse multi-line output. I suppose its six of one, half a dozen of the other. How about providing the FMID description on the summary section of the ERROR SYSMOD report? :-) The print line has the room! grin Duly noted. In the absence of that, do you approve of the BCNFMDS method as being accurate? Yes, that is accurate and seems a fine use for your purposes. Although we have no plans right now that would affect the BCNFMDS table, understand of course the usual caveats apply -- it's not a published program interface, so in the future we could change the structure of that table, eliminate it, etc. 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: FMID descriptions
Kurt, Caveats understood. In case some are wondering, the reason I am providing this information is to satisfy a request for auditing/security purposes by providing what I like to call pseudo vulnerability scanning reports. We all know that our favorite platform is not very vulnerable when using the Windows platform as the baseline standard for this topic, but I had to come up with something to report on and ERROR SYSMODS seemed to fit the bill. Yeah, I know, it's a stretch, but they seemed to like the idea. :-) I had to provide the English descriptions for the FMIDs and even with them, the intended audience will probably not have a clue as to what they do. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kurt Quackenbush Sent: Monday, June 01, 2009 9:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions Richards, Robert B. wrote: Unless I coded it wrong SET BDY(TARGET). UNLOAD SYSMODS FUNCTIONS., why do you think it is easier? Both UNLOAD and LIST are multi-line reports. To me having the values delineated by subentrytype(value) seems a bit easier to parse and pick off the stuff you want. Yes you still have to parse multi-line output. I suppose its six of one, half a dozen of the other. How about providing the FMID description on the summary section of the ERROR SYSMOD report? :-) The print line has the room! grin Duly noted. In the absence of that, do you approve of the BCNFMDS method as being accurate? Yes, that is accurate and seems a fine use for your purposes. Although we have no plans right now that would affect the BCNFMDS table, understand of course the usual caveats apply -- it's not a published program interface, so in the future we could change the structure of that table, eliminate it, etc. 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)
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: FMID descriptions
Would it be wonderful if IBM could just figure out how to make the FMID's really directly relate the the software product name... --- On Sat, 5/30/09, Richards, Robert B. robert.richa...@opm.gov wrote: From: Richards, Robert B. robert.richa...@opm.gov Subject: Re: FMID descriptions To: IBM-MAIN@bama.ua.edu Date: Saturday, May 30, 2009, 4:25 PM I will checkout the Migration Assistant BIN file, but so far, the BCNFMDS table entries seem to have the most complete English descriptions. And since I now have working code to read those entries, I have a potential solution. My follow-on to Kurt was to ask him if that is an adequate source that is updated continually. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Saturday, May 30, 2009 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions On Fri, 29 May 2009 17:54:57 -0400, Kurt Quackenbush ku...@us.ibm.com wrote: Mark Zelden wrote: Bob and I spoke off-list about this. SMP/E is a bad spot for what he is looking for. Too many FMIDs are part of z/OS base. For example, RACF (HRF*). Huh? Given the FMIDs reported by REPORT ERRSYSMODS, I thought Bob was asking for a method to obtain the DESCRIPTION for said FMIDs. Is that not the case? Bob, if not the FMID Descriptions, what exactly are you looking for? An example would be helpful. Sorry, I was referring to the output of LIST PRODUCT (which doesn't show FMIDs) or LIST FEATURE which lumps a bunch of FMIDs into z/OS V1 Base. I hadn't thought of the migration assistant... but I remember Bob mentioning it now and didn't put 2 and 2 together with the ISPF table. So Bob, If you don't want to play with ISPF tables, I think you can parse the output of a migration assistant products applied report fairly easy since there just a single line for each FMID and description and match that to the REPORT ERRORSYSMODS FMID. 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 -- 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: FMID descriptions
On Sun, 31 May 2009 07:49:12 -0700, Howard Rifkind wrote: Would it be wonderful if IBM could just figure out how to make the FMID's really directly relate the the software product name... Particularly, why not allow FMIDs to be much longer than 7 characters (say about 50 characters) so a meaningful product name could be embedded in the FMID? -- 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, 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: FMID descriptions
Kurt, Unless I coded it wrong SET BDY(TARGET). UNLOAD SYSMODS FUNCTIONS., why do you think it is easier? Both UNLOAD and LIST are multi-line reports. Regardless, thanks for replying and you were correct in your assumption as to what I was looking for. How about providing the FMID description on the summary section of the ERROR SYSMOD report? :-) The print line was the room! grin In the absence of that, do you approve of the BCNFMDS method are being accurate? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kurt Quackenbush Sent: Friday, May 29, 2009 2: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 -- 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: FMID descriptions
Yes, Mark and I did speak offline, but I had to reconsider a portion of
that conversation and Mark was unaware of that. Sorry, Mark.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Zelden
Sent: Friday, May 29, 2009 1:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FMID descriptions
On Fri, 29 May 2009 17:40:07 +0200, Miklos Szigetvari
miklos.szigetv...@isis-papyrus.com wrote:
This worked for me:
/* REXX */
ADDRESS TSO
ALLOC FI(ISPPROF) DA('ESA.ISPF.ISPPROF') SHR REUSE
ADDRESS ISPEXEC
TBOPEN BCNFMDS NOWRITE
TBTOP BCNFMDS
DO WHILE RC = 0
TBSKIP BCNFMDS
TBGET BCNFMDS ROWID(I)
SAY FMID FMIDDESC
END
TBCLOSE BCNFMDS
Richards, Robert B. wrote:
Bob and I spoke off-list about this. SMP/E is a bad spot for what he
is looking for. Too many FMIDs are part of z/OS base. For example,
RACF (HRF*).
Mark
--
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: Subject: FMID descriptions
Bob, My shop does annual serverpacs and what I did was to generate the CPAC products report to a pre-allocated dataset. I then wrote an exec to parse out all the FMIDs and their plain English equivalents. We use this to provide dynamically generated web pages to publish what maintenence we've applied during a given maintenence cycle. I've also used GIMAPI and Rexx code to extract the same data from the CSI. I'd be happy to share so if you'd like so please let me know. Jim Holloway - MetLife jhollo...@metlife.com IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 05/30/2009 12:00:03 AM: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Thursday, May 28, 2009 12:16 PM To: IBM-MAIN@bama.ua.edu Subject: FMID descriptions Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) Bob The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- 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: FMID descriptions
Wow, my English was horrible in the previous post. More coffee, please! I meant to say The print line HAS the room and ... AS being accurate. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Saturday, May 30, 2009 9:04 AM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions Kurt, Unless I coded it wrong SET BDY(TARGET). UNLOAD SYSMODS FUNCTIONS., why do you think it is easier? Both UNLOAD and LIST are multi-line reports. Regardless, thanks for replying and you were correct in your assumption as to what I was looking for. How about providing the FMID description on the summary section of the ERROR SYSMOD report? :-) The print line was the room! grin In the absence of that, do you approve of the BCNFMDS method are being accurate? Bob -- 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: Subject: FMID descriptions
Jim, Absolutely, I would be interested in looking at it. Thanks for offering. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jim Holloway Sent: Saturday, May 30, 2009 9:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Subject: FMID descriptions Bob, My shop does annual serverpacs and what I did was to generate the CPAC products report to a pre-allocated dataset. I then wrote an exec to parse out all the FMIDs and their plain English equivalents. We use this to provide dynamically generated web pages to publish what maintenence we've applied during a given maintenence cycle. I've also used GIMAPI and Rexx code to extract the same data from the CSI. I'd be happy to share so if you'd like so please let me know. Jim Holloway - MetLife jhollo...@metlife.com IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 05/30/2009 12:00:03 AM: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Thursday, May 28, 2009 12:16 PM To: IBM-MAIN@bama.ua.edu Subject: FMID descriptions Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) Bob The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- 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, 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: FMID descriptions
On Sat, 30 May 2009 09:14:33 +1000, Shane wrote: On Fri, 2009-05-29 at 17:52 -0500, Paul Gilmartin wrote: Grrr. (Bristling at the aura of condescension.) It's an unconscionable oversight that SMP/E elected to design GIMAPI in a Rexx-hostile style. I'd be prepared to cut Kurt some slack, and trust his answer was composed with a modicum of levity rather than condescension. Much as we continually call for APIs for general usage, this particular one I found a mongrel to use. As I'm sure a I've said before. Point taken. I let my frustration at absence of Rexx support blunt my sense of humor. There's a hopeful note here. If you're correct in your plausible surmise that Kurt was engaging in (displaced) self-deprecation, it implies he's sensitive to the concern. -- 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: FMID descriptions
On Fri, 29 May 2009 17:54:57 -0400, Kurt Quackenbush ku...@us.ibm.com wrote: Mark Zelden wrote: Bob and I spoke off-list about this. SMP/E is a bad spot for what he is looking for. Too many FMIDs are part of z/OS base. For example, RACF (HRF*). Huh? Given the FMIDs reported by REPORT ERRSYSMODS, I thought Bob was asking for a method to obtain the DESCRIPTION for said FMIDs. Is that not the case? Bob, if not the FMID Descriptions, what exactly are you looking for? An example would be helpful. Sorry, I was referring to the output of LIST PRODUCT (which doesn't show FMIDs) or LIST FEATURE which lumps a bunch of FMIDs into z/OS V1 Base. I hadn't thought of the migration assistant... but I remember Bob mentioning it now and didn't put 2 and 2 together with the ISPF table. So Bob, If you don't want to play with ISPF tables, I think you can parse the output of a migration assistant products applied report fairly easy since there just a single line for each FMID and description and match that to the REPORT ERRORSYSMODS FMID. 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: 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: FMID descriptions
I will checkout the Migration Assistant BIN file, but so far, the BCNFMDS table entries seem to have the most complete English descriptions. And since I now have working code to read those entries, I have a potential solution. My follow-on to Kurt was to ask him if that is an adequate source that is updated continually. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Saturday, May 30, 2009 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions On Fri, 29 May 2009 17:54:57 -0400, Kurt Quackenbush ku...@us.ibm.com wrote: Mark Zelden wrote: Bob and I spoke off-list about this. SMP/E is a bad spot for what he is looking for. Too many FMIDs are part of z/OS base. For example, RACF (HRF*). Huh? Given the FMIDs reported by REPORT ERRSYSMODS, I thought Bob was asking for a method to obtain the DESCRIPTION for said FMIDs. Is that not the case? Bob, if not the FMID Descriptions, what exactly are you looking for? An example would be helpful. Sorry, I was referring to the output of LIST PRODUCT (which doesn't show FMIDs) or LIST FEATURE which lumps a bunch of FMIDs into z/OS V1 Base. I hadn't thought of the migration assistant... but I remember Bob mentioning it now and didn't put 2 and 2 together with the ISPF table. So Bob, If you don't want to play with ISPF tables, I think you can parse the output of a migration assistant products applied report fairly easy since there just a single line for each FMID and description and match that to the REPORT ERRORSYSMODS FMID. 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 -- 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
Re: FMID descriptions
Wow, the replies to my query were overwhelming! Perhaps I should change the subject line to Book on Poughkeepsie! grin -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Thursday, May 28, 2009 12:16 PM To: IBM-MAIN@bama.ua.edu Subject: FMID descriptions Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) Bob -- 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: FMID descriptions
Wow, the replies to my query were overwhelming! Perhaps I should change the subject line to Book on Poughkeepsie! Nobody is required to respond; we're all volunteers. Maybe nobody has the answer, or they are busy. - Too busy driving to stop for gas! -- 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: FMID descriptions
Hi Seems to me as standard ISPF table, and the KEY is the FMID. You can get the row's via TBGET Richards, Robert B. wrote: Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) Bob -- 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 -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- 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: FMID descriptions
Really Ted? Did you really think that I did not know that after all my years on this list? Lighten up! Can't you spot a tongue-in-cheek post when you see one? Bob - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, May 29, 2009 11:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions Wow, the replies to my query were overwhelming! Perhaps I should change the subject line to Book on Poughkeepsie! Nobody is required to respond; we're all volunteers. Maybe nobody has the answer, or they are busy. -- 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: FMID descriptions
This worked for me:
/* REXX */
ADDRESS TSO
ALLOC FI(ISPPROF) DA('ESA.ISPF.ISPPROF') SHR REUSE
ADDRESS ISPEXEC
TBOPEN BCNFMDS NOWRITE
TBTOP BCNFMDS
DO WHILE RC = 0
TBSKIP BCNFMDS
TBGET BCNFMDS ROWID(I)
SAY FMID FMIDDESC
END
TBCLOSE BCNFMDS
Richards, Robert B. wrote:
Does anyone have any REXX code to grab English description FMID table
entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in
question?
I am writing some code to parse information from the ERROR SYSMODS
Report and want to provide the reader with ICKDSF instead of EDU1H01, et
al. I looked at the various SMP/E LIST commands, but parsing any one of
those reports seems to be overkill for my purposes.
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. I looked
in the archives and see that others have cut and paste some of this info
from web pages or have their own lists, but am looking for something
that would be automatically updated based on my product set.
Other suggestions are also welcome! :-)
Bob
--
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
--
Miklos Szigetvari
Development Team
ISIS Information Systems Gmbh
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com
Hotline: +43-2236-27551-111
Visit our Website: http://www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---
--
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: FMID descriptions
Really Ted? Did you really think that I did not know that after all my years on this list? Lighten up! Can't you spot a tongue-in-cheek post when you see one? And, when I said maybe nobody knows, how serious was I. - Too busy driving to stop for gas! -- 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: FMID descriptions
Okay. Point taken. Truce! TGIF! :-) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, May 29, 2009 11:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions Really Ted? Did you really think that I did not know that after all my years on this list? Lighten up! Can't you spot a tongue-in-cheek post when you see one? And, when I said maybe nobody knows, how serious was I. - Too busy driving to stop for gas! -- 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: FMID descriptions
Thank you, Miklos. I appreciate your response.
Bob
-
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Miklos Szigetvari
Sent: Friday, May 29, 2009 11:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FMID descriptions
This worked for me:
/* REXX */
ADDRESS TSO
ALLOC FI(ISPPROF) DA('ESA.ISPF.ISPPROF') SHR REUSE
ADDRESS ISPEXEC
TBOPEN BCNFMDS NOWRITE
TBTOP BCNFMDS
DO WHILE RC = 0
TBSKIP BCNFMDS
TBGET BCNFMDS ROWID(I)
SAY FMID FMIDDESC
END
TBCLOSE BCNFMDS
Richards, Robert B. wrote:
Does anyone have any REXX code to grab English description FMID table
entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in
question?
I am writing some code to parse information from the ERROR SYSMODS
Report and want to provide the reader with ICKDSF instead of EDU1H01,
et
al. I looked at the various SMP/E LIST commands, but parsing any one of
those reports seems to be overkill for my purposes.
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. I
looked
in the archives and see that others have cut and paste some of this
info
from web pages or have their own lists, but am looking for something
that would be automatically updated based on my product set.
Other suggestions are also welcome! :-)
Bob
--
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
--
Miklos Szigetvari
Development Team
ISIS Information Systems Gmbh
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com
Hotline: +43-2236-27551-111
Visit our Website: http://www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---
--
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: FMID descriptions
Okay. Point taken. Truce! TGIF! :-)
Truce.
It's sometimes hard to tell how serious people aren't from the written word.
I forgot to include a smiley.
I have a custom-designed one:
(8-{]}
Bald head, glasses, nose, mustache, smile, beard.
-
Too busy driving to stop for gas!
--
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: FMID descriptions
2009/5/28 Richards, Robert B. robert.richa...@opm.gov Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) It looks like a set of ordinary ISPF tables... I mean, you can go into Dialog Test, browse the table, and find entries by FMID Display row Table BCNFMDS row 4 Row found Command === Scroll === CSR Variable T A Value FMID K EDU1H01 FMIDDESC N ICKDSF - Device Support Facili FMWRK1 N so presumably you can call the ISPF table services from REXX to do the same. Just TBOPEN and TBGET, I think. But perhaps this part is obvious, and I'm not understanding the real point of your question. Do you need to do this without having access to ISPF services? In that case, you could prepopulate a dataset in some format of your own choosing from the ISPF tables, and then scan it directly in REXX. The IBM PMA download at ftp://ftp.software.ibm.com/s390/pma/bcnitenu.bin has the whole thing (30+ MB) already in the ISPF table format, but you could even download and parse that on the fly if you need extreme currency, I suppose. Tony H. -- 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: FMID descriptions
Tony, I'll definitely look into that web link. In the meantime, thanks to Miklos and especially to Bob Rutledge, I have a working solution that I can modify to suit my own purposes. Now, I wonder if Kurt will chime in? grin Bob - -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony Harminc Sent: Friday, May 29, 2009 12:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FMID descriptions 2009/5/28 Richards, Robert B. robert.richa...@opm.gov Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) It looks like a set of ordinary ISPF tables... I mean, you can go into Dialog Test, browse the table, and find entries by FMID Display row Table BCNFMDS row 4 Row found Command === Scroll === CSR Variable T A Value FMID K EDU1H01 FMIDDESC N ICKDSF - Device Support Facili FMWRK1 N so presumably you can call the ISPF table services from REXX to do the same. Just TBOPEN and TBGET, I think. But perhaps this part is obvious, and I'm not understanding the real point of your question. Do you need to do this without having access to ISPF services? In that case, you could prepopulate a dataset in some format of your own choosing from the ISPF tables, and then scan it directly in REXX. The IBM PMA download at ftp://ftp.software.ibm.com/s390/pma/bcnitenu.bin has the whole thing (30+ MB) already in the ISPF table format, but you could even download and parse that on the fly if you need extreme currency, I suppose. Tony H. -- 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: FMID descriptions
On Fri, 29 May 2009 17:40:07 +0200, Miklos Szigetvari
miklos.szigetv...@isis-papyrus.com wrote:
This worked for me:
/* REXX */
ADDRESS TSO
ALLOC FI(ISPPROF) DA('ESA.ISPF.ISPPROF') SHR REUSE
ADDRESS ISPEXEC
TBOPEN BCNFMDS NOWRITE
TBTOP BCNFMDS
DO WHILE RC = 0
TBSKIP BCNFMDS
TBGET BCNFMDS ROWID(I)
SAY FMID FMIDDESC
END
TBCLOSE BCNFMDS
Richards, Robert B. wrote:
Bob and I spoke off-list about this. SMP/E is a bad spot for what he
is looking for. Too many FMIDs are part of z/OS base. For example,
RACF (HRF*).
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: 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 -- 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: FMID descriptions
Mark Zelden wrote: Bob and I spoke off-list about this. SMP/E is a bad spot for what he is looking for. Too many FMIDs are part of z/OS base. For example, RACF (HRF*). Huh? Given the FMIDs reported by REPORT ERRSYSMODS, I thought Bob was asking for a method to obtain the DESCRIPTION for said FMIDs. Is that not the case? Bob, if not the FMID Descriptions, what exactly are you looking for? An example would be helpful. 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)
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: FMID descriptions
On Fri, 29 May 2009 14:43:25 -0400, Kurt Quackenbush wrote: 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. Grrr. (Bristling at the aura of condescension.) It's an unconscionable oversight that SMP/E elected to design GIMAPI in a Rexx-hostile style. For an example of how an API can be designed to be Rexx-friendly, study the API to ICSF; example in SAMPLIB. -- 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)
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: FMID descriptions
On Fri, 2009-05-29 at 17:52 -0500, Paul Gilmartin wrote: Grrr. (Bristling at the aura of condescension.) It's an unconscionable oversight that SMP/E elected to design GIMAPI in a Rexx-hostile style. I'd be prepared to cut Kurt some slack, and trust his answer was composed with a modicum of levity rather than condescension. Much as we continually call for APIs for general usage, this particular one I found a mongrel to use. As I'm sure a I've said before. Shane ... -- 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
FMID descriptions
Does anyone have any REXX code to grab English description FMID table entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in question? I am writing some code to parse information from the ERROR SYSMODS Report and want to provide the reader with ICKDSF instead of EDU1H01, et al. I looked at the various SMP/E LIST commands, but parsing any one of those reports seems to be overkill for my purposes. 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. I looked in the archives and see that others have cut and paste some of this info from web pages or have their own lists, but am looking for something that would be automatically updated based on my product set. Other suggestions are also welcome! :-) Bob -- 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
