Re: Style (was: Newbie SMP/E questions)
LISTSERV and Netnews are both good; Stack Exchange is not bad; most of the other options run from bad on down. I find both gmail and outlook to be pathetic. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Monday, February 4, 2019 10:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Style (was: Newbie SMP/E questions) Random thoughts... The fundamental issue is that email isn't the best way to handle online group conversations. Many better solutions have been offered, from NNTP, Notes, Stack Exchange, Slash Dot, and Lord knows how many others. SX is extremely protective of their software, and for whatever reasons, none of the general solutions ever seem to catch on. Gmail does a pretty good job of managing this list for me. It does however, make it far to easy to regurgitate all previous messages as in-line quoting. I have gotten in the habit of trimming that (usually). Automatic quoting of the previous message is practically evil. Why we put up with that is beyond my understanding. No previous communication technology did that. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
On Mon, 4 Feb 2019 22:06:43 -0500, Gord Tomlin wrote: > >In Thunderbird, look in your account settings. Under composition and >addressing, you will find what you want. > Ah! Account specific because I might want different behaviors for my work account and my personal account. On Mon, 4 Feb 2019 22:24:59 -0500, Steve Smith wrote: > >Automatic quoting of the previous message is practically evil. Why we put >up with that is beyond my understanding. No previous communication >technology did that. > I'm imagining a telephone's doing that for me. But I select automatic quoting, then trim and interleave replies. (On a list I sometimes reply to two plies at once.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
Random thoughts... The fundamental issue is that email isn't the best way to handle online group conversations. Many better solutions have been offered, from NNTP, Notes, Stack Exchange, Slash Dot, and Lord knows how many others. SX is extremely protective of their software, and for whatever reasons, none of the general solutions ever seem to catch on. Gmail does a pretty good job of managing this list for me. It does however, make it far to easy to regurgitate all previous messages as in-line quoting. I have gotten in the habit of trimming that (usually). Automatic quoting of the previous message is practically evil. Why we put up with that is beyond my understanding. No previous communication technology did that. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
On 2019-02-04 21:39, Paul Gilmartin wrote: I thought I recalled a MUA where Preferences gave the option of positioning the text input cursor at either top of bottom when replying. Today I see that in neither Mac Mail.app nor Thunderbird. In Thunderbird, look in your account settings. Under composition and addressing, you will find what you want. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
On Mon, 4 Feb 2019 21:12:15 -0500, Phil Smith III wrote: > >>Indeed. Some prohibit editing quoted text, deeming it a form of forgery. >>That leads to a pernicious accumulation of footers and a secular bloat of >>text. > >... For corporate >communications, top-posting isn't a bad thing: folks get added to threads, and >can then understand WTF is going on. Bottom-posting >would be a major pain in some of the customer threads I'm on, which go on for >weeks and dozens or hundreds of notes. > When I add someone to a thread, I try to quote *relevant* previous plies. >For a mailing list, it's clearly dumb, for the reasons Gil notes. > >The sad thing is that no client seems to have figured this out, perhaps >providing a button that will flip formats. Or allowing a >marker in the address book indicating the style to use for specific >addressees. Or any number of other options. > I thought I recalled a MUA where Preferences gave the option of positioning the text input cursor at either top of bottom when replying. Today I see that in neither Mac Mail.app nor Thunderbird. Mail.app gives the option of quoting either all or only selected text. Almost needless -- I can edit ad lib. A colleague complained about my bottom-posting saying she reflexively deletes any message when she has seen the first line before. LISTSERV provides the option of showing the first line on mouseover. Would that it were the first *unquoted* line. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
Paul Gilmartin wrote, re reply styles: >Indeed. Some prohibit editing quoted text, deeming it a form of forgery. >That leads to a pernicious accumulation of footers and a secular bloat of text. Sigh. Not that this isn't an ancient and unlikely-to-be-resolved issue, but I'm of the strong opinion that It Depends. For corporate communications, top-posting isn't a bad thing: folks get added to threads, and can then understand WTF is going on. Bottom-posting would be a major pain in some of the customer threads I'm on, which go on for weeks and dozens or hundreds of notes. For a mailing list, it's clearly dumb, for the reasons Gil notes. The sad thing is that no client seems to have figured this out, perhaps providing a button that will flip formats. Or allowing a marker in the address book indicating the style to use for specific addressees. Or any number of other options. .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
FOR EXAMPLE //STEP0050 EXEC PGM=AMBLIST,REGION=0M //DSNLOAD DD DISP=SHR,DSN=DB2.DSNLOAD (this is not complete JCL) //SYSINDD * LISTIDR MODLIB,DDN=DSNLOAD Will produce that includes CSECT:DSNAA 01/15/2013 RSI23571390 CSECT:DSNACA00 07/13/2016 UI30682 CSECT:DSNACA70 06/05/2017 UI45412 CSECT:DSNAMTXT 01/15/2013 RSI23571427 CSECT:DSNAPRH 01/14/2013 RSI23571428 CSECT:DSNARIB 06/05/2017 UI41695 CSECT:DSNFMNFM 01/15/2013 RSI23571651 CSECT:DSNFPMSG 01/04/2018 UI48762 DATE USER DATA CSECT:DSNFSAMG 07/09/2013 UK95423 CSECT:DSNXVEOA 01/04/2018 UI49949 By extracting the ptf numbers listed you can build a "history" of what ptfs have been applied (or not applied) to any environment (to me just as important as what is in the CSI) Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services Humana Inc. 123 East Main Street Louisville, KY 40202 Humana.com (502) 476-2538 or 407-7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Monday, February 4, 2019 4:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Newbie SMP/E questions This one caught my attention. I trotted off to look up AMBLIST, and it looks like it's a utility useful to assembler programmers (see https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieav100%2Famblist.htmdata=02%7C01%7Cchoelscher%40humana.com%7C529307afb9694e91160c08d68aebf405%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C636849143369855693sdata=WJIGIAgHNB6uR1cFAfyPMXMoTLS1LyI1NGdfZvpFvzg%3Dreserved=0). I suspect that to one of my ignorance it won't tell me anything, but can you provide some background? I don't know what I would see in an ABMLISTing that would tell me anything I need to know about a CSI. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* Paramedic Rule #2: All bleeding stopseventually. -from Randy Cassingham's Rules for Paramedics (https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jumbojoke.com%2Frules_for_paramedics_996.htmldata=02%7C01%7Cchoelscher%40humana.com%7C529307afb9694e91160c08d68aebf405%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C636849143369855693sdata=K9LaEEfisQKIP8DswaT8hvJ%2F%2FK9iILjrAWKclZvZPek%3Dreserved=0) */ -Original Message- From: Chris Hoelscher Sent: Wednesday, January 30, 2019 10:59 One task I perform as part of reporting - I run amblist against the run-time loadlib to see what fixes have made it to prod/test - although CA has a utility to interrogate libraries for its products to get a clean list of what fixes (or perhaps just the most recent) Have been applied to the runtime modules The utility is CAMODID -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으
Re: Newbie SMP/E questions
On Mon, 4 Feb 2019 16:58:42 -0500, Bob Bridges wrote: >I don't know what I would see in an ABMLISTing that would tell me anything I >need to know about a CSI. AMBLIST will tell you about a load module (or program object). Given enough knowledge about the load module, it can tell you if it is correct, but in general, it won't tell you anything about a CSI. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
AMBLIST if used properly will tell you what ptf eyecatches are embedded in a load module in a runtime loadlib - this might enable you to determine how much of what has been APPLY'd to a CSI ever found its way to the runtime load library Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services Humana Inc. 123 East Main Street Louisville, KY 40202 Humana.com (502) 476-2538 or 407-7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Monday, February 4, 2019 4:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Newbie SMP/E questions This one caught my attention. I trotted off to look up AMBLIST, and it looks like it's a utility useful to assembler programmers (see https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieav100%2Famblist.htmdata=02%7C01%7Cchoelscher%40humana.com%7C529307afb9694e91160c08d68aebf405%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C636849143369855693sdata=WJIGIAgHNB6uR1cFAfyPMXMoTLS1LyI1NGdfZvpFvzg%3Dreserved=0). I suspect that to one of my ignorance it won't tell me anything, but can you provide some background? I don't know what I would see in an ABMLISTing that would tell me anything I need to know about a CSI. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* Paramedic Rule #2: All bleeding stopseventually. -from Randy Cassingham's Rules for Paramedics (https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jumbojoke.com%2Frules_for_paramedics_996.htmldata=02%7C01%7Cchoelscher%40humana.com%7C529307afb9694e91160c08d68aebf405%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C636849143369855693sdata=K9LaEEfisQKIP8DswaT8hvJ%2F%2FK9iILjrAWKclZvZPek%3Dreserved=0) */ -Original Message- From: Chris Hoelscher Sent: Wednesday, January 30, 2019 10:59 One task I perform as part of reporting - I run amblist against the run-time loadlib to see what fixes have made it to prod/test - although CA has a utility to interrogate libraries for its products to get a clean list of what fixes (or perhaps just the most recent) Have been applied to the runtime modules The utility is CAMODID -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
This one caught my attention. I trotted off to look up AMBLIST, and it looks like it's a utility useful to assembler programmers (see https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieav100/amblist.htm). I suspect that to one of my ignorance it won't tell me anything, but can you provide some background? I don't know what I would see in an ABMLISTing that would tell me anything I need to know about a CSI. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* Paramedic Rule #2: All bleeding stopseventually. -from Randy Cassingham's Rules for Paramedics (http://www.jumbojoke.com/rules_for_paramedics_996.html) */ -Original Message- From: Chris Hoelscher Sent: Wednesday, January 30, 2019 10:59 One task I perform as part of reporting - I run amblist against the run-time loadlib to see what fixes have made it to prod/test - although CA has a utility to interrogate libraries for its products to get a clean list of what fixes (or perhaps just the most recent) Have been applied to the runtime modules The utility is CAMODID -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
On Sun, 3 Feb 2019 21:17:26 +, Seymour J Metz wrote: >> What ever became of the venerable practice of interleaving replies close to >> the paragraphs to which they refer > >B0rken e-mail software that makes difficult to DTRT, and, in some cases, >management that actually directs doing the wrong thing. > Indeed. Some prohibit editing quoted text, deeming it a form of forgery. That leads to a pernicious accumulation of footers and a secular bloat of text. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
> What ever became of the venerable practice of interleaving replies close to > the paragraphs to which they refer B0rken e-mail software that makes difficult to DTRT, and, in some cases, management that actually directs doing the wrong thing. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, January 29, 2019 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Style (was: Newbie SMP/E questions) On Tue, 29 Jan 2019 16:23:06 +, David Spiegel wrote: >Hi Bob, >2) Yes for the current situation. If, however, PTFs between base and >your new PTFs are ACCEPTd, no. >> ... [about 20 lines skipped] >> Question #2) ... What ever became of the venerable practice of interleaving replies close to the paragraphs to which they refer so the reader doesn't need to hop up and down in the page? Top-posting is execrable. It's harder for both the poster and the reader. (Of course it helps if the depth of quoted text is clearly identified -- that was not a problem in this thread.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
I hate to be defending some anonymous old fogey, but his message is intended to endorse regular and rigorous maintenance, not to criticize it. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, February 01, 2019 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Newbie SMP/E questions W dniu 2019-02-01 o 19:50, Tom Conley pisze: > On 2/1/2019 12:22 PM, Jesse 1 Robinson wrote: >> I'd like to explore this teaser post. I was (I think also) dubious >> about the original comment in that it seems to disparage--or at least >> discourage--mass service like RSU, which I view as a major advance in >> software maintenance. Is there really wide-spread distrust of an >> "unavoidable 'push'"? >> >> . >> . > > A wise man once said, "If it ain't broke, don't fix it, but with z/OS, > it's ALWAYS broke!" Older guy, beard, wore a denim newsie This guy was not necessarily wise. It's rare to have completely isolated, fixed systems with no changes, including software. Having unsupported system and changing hardware is dead end. At some time you HAVE TO apply some servicve because you changed DASD, because you have to migrate from SSLv3 to TLS, because you have to switch from native SNA to Enterprise Extender, etc. etc. In IT world changes are consstant, so there are no "fixed state" of IT systems (with very few exceptions). So you have to apply *some* service. Usually it's much simpler when you apply preventive service and upgrade to new versions. Otherwise you have problems like how to migrate from unsupported OS on unsupported CPC to current OS/CPC. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
W dniu 2019-02-01 o 19:50, Tom Conley pisze: On 2/1/2019 12:22 PM, Jesse 1 Robinson wrote: I'd like to explore this teaser post. I was (I think also) dubious about the original comment in that it seems to disparage--or at least discourage--mass service like RSU, which I view as a major advance in software maintenance. Is there really wide-spread distrust of an "unavoidable 'push'"? . . A wise man once said, "If it ain't broke, don't fix it, but with z/OS, it's ALWAYS broke!" Older guy, beard, wore a denim newsie This guy was not necessarily wise. It's rare to have completely isolated, fixed systems with no changes, including software. Having unsupported system and changing hardware is dead end. At some time you HAVE TO apply some servicve because you changed DASD, because you have to migrate from SSLv3 to TLS, because you have to switch from native SNA to Enterprise Extender, etc. etc. In IT world changes are consstant, so there are no "fixed state" of IT systems (with very few exceptions). So you have to apply *some* service. Usually it's much simpler when you apply preventive service and upgrade to new versions. Otherwise you have problems like how to migrate from unsupported OS on unsupported CPC to current OS/CPC. My €0.02 -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
At first I thought maybe the referent was me. Wise? Debatable. Older? Remotely possible. But I searched my closet in vain for a 'denim newsie'. I guess that could signify my road apple hat. Anyway those who've heard me say 'always broke' know that I mean nothing derogatory. Quite the contrary. IBM gives us a window into 'problems' like few other vendors. Whether an open APAR or one whose fixing PTF is not yet installed, we have a pretty transparent view into the inevitable brokenness of the OS at any given time. That is to our everlasting benefit. OTOH we cannot rightfully claim the peaceful slumber of the clueless. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Friday, February 01, 2019 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Newbie SMP/E questions On 2/1/2019 12:22 PM, Jesse 1 Robinson wrote: > I'd like to explore this teaser post. I was (I think also) dubious about the > original comment in that it seems to disparage--or at least discourage--mass > service like RSU, which I view as a major advance in software maintenance. Is > there really wide-spread distrust of an "unavoidable 'push'"? > > . > . A wise man once said, "If it ain't broke, don't fix it, but with z/OS, it's ALWAYS broke!" Older guy, beard, wore a denim newsie Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
On 2/1/2019 12:22 PM, Jesse 1 Robinson wrote: I'd like to explore this teaser post. I was (I think also) dubious about the original comment in that it seems to disparage--or at least discourage--mass service like RSU, which I view as a major advance in software maintenance. Is there really wide-spread distrust of an "unavoidable 'push'"? . . A wise man once said, "If it ain't broke, don't fix it, but with z/OS, it's ALWAYS broke!" Older guy, beard, wore a denim newsie Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
I'd like to explore this teaser post. I was (I think also) dubious about the original comment in that it seems to disparage--or at least discourage--mass service like RSU, which I view as a major advance in software maintenance. Is there really wide-spread distrust of an "unavoidable 'push'"? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, January 30, 2019 5:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Newbie SMP/E questions On Wed, 30 Jan 2019 18:19:22 -0600, Robert Longabaugh wrote: > >.. That is one of the great things about getting individual fixes >instead of an unavoidable "push". ... > The less-than-great thing is that it cirvumvents Linus's Law, leading to regenerative service phobia, an instance of Tragedy of the Commons. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
Many, many thanks to all of you for your comments. I've made a long list of quotes pulled from your emails and plan to go over them with the sysprog in tomorrow's meeting. Then she goes away on vacation for a month, so I'll have lots of time to think, reread, ask more questions and peruse the documentation. You probably won't hear many more questions from me for a while, therefore, but I'm certain to be back eventually. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* A fanatic is someone who does what he knows God would do if God knew the facts of the case. -found at http://www.algonet.se/~parlei/quotes.html */ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
On Wed, 30 Jan 2019 18:19:22 -0600, Robert Longabaugh wrote: > >.. That is one of the great things about getting individual fixes instead of >an >unavoidable "push". ... > The less-than-great thing is that it cirvumvents Linus's Law, leading to regenerative service phobia, an instance of Tragedy of the Commons. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
If a PTF has a ++DELETE, it will contain ++HOLD(sysmod-id) ... REASON(DELETE) etc. You cannot restore those PTFs. The statement will look like ++DELETE(lmodname) That is not to be confused with PTFs that delete MOD, MAC, or Data Element entries. Those would look like ++PNLENU(ABC) DELETE SYSLIB(s) DISTLIB(d) . You can restore sysmods as long as they don't contain the ++DELETE MCS, but there are some considerations. 1. If you have newer PTFs that contain a PRE for the PTF that you are trying to restore, you will need to add those newer PTFs to your restore command, or even easier, just add GROUP to the RESTORE command. 2. If the sysmod that you are restoring has prereqs that you did not accept, then you will need to add those to the RESTORE command and re-apply them later. If you can accept the prereqs, then it will be a lot easier. Outside of that, it is up to you to set your policy of when you accept PTFs. The one policy to avoid is "NEVER", which makes it harder to back out fixes when you need to. Some of our CA products have releases that exist across multiple releases of CA, but need compatibility PTFs. Using a "never accept" policy on some of those products would allow you to restore back to levels that work with unsupported z/OS release. If you anticipate the need to run our product with z/OS 1.8, then that would be how you could do it. Bypassing error holds is up to you as the systems programmer. That is one of the great things about getting individual fixes instead of an unavoidable "push". For example, if we had a problem with our PDS Compression procedure, but you only use Backup and Restore, then it would be safe for you to bypass the error hold. You would be in control by analyzing the situation and making the decision, but I would definitely not advise a blanket BYPASS HOLDERROR technique. On Wed, Jan 30, 2019 at 5:34 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 30 Jan 2019 23:00:09 +, Jesse 1 Robinson < > jesse1.robin...@sce.com> wrote: > > >I'm also curious about 'not applying', but 'not restoring' is a long > standing characteristic. A PTF may contain a ++DELETE among its effects. > There's a special system hold category for this bad boy that tells you it > cannot be restored because a key element is gone. They're fairly rare, but > they do exist. > > > It doesn't have to be that way. RESTORE ought to be possible if all the > parts to > rebulid that key element remain in the GLOBAL zone and the parts list > remains in > the CSI. SMP/E simply is not designed to do it. VMSES/E does better > because it > is not hindered by depending on ACCEPT and DLIB contents. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
On Wed, 30 Jan 2019 23:00:09 +, Jesse 1 Robinson wrote: >I'm also curious about 'not applying', but 'not restoring' is a long standing >characteristic. A PTF may contain a ++DELETE among its effects. There's a >special system hold category for this bad boy that tells you it cannot be >restored because a key element is gone. They're fairly rare, but they do >exist. > It doesn't have to be that way. RESTORE ought to be possible if all the parts to rebulid that key element remain in the GLOBAL zone and the parts list remains in the CSI. SMP/E simply is not designed to do it. VMSES/E does better because it is not hindered by depending on ACCEPT and DLIB contents. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
I'm also curious about 'not applying', but 'not restoring' is a long standing characteristic. A PTF may contain a ++DELETE among its effects. There's a special system hold category for this bad boy that tells you it cannot be restored because a key element is gone. They're fairly rare, but they do exist. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Wednesday, January 30, 2019 1:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Newbie SMP/E questions Carmen, what do you mean by "not all PTFs will apply or restore"? If you mean that there's a PTF that cannot be applied, how then is it a PTF? And if you can APPLY it but not RESTORE...I'm incredulous. Can you expand on that? --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* 'Tis easier to suppress the first desire than to satisfy all that follow it. -Poor Richard */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Tuesday, January 29, 2019 11:26 you should concentrate on your current situation, research the use of APPLY/ RESTORE with group or groupextend, research why a PTF will not apply or restore, it may be a valid reason, not all PTF's will apply or restore. I suggest an SMP/E course sooner than later -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
On Wed, 30 Jan 2019 16:44:23 -0500, Bob Bridges wrote: >Carmen, what do you mean by "not all PTFs will apply or restore"? If you mean >that there's a PTF that cannot be applied, how then is it a PTF? And if you >can APPLY it but not RESTORE...I'm incredulous. Can you expand on that? > Documented. A PTF containing ++DELETE MCS can not be restored. Possibly other conditions. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
Carmen, what do you mean by "not all PTFs will apply or restore"? If you mean that there's a PTF that cannot be applied, how then is it a PTF? And if you can APPLY it but not RESTORE...I'm incredulous. Can you expand on that? --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* 'Tis easier to suppress the first desire than to satisfy all that follow it. -Poor Richard */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Tuesday, January 29, 2019 11:26 you should concentrate on your current situation, research the use of APPLY/ RESTORE with group or groupextend, research why a PTF will not apply or restore, it may be a valid reason, not all PTF's will apply or restore. I suggest an SMP/E course sooner than later -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
Replying to the original post because of this statement: "I think maybe we bypassed some HOLDs back then too." One the hardest lessons for an SMP/E newbie to grasp is when it's OK to bypass a HOLD condition and when it's not. First the nots. It's not (or virtually never) OK to bypass an error hold. If you bypass an error hold, you're telling SMP/E to apply PTF(s) that have been found to be and are declared in error. The nature of that error can vary widely. It may be that some additional action was not mentioned in a hold record. Or this PTF, if applied, may cause a new problem. In general, PTFs in error should (almost) never be applied unless you are very confident that the identified problem will not affect you, or Level 2 Support has advised you to forge ahead for the sake of fixing a more serious problem. These cases are rare, but they can occur. Most other hold conditions may--even should--be bypassed. See https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.gim2000/namsys.htm for an exhaustive inventory of 'system' ids. You should read these hold records, take action if appropriate, but not bother bypassing them. Be prepared for CC 8. Look in the Causer Report to make sure nothing unexpected has popped up, and move on. Regular maintenance is time-consuming enough without spinning wheels on the tedium of bypassing hold records just for the sake of CC 0. The outcome will be the same anyway. As someone else said, rather than try to restore an iffy PTF, you're generally better off with APPLY REDO. It's possible that a new hold condition has emerged since the original apply, but you need to deal with that anyway. As a friend of mine likes to say, software maintenance is an art, not a science. The longer you do it, the better your nose gets. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Tuesday, January 29, 2019 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Newbie SMP/E questions I'm the Top-Secret admin for a client whose system programmer retired a couple years ago. The client tapped another employee to take his place, and she's learning the job with frantic haste but insists with some justification that she's not a system programmer yet. Me, I came into security through the applications-development side so I'm not even close. Together she and I are trying to learn SMP/E. The immediate purpose is so we can apply some TSS-related PTFs, but really, it's become clear to me that we need no excuses to make it a priority; SMP/E is kind of important. I have embarked on a serious reading of the SMP/E User's Guide, but I still need help. I'll limit myself to a handful of questions to start with: Question #1) We started by applying a PTF - call it A for simplicity - and its prerequisite B. We did that last August and then the project languished for the sake of other priorities. Now we're working on it again and we want to restore those two PTFs and do the APPLY again. Why? Well, partly because it was 'way back in August and we're uncertain about exactly how we did it back then. We know more now. Partly because we know more now and we want to practice it better. I dunno, partly because we just want to. I think maybe we bypassed some HOLDs back then too. Anyway, we attempted the RESTORE, but we got lots and lots of error messages saying we need to include other PTFs in the RESTORE. Some of these have an indirect connection to A and B; B superceded at least three of them, for example, which I can see were applied some years ago. Others have no relation to our PTFs that I can discern. I haven't yet found the place in the User's Guide that explains these relationship and their relevance. Can someone give a helpful explanation? Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran this thing in the past never did any ACCEPT, ever, except for the original function code. I see at least 11 PTFs that were applied (including our two), but the distribution library shows no PTFs for any module I've yet LISTed. If true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE everything back to the plain-vanilla base? Question #3) My partner the not-sysprog has in mind that maybe we need to set aside this CSI (which is dedicated to Top Secret) and create another one starting with the base software and build up from there. I didn't realize this could be done, but she thinks she can do it. If it'll work, I like it; we'll know in that case what we have, which we do not at present. Anyone have any thoughts on this plan? Question #4) This is a less-important add-on: In both the online doc
Re: Newbie SMP/E questions
One task I perform as part of reporting - I run amblist against the run-time loadlib to see what fixes have made it to prod/test - although CA has a utility to interrogate libraries for its products to get a clean list of what fixes (or perhaps just the most recent) Have been applied to the runtime modules The utility is CAMODID Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services Humana Inc. 123 East Main Street Louisville, KY 40202 Humana.com (502) 476-2538 or 407-7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, January 30, 2019 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Newbie SMP/E questions Reject would occur after the restore. However, another semi-forgotten item has be paged into my virtual storage. The "2 PTFs" do not need to be restored. They can be re-implemented with APPLY REDO. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Tuesday, January 29, 2019 11:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Newbie SMP/E questions I think you can REJECT specific PTFs. On Tue, Jan 29, 2019 at 10:07 AM Bob Bridges wrote: > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. > > I have embarked on a serious reading of the SMP/E User's Guide, but I still > need help. I'll limit myself to a handful of questions to start with: > > Question #1) We started by applying a PTF - call it A for simplicity - and > its prerequisite B. We did that last August and then the project languished > for the sake of other priorities. Now we're working on it again and we want > to restore those two PTFs and do the APPLY again. Why? Well, partly because > it was 'way back in August and we're uncertain about exactly how we did it > back then. We know more now. Partly because we know more now and we want to > practice it better. I dunno, partly because we just want to. I think maybe > we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an > indirect connection to A and B; B superceded at least three of them, for > example, which I can see were applied some years ago. Others have no > relation to our PTFs that I can discern. I haven't yet found the place in > the User's Guide that explains these relationship and their relevance. Can > someone give a helpful explanation? > > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. I see at least 11 PTFs that were applied (including our two), > but the distribution library shows no PTFs for any module I've yet LISTed. > If true, does that mean that to do a RESTORE of our two PTFs we'll have to > RESTORE everything back to the plain-vanilla base? > > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever other > PTFs are required for various reasons. It doesn't seem to, though; it names > them and complains about them, but doesn't add them to the list. Have I > misunderstood something? I'm loathe to believe the documentation is flat > wrong. > > If you're getting ready to send rushed messages saying "DON'T DO ANYTHING > UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > > --- > Bob Bridges, cell 336 382-7313 > robhbrid...@gmail.com > rbrid...@infosecinc.com > > /* Anyone can do any amount of work, provided it isn't the work he is > supposed
Re: Newbie SMP/E questions
Reject would occur after the restore. However, another semi-forgotten item has be paged into my virtual storage. The "2 PTFs" do not need to be restored. They can be re-implemented with APPLY REDO. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Tuesday, January 29, 2019 11:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Newbie SMP/E questions I think you can REJECT specific PTFs. On Tue, Jan 29, 2019 at 10:07 AM Bob Bridges wrote: > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. > > I have embarked on a serious reading of the SMP/E User's Guide, but I still > need help. I'll limit myself to a handful of questions to start with: > > Question #1) We started by applying a PTF - call it A for simplicity - and > its prerequisite B. We did that last August and then the project languished > for the sake of other priorities. Now we're working on it again and we want > to restore those two PTFs and do the APPLY again. Why? Well, partly because > it was 'way back in August and we're uncertain about exactly how we did it > back then. We know more now. Partly because we know more now and we want to > practice it better. I dunno, partly because we just want to. I think maybe > we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an > indirect connection to A and B; B superceded at least three of them, for > example, which I can see were applied some years ago. Others have no > relation to our PTFs that I can discern. I haven't yet found the place in > the User's Guide that explains these relationship and their relevance. Can > someone give a helpful explanation? > > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. I see at least 11 PTFs that were applied (including our two), > but the distribution library shows no PTFs for any module I've yet LISTed. > If true, does that mean that to do a RESTORE of our two PTFs we'll have to > RESTORE everything back to the plain-vanilla base? > > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever other > PTFs are required for various reasons. It doesn't seem to, though; it names > them and complains about them, but doesn't add them to the list. Have I > misunderstood something? I'm loathe to believe the documentation is flat > wrong. > > If you're getting ready to send rushed messages saying "DON'T DO ANYTHING > UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > > --- > Bob Bridges, cell 336 382-7313 > robhbrid...@gmail.com > rbrid...@infosecinc.com > > /* Anyone can do any amount of work, provided it isn't the work he is > supposed be doing at that moment. -Robert Benchley */ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER::
Re: Newbie SMP/E questions
I think you can REJECT specific PTFs. REJECT takes a PTF out of the GLOBAL zone. If it's already applied, you won't undo the PTF APPLY. RESTORE ing the PTF just so you can have another go at it is not a good idea. As people have said, RESTORE rolls back to the last ACCEPTed status but you have to RESTORE all PTFS in the chain. A fairly difficult and pointless exercise in this case. APPLY REDO is the easiiest route to take but what if the PTF was a ++VER REP? It's not going to work. Then you get into another mess. I remember when CA would issue PTFS that were all VER/ZAP fixes and then when they were bad, I wrote USERMODS to undo them because it was insanity to ACCEPT anything. One day when I was on leave a SYSPROG did an accept. Most of us have been burned and take the ADRDDSU dump everything SMPE and RESTORE if it goes pear shaped. MSHP on VSE has a much better approach to backing out PTFS. Wonder why SMPE couldn't have been the same. On Wed, Jan 30, 2019 at 4:56 PM Mike Schwab wrote: > I think you can REJECT specific PTFs. > > On Tue, Jan 29, 2019 at 10:07 AM Bob Bridges > wrote: > > > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, > and she's learning the job with frantic haste but insists with some > justification that she's not a system programmer yet. Me, I came into > security through the applications-development side so I'm not even close. > > > > Together she and I are trying to learn SMP/E. The immediate purpose is > so we can apply some TSS-related PTFs, but really, it's become clear to me > that we need no excuses to make it a priority; SMP/E is kind of important. > > > > I have embarked on a serious reading of the SMP/E User's Guide, but I > still need help. I'll limit myself to a handful of questions to start with: > > > > Question #1) We started by applying a PTF - call it A for simplicity - > and its prerequisite B. We did that last August and then the project > languished for the sake of other priorities. Now we're working on it again > and we want to restore those two PTFs and do the APPLY again. Why? Well, > partly because it was 'way back in August and we're uncertain about exactly > how we did it back then. We know more now. Partly because we know more > now and we want to practice it better. I dunno, partly because we just > want to. I think maybe we bypassed some HOLDs back then too. > > > > Anyway, we attempted the RESTORE, but we got lots and lots of error > messages saying we need to include other PTFs in the RESTORE. Some of > these have an indirect connection to A and B; B superceded at least three > of them, for example, which I can see were applied some years ago. Others > have no relation to our PTFs that I can discern. I haven't yet found the > place in the User's Guide that explains these relationship and their > relevance. Can someone give a helpful explanation? > > > > Question #2) So far as we can tell by issuing LIST XREF commands, > whoever ran this thing in the past never did any ACCEPT, ever, except for > the original function code. I see at least 11 PTFs that were applied > (including our two), but the distribution library shows no PTFs for any > module I've yet LISTed. If true, does that mean that to do a RESTORE of > our two PTFs we'll have to RESTORE everything back to the plain-vanilla > base? > > > > Question #3) My partner the not-sysprog has in mind that maybe we need > to set aside this CSI (which is dedicated to Top Secret) and create another > one starting with the base software and build up from there. I didn't > realize this could be done, but she thinks she can do it. If it'll work, I > like it; we'll know in that case what we have, which we do not at present. > Anyone have any thoughts on this plan? > > > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever > other PTFs are required for various reasons. It doesn't seem to, though; > it names them and complains about them, but doesn't add them to the list. > Have I misunderstood something? I'm loathe to believe the documentation is > flat wrong. > > > > If you're getting ready to send rushed messages saying "DON'T DO > ANYTHING UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > > > > --- > > Bob Bridges, cell 336 382-7313 > > robhbrid...@gmail.com > > rbrid...@infosecinc.com > > > > /* Anyone can do any amount of work, provided it isn't the work he is > supposed be doing at that moment. -Robert Benchley */ > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest
Re: Newbie SMP/E questions
I think you can REJECT specific PTFs. On Tue, Jan 29, 2019 at 10:07 AM Bob Bridges wrote: > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. > > I have embarked on a serious reading of the SMP/E User's Guide, but I still > need help. I'll limit myself to a handful of questions to start with: > > Question #1) We started by applying a PTF - call it A for simplicity - and > its prerequisite B. We did that last August and then the project languished > for the sake of other priorities. Now we're working on it again and we want > to restore those two PTFs and do the APPLY again. Why? Well, partly because > it was 'way back in August and we're uncertain about exactly how we did it > back then. We know more now. Partly because we know more now and we want to > practice it better. I dunno, partly because we just want to. I think maybe > we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an > indirect connection to A and B; B superceded at least three of them, for > example, which I can see were applied some years ago. Others have no > relation to our PTFs that I can discern. I haven't yet found the place in > the User's Guide that explains these relationship and their relevance. Can > someone give a helpful explanation? > > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. I see at least 11 PTFs that were applied (including our two), > but the distribution library shows no PTFs for any module I've yet LISTed. > If true, does that mean that to do a RESTORE of our two PTFs we'll have to > RESTORE everything back to the plain-vanilla base? > > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever other > PTFs are required for various reasons. It doesn't seem to, though; it names > them and complains about them, but doesn't add them to the list. Have I > misunderstood something? I'm loathe to believe the documentation is flat > wrong. > > If you're getting ready to send rushed messages saying "DON'T DO ANYTHING > UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > > --- > Bob Bridges, cell 336 382-7313 > robhbrid...@gmail.com > rbrid...@infosecinc.com > > /* Anyone can do any amount of work, provided it isn't the work he is > supposed be doing at that moment. -Robert Benchley */ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
On Tue, 29 Jan 2019 at 11:07, Bob Bridges wrote: > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. Lots of good info already. I have just a comment or two, more in passing than specifically answering your questions. > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. Your use of LIST XREF is Very Good. As an ISV we are forever asking customers to send us the result of SMP/E LIST . commands, and half the time we get the output from LIST SYSMODS or LIST PTFS or the like, which doesn't tell us everything. You can always ask SMP/E something specific, or you can say "tell me everything you know", and save that large chunk of output and then search it with ISPF or on your desktop or wherever you like to do that kind of thing. If you want to document the situation at a given time, I highly recommend storing the result from a LIST ALLZONES XREF. Then you can do simple find commands on PTF IDs or module names or even things like the comments in PTFs that you no longer can find the source for. The earlier suggestion to use the z/OS UNIX interface is an alternative if you are comfortable with UNIXy line commands. You could probably send its output to your favorite tool(s) which could even be a desktop spreadsheet. > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? If you are in any doubt as to what you have, then it's a good idea. It may be obvious, but let me say it: the SMP/E CSI is a bit like the catalog on z/OS. It has all kinds of information about what's where, and so on, but the actual datasets as defined by the DDDEF entries are definitive as to what the data *is*. If you update one or the other independently, then you are likely to be in big trouble, just as you would be if you restored a catalog from a backup independent of the datasets it points to, or the other way around. So treat the CSI and the datasets it points to as a unit when it comes to backup/restore operations. It's not impossible to manage the pieces independently, but it's usually a bad idea. Also, it is certainly possible for someone to have updated a target or DLIB dataset known to SMP/E outside SMP/E using the Binder or IEBCOPY etc, and then you have no reliable way of knowing what your state of affairs is. This is perhaps unlikely if your predecessor was a wise and experienced person, but it happens. Someone needs to bang on a quick fix or apply a ZAP in a rush, and then the "paperwork" (CSI) doesn't get updated to match. Simple, standalone products maintained by SMP/E are, well - simple and standalone. Typically the target zone's LOAD dataset is used as the production STEPLIB'd load library. Or a promote to production or staging through test layers scheme that is outside of SMP/E is used to make an exact copy of that module data to one or more production datasets. But something like TSS, and certainly some of the z/OS components, have specific requirements as to where the modules live, such as LPALIB or Linklist datasets. The promotion process in this case can be more complex, and with any system-level product you run the risk of breaking the system if you get it wrong. SMP/E will do its best (for example, recovering from an out of space condition while building a load module), but it can't fix what it doesn't know about. Any such product will come with detailed instructions for initial installation and ongoing maintenance, which you need to follow carefully. Again, this may be obvious, but if you are both new to sysprogging, I think it can't hurt to sayit. Best of luck in learning about and using what you have inherited! Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
> The other option is to see if the ISPF environment has the ISPF SMP/E panels > available. If you are coming from a Unix background, are comfortable with the USS command line and scripting, and have the xlc compiler available (a lot of "ifs"...), you might want to try this: https://github.com/zorts/smpapi It's a little C program that uses the SMP query API to dig information out of the SMPCSI. I personally find it easier to use than the ISPF panels. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
Just a few thoughts from my vast (well, half-vast) SMP/E experience Always receive HOLDDATA before doing anything - it may alert you to previously received fixes that are now marked PE (PROGRAM IN ERROR) Holddata can also inform you of previously-PE ptf that are now resolved The REPORT ERRSYSMODS COMMAQND IS YOUR FRIEND Accept the base (fmid) - never ACCEPT a ptf until/unless you are damned sure you will never need to remove it (that could mean NEVER ) After EVERY smp/e modification, backup (dfdss/favr/whatever) your entire smp/e environment - and keep many many generations - you can use these to do an end run around the need to RESTORE How far back do you need to go in a restore - until you are clean or pre-and co-requisite PTFs (could be many iterations) If all else fails, start over with a new CSI Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services Humana Inc. 123 East Main Street Louisville, KY 40202 Humana.com (502) 476-2538 or 407-7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Tuesday, January 29, 2019 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Newbie SMP/E questions Never heard of CA-MSM, but I'll look into it. (I've been in contact with Bob Boerum at CA, but he's never mentioned it.) We've been using the SMP/E panels, and, as you say, letting them construct the JCL. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* In its state of nature [a dog] has a smell, and habits, which frustrate man's love; he washes it, house-trains it, teaches it not to steal, and is so enabled to love it completely. To the puppy, the whole proceeding would seem, if it were a theologian, to cast grave doubts on the "goodness" of man; but the full-grown and full-trained dog, larger, healthier and longer-lived than the wild dog, and admitted, as it were by Grace, to a whole world of affections, loyalties, interests and comforts entirely beyond its animal destiny, would have no such doubt. -C S Lewis, _The Problem of Pain_ */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, January 29, 2019 11:17 The other option is to see if the ISPF environment has the ISPF SMP/E panels available. That also can help reduce the stress of using SMP/E. REC/APP/REST/REJ/ACC are pretty easy to do. Try not to get lost in the details. The panels will wrap JCL around what you are going to do. I save that off to a dataset and then I have a sample of how to do each. > -Original Message- > From: > Lizette Koehler > Sent: Tuesday, January 29, 2019 9:15 AM > > For supporting any CA Product, you should be using if possible, CA MSM. > This is a gui interface that makes CA SMP/E maintenance easier. It > pulls the fixes, and you just select what you want it does the rest. > Do you have CAMSM available to you? > > > -Original Message- > > From: Bob Bridges > > Sent: Tuesday, January 29, 2019 9:07 AM > > > > I'm the Top-Secret admin for a client whose system programmer > > retired a couple years ago. The client tapped another employee to > > take his place, and she's learning the job with frantic haste but > > insists with some justification that she's not a system programmer > > yet. Me, I came into security through the applications-development > > side so I'm not even close. > > > > Together she and I are trying to learn SMP/E. The immediate purpose > > is so we can apply some TSS-related PTFs, but really, it's become > > clear to me that we need no excuses to make it a priority; SMP/E is > > kind of important. > > > > I have embarked on a serious reading of the SMP/E User's Guide, but > > I still need help. I'll limit myself to a handful of questions to > > start > > with: > > > > Question #1) We started by applying a PTF - call it A for simplicity > > - and its prerequisite B. We did that last August and then the > > project languished for the sake of other priorities. Now we're > > working on it again and we want to restore those two PTFs and do the APPLY > > again. > > Why? Well, partly because it was 'way back in August and we're > > uncertain about exactly how we did it back then. We know more now. > > Partly because we know more now and we want to practice it better. > > I dunno, partly because we just want to. I think maybe we bypassed > > some HOLDs back then too. > > > > Anyway, we attempted the RESTORE, but we got lots and lots of error > > messages saying we need to include other PTFs in the RESTORE. Some > > of these have an indirect conn
Re: Newbie SMP/E questions
If PTF A has PTF B as a prerequisite, and both have been applied, but neither has been accepted, then in order to restore A, you must also restore B. GROUP will not help you here. IIRC, if you restore B and specify GROUP, SMP/E will restore both A and B, but I'm not at all sure about this. SMPLOG is your friend for determining what has been done and how. Each zone should have a DDDEF for its own SMPLOG with DISP=MOD. The content is essentially everything from the SMPOUT output for each run with a date and time in the first few bytes of each record in packed decimal format. You can list the SMPLOG for a range of dates/times, but I usually just use VIEW to look at it, with the occasional HX line command to see the date and time. If you install Top Secret from scratch, you will have an isolated environment to play with and you can do so without worrying, as long as you define all new data sets, including for the global zone, with different names. You can even use your userid as the high level qualifier for everything. I do this frequently to test SMP/E environments. Having created this environment, you can experiment and will find it very instructive. You can also clone your target and distribution zones. That would involve using ZONECOPY to copy the zones, copy all of the target and distribution data sets, keeping the low level qualifiers, and changing all the DDDEFs ZONEEDIT can help with this. I would actually suggest that you do both of these things. Install Top Secret (or any other product) in an isolated environment, then clone the target and distribution zone within that environment. IIRC, CA-MSM is now called Opera. I disagree with Lizette, though. I do not recommend that you use it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
BB5> My best friend and I developed a protocol when our long, long debates started going electronic back in the '80s. (He abandoned his Catholic upbringing just about the time I was baptized in the Holy Spirit, so we've been merrily arguing over it ever since.) The initials and numbers are slightly more work but For multiple contributors and especially for multiple iterations they add a great deal to clarity; see below. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* Law #31 of combat operations: If the enemy is within range, so are you. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, January 29, 2019 12:09 AS4> They were indented when I sent it. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, January 29, 2019 11:06 AM --- On 2019-01-29, at 09:52:18, Allan Staller wrote: AS2> Comments interspersed. PG3> Thanks. It would further be useful if you distinguished quoted material with the customary ">" prefix. > -Original Message- > From: Bob Bridges > Sent: Tuesday, January 29, 2019 10:07 AM BB1> I'm the Top-Secret admin for a client whose system programmer retired a couple years ago. The client tapped another employee to take his place, and she's learning the job with frantic haste but insists with some justification that she's not a system programmer yet. Me, I came into security through the applications-development side so I'm not even close. Together she and I are trying to learn SMP/E. The immediate purpose is so we can apply some TSS-related PTFs, but really, it's become clear to me that we need no excuses to make it a priority; SMP/E is kind of important. I have embarked on a serious reading of the SMP/E User's Guide, but I still need help. I'll limit myself to a handful of questions to start with: Question #1) We started by applying a PTF - call it A for simplicity - and its prerequisite B. We did that last August and then the project languished for the sake of other priorities. Now we're working on it again and we want to restore those two PTFs and do the APPLY again. Why? Well, partly because it was 'way back in August and we're uncertain about exactly how we did it back then. We know more now. Partly because we know more now and we want to practice it better. I dunno, partly because we just want to. I think maybe we bypassed some HOLDs back then too. Anyway, we attempted the RESTORE, but we got lots and lots of error messages saying we need to include other PTFs in the RESTORE. Some of these have an indirect connection to A and B; B superceded at least three of them, for example, which I can see were applied some years ago. Others have no relation to our PTFs that I can discern. I haven't yet found the place in the User's Guide that explains these relationship and their relevance. Can someone give a helpful explanation? AS2> SMPE has 2 basic zones TARGET and DLIB (everything else just supports these 2 zones.). APPLY/ACCEPT processing installs maintenance into the TARGET/DLIB zones respectively. Once accepted, the only fallback is dfDSS restore (if you have backups). Restore processing returns the environment to the last ACCEPTed level. In order to complete this process, all maintenance from the accepted level to the current code level must be restored. BB1> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran this thing in the past never did any ACCEPT, ever, except for the original function code. I see at least 11 PTFs that were applied (including our two), but the distribution library shows no PTFs for any module I've yet LISTed. If true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE everything back to the plain-vanilla base? > It is a common practice not to accept maintenance for 3rd party products. I will not say it is good or bad, but it is common. In to restore to the environment "before the 2 PTFs", all non-accept PTFs must be restored and then re-applied (minus the two PTFS). AS2> This will accomplish what is desired in #1 above. BB1> Question #3) My partner the not-sysprog has in mind that maybe we need to set aside this CSI (which is dedicated to Top Secret) and create another one starting with the base software and build up from there. I didn't realize this could be done, but she thinks she can do it. If it'll work, I like it; we'll know in that case what we have, which we do not at present. Anyone have any thoughts on this plan? AS2> A re-install of the product into separate zones is certainly practical. IMO, less work, but also less of a learning experience BB1> Question #4) This is a less-important add-on: In both the online documentation and the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, including the GROUP operand causes SMP/E to add whatever other PTFs are required
Re: Style (was: Newbie SMP/E questions)
On 2019-01-29, at 10:09:25, Allan Staller wrote: > They were indented when I sent it. > Thanks. I blame much misbehavior on hypermodern mailer software (You appear to be using MS-Exchange) that aggressively reformats to optimize for handheld devices where character cells are precious. Too much misguided DWIM. > -Original Message- > From: Paul Gilmartin > Sent: Tuesday, January 29, 2019 11:06 AM > > On 2019-01-29, at 09:52:18, Allan Staller wrote: > >> Comments interspersed. >> >> HTH, >> > Thanks. It would further be useful if you distinguished quoted material with > the customary ">" prefix. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
> -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bob Bridges > Sent: Tuesday, January 29, 2019 8:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Newbie SMP/E questions > > Question #1) We started by applying a PTF - call it A for simplicity - and its > prerequisite B. We did that last August and then the project languished for > the sake of > other priorities. Now we're working on it again and we want to restore those > two PTFs > and do the APPLY again. Why? Well, partly because it was 'way back in > August and > we're uncertain about exactly how we did it back then. We know more now. > Partly My solution to this problem is to save the complete listing (everything SDSF would give me) of every SMPE run in a PDS and with a member name that reflects the chronology. For example: $0001R and $0002R for the receives, $0003P for the apply check, $0004P for the apply and $0005C for the accept check, etc. Many jobs had to be run more than once and they are all there for later review. > because we know more now and we want to practice it better. I dunno, partly > because > we just want to. I think maybe we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an This is caused by the lack of accepts you describe below. One solution might be to accept the ones that were applied years ago since you are not likely to restore any of them. > indirect connection to A and B; B superceded at least three of them, for > example, > which I can see were applied some years ago. Others have no relation to our > PTFs that > I can discern. I haven't yet found the place in the User's Guide that > explains these > relationship and their relevance. Can someone give a helpful explanation? The LIST SYSMODS command is your friend. > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this > thing in the past never did any ACCEPT, ever, except for the original > function code. I > see at least 11 PTFs that were applied (including our two), but the > distribution library > shows no PTFs for any module I've yet LISTed. If true, does that mean that > to do a > RESTORE of our two PTFs we'll have to RESTORE everything back to the plain- > vanilla base? The basic function of the restore command is to replace "updated" but not accepted data in your target libraries with the "original" data in the distribution library. Since the related PTFs don't exist in the DLIB, there are only two choices. Put them there by accepting them as described above or include them in the restore. If you choose the latter, you don't need to manually include them. You can use the GROUP operand to have SMPE do it for you. My preference while learning SMPE is to use the CHECK operand on every command before firing for effect. > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside > this CSI (which is dedicated to Top Secret) and create another one starting > with the > base software and build up from there. I didn't realize this could be done, > but she > thinks she can do it. If it'll work, I like it; we'll know in that case what > we have, which > we do not at present. Anyone have any thoughts on this plan? If you do this, make sure you specify different target and distribution libraries. You don't want your testing to step on production. On the other hand, LIST is still your friend. > Question #4) This is a less-important add-on: In both the online > documentation and > the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, > including > the GROUP operand causes SMP/E to add whatever other PTFs are required for > various > reasons. It doesn't seem to, though; it names them and complains about them, > but > doesn't add them to the list. Have I misunderstood something? I'm loathe to > believe > the documentation is flat wrong. Use the CHECK operand to test. Look at the third and fourth paragraphs in the description of the GROUP operand in the SMPE Commands manual If you still have questions, show us the exact command you issue and a sample of the error messages. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Style (was: Newbie SMP/E questions)
They were indented when I sent it. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, January 29, 2019 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Style (was: Newbie SMP/E questions) On 2019-01-29, at 09:52:18, Allan Staller wrote: > Comments interspersed. > > HTH, > Thanks. It would further be useful if you distinguished quoted material with the customary ">" prefix. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bob Bridges > Sent: Tuesday, January 29, 2019 10:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Newbie SMP/E questions > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. > > I have embarked on a serious reading of the SMP/E User's Guide, but I still > need help. I'll limit myself to a handful of questions to start with: > > Question #1) We started by applying a PTF - call it A for simplicity - and > its prerequisite B. We did that last August and then the project languished > for the sake of other priorities. Now we're working on it again and we want > to restore those two PTFs and do the APPLY again. Why? Well, partly because > it was 'way back in August and we're uncertain about exactly how we did it > back then. We know more now. Partly because we know more now and we want to > practice it better. I dunno, partly because we just want to. I think maybe > we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an > indirect connection to A and B; B superceded at least three of them, for > example, which I can see were applied some years ago. Others have no > relation to our PTFs that I can discern. I haven't yet found the place in > the User's Guide that explains these relationship and their relevance. Can > someone give a helpful explanation? > SMPE has 2 basic zones TARGET and DLIB (everything else just supports these 2 > zones.). APPLY/ACCEPT processing installs maintenance into the TARGET/DLIB > zones respectively. Once accepted, the only fallback is dfDSS restore (if you > have backups). > Restore processing returns the environment to the last ACCEPTed level. In > order to complete this process, all maintenance from the accepted level to > the current code level must be restored. > > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. I see at least 11 PTFs that were applied (including our two), > but the distribution library shows no PTFs for any module I've yet LISTed. > If true, does that mean that to do a RESTORE of our two PTFs we'll have to > RESTORE everything back to the plain-vanilla base? > It is a common practice not to accept maintenance for 3rd party products. I > will not say it is good or bad, but it is common. In to restore to the > environment "before the 2 PTFs", all non-accept PTFs must be restored and > then re-applied (minus the two PTFS). > This will accomplish what is desired in #1 above. > > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? > A re-install of the product into separate zones is certainly > practical. IMO, less work, but also less of a learning experience > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever other > PTFs are required for various reasons. It doesn't seem to, though; it names > them and complains about them, but doesn't add them to the list. Have I > misunderstood something? I'm loathe to believe the documentation is
Style (was: Newbie SMP/E questions)
On 2019-01-29, at 09:52:18, Allan Staller wrote: > Comments interspersed. > > HTH, > Thanks. It would further be useful if you distinguished quoted material with the customary ">" prefix. > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Bob Bridges > Sent: Tuesday, January 29, 2019 10:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Newbie SMP/E questions > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. > > I have embarked on a serious reading of the SMP/E User's Guide, but I still > need help. I'll limit myself to a handful of questions to start with: > > Question #1) We started by applying a PTF - call it A for simplicity - and > its prerequisite B. We did that last August and then the project languished > for the sake of other priorities. Now we're working on it again and we want > to restore those two PTFs and do the APPLY again. Why? Well, partly because > it was 'way back in August and we're uncertain about exactly how we did it > back then. We know more now. Partly because we know more now and we want to > practice it better. I dunno, partly because we just want to. I think maybe > we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an > indirect connection to A and B; B superceded at least three of them, for > example, which I can see were applied some years ago. Others have no > relation to our PTFs that I can discern. I haven't yet found the place in > the User's Guide that explains these relationship and their relevance. Can > someone give a helpful explanation? > SMPE has 2 basic zones TARGET and DLIB (everything else just supports these 2 > zones.). APPLY/ACCEPT processing installs maintenance into the TARGET/DLIB > zones respectively. Once accepted, the only fallback is dfDSS restore (if you > have backups). > Restore processing returns the environment to the last ACCEPTed level. In > order to complete this process, all maintenance from the accepted level to > the current code level must be restored. > > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. I see at least 11 PTFs that were applied (including our two), > but the distribution library shows no PTFs for any module I've yet LISTed. > If true, does that mean that to do a RESTORE of our two PTFs we'll have to > RESTORE everything back to the plain-vanilla base? > It is a common practice not to accept maintenance for 3rd party products. I > will not say it is good or bad, but it is common. In to restore to the > environment "before the 2 PTFs", all non-accept PTFs must be restored and > then re-applied (minus the two PTFS). > This will accomplish what is desired in #1 above. > > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? > A re-install of the product into separate zones is certainly practical. IMO, > less work, but also less of a learning experience > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever other > PTFs are required for various reasons. It doesn't seem to, though; it names > them and complains about them, but doesn't add them to the list. Have I > misunderstood something? I'm loathe to believe the documentation is flat > wrong. > RESTORE S(A,B) GROUPEXTEND will sometimes miss some items. Include them > manually. E.g . RESTORE S(A,B,C) GROUPEXTEND will sometimes miss some items. > > If you're getting ready to send rushe
Re: Newbie SMP/E questions
Well, the messages from the RESTORE indicate that SMP/E thinks that they are applied. If you want to re-APPLY them, merely add the keyword REDO to the APPLY statement. But you also need to know the procedures that were followed at your shop. It is very rare that APPLY goes to a live system. It usually goes to the "next" sysres which will be clip'ed over when ready. Many shops have a standard of never accepting PTFs. If you start a new CSI, you will also need new target libraries etc. Not for the beginner (IMHO). There is no reason to RESTORE these PTFs just to reapply them. You may have a procedure to emergency apply PTFs (without the new SYSRES process) but you need to know what you are doing. Is your shop dropping the mainframe? If not, how to they plan on going forwards without a sysprog? On Tue, 29 Jan 2019 11:06:51 -0500 Bob Bridges wrote: :>I'm the Top-Secret admin for a client whose system programmer retired a couple years ago. The client tapped another employee to take his place, and she's learning the job with frantic haste but insists with some justification that she's not a system programmer yet. Me, I came into security through the applications-development side so I'm not even close. :> :>Together she and I are trying to learn SMP/E. The immediate purpose is so we can apply some TSS-related PTFs, but really, it's become clear to me that we need no excuses to make it a priority; SMP/E is kind of important. :> :>I have embarked on a serious reading of the SMP/E User's Guide, but I still need help. I'll limit myself to a handful of questions to start with: :> :>Question #1) We started by applying a PTF - call it A for simplicity - and its prerequisite B. We did that last August and then the project languished for the sake of other priorities. Now we're working on it again and we want to restore those two PTFs and do the APPLY again. Why? Well, partly because it was 'way back in August and we're uncertain about exactly how we did it back then. We know more now. Partly because we know more now and we want to practice it better. I dunno, partly because we just want to. I think maybe we bypassed some HOLDs back then too. :> :>Anyway, we attempted the RESTORE, but we got lots and lots of error messages saying we need to include other PTFs in the RESTORE. Some of these have an indirect connection to A and B; B superceded at least three of them, for example, which I can see were applied some years ago. Others have no relation to our PTFs that I can discern. I haven't yet found the place in the User's Guide that explains these relationship and their relevance. Can someone give a helpful explanation? :> :>Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran this thing in the past never did any ACCEPT, ever, except for the original function code. I see at least 11 PTFs that were applied (including our two), but the distribution library shows no PTFs for any module I've yet LISTed. If true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE everything back to the plain-vanilla base? :> :>Question #3) My partner the not-sysprog has in mind that maybe we need to set aside this CSI (which is dedicated to Top Secret) and create another one starting with the base software and build up from there. I didn't realize this could be done, but she thinks she can do it. If it'll work, I like it; we'll know in that case what we have, which we do not at present. Anyone have any thoughts on this plan? :> :>Question #4) This is a less-important add-on: In both the online documentation and the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, including the GROUP operand causes SMP/E to add whatever other PTFs are required for various reasons. It doesn't seem to, though; it names them and complains about them, but doesn't add them to the list. Have I misunderstood something? I'm loathe to believe the documentation is flat wrong. :> :>If you're getting ready to send rushed messages saying "DON'T DO ANYTHING UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. :> :>--- :>Bob Bridges, cell 336 382-7313 :> robhbrid...@gmail.com :> rbrid...@infosecinc.com :> :>/* Anyone can do any amount of work, provided it isn't the work he is supposed be doing at that moment. -Robert Benchley */ :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: Newbie SMP/E questions
On Tue, 29 Jan 2019 11:46:39 -0500, Bob Bridges wrote: >Never heard of CA-MSM, but I'll look into it. (I've been in contact with Bob >Boerum at CA, but he's never mentioned it.) > >We've been using the SMP/E panels, and, as you say, letting them construct the >JCL. > Yes. And I always save the constructed JCL so I can tweak it rather than starting afresh. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
And on top of that, backup, ACCEPT, backup, RECEIVE, backup, APPLY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rugen, Len Sent: Tuesday, January 29, 2019 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Newbie SMP/E questions [External Email] Some of us developed a maintenance cycle of ACCEPT, RECEIVE, APPLY. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
Comments interspersed. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Tuesday, January 29, 2019 10:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Newbie SMP/E questions I'm the Top-Secret admin for a client whose system programmer retired a couple years ago. The client tapped another employee to take his place, and she's learning the job with frantic haste but insists with some justification that she's not a system programmer yet. Me, I came into security through the applications-development side so I'm not even close. Together she and I are trying to learn SMP/E. The immediate purpose is so we can apply some TSS-related PTFs, but really, it's become clear to me that we need no excuses to make it a priority; SMP/E is kind of important. I have embarked on a serious reading of the SMP/E User's Guide, but I still need help. I'll limit myself to a handful of questions to start with: Question #1) We started by applying a PTF - call it A for simplicity - and its prerequisite B. We did that last August and then the project languished for the sake of other priorities. Now we're working on it again and we want to restore those two PTFs and do the APPLY again. Why? Well, partly because it was 'way back in August and we're uncertain about exactly how we did it back then. We know more now. Partly because we know more now and we want to practice it better. I dunno, partly because we just want to. I think maybe we bypassed some HOLDs back then too. Anyway, we attempted the RESTORE, but we got lots and lots of error messages saying we need to include other PTFs in the RESTORE. Some of these have an indirect connection to A and B; B superceded at least three of them, for example, which I can see were applied some years ago. Others have no relation to our PTFs that I can discern. I haven't yet found the place in the User's Guide that explains these relationship and their relevance. Can someone give a helpful explanation? SMPE has 2 basic zones TARGET and DLIB (everything else just supports these 2 zones.). APPLY/ACCEPT processing installs maintenance into the TARGET/DLIB zones respectively. Once accepted, the only fallback is dfDSS restore (if you have backups). Restore processing returns the environment to the last ACCEPTed level. In order to complete this process, all maintenance from the accepted level to the current code level must be restored. Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran this thing in the past never did any ACCEPT, ever, except for the original function code. I see at least 11 PTFs that were applied (including our two), but the distribution library shows no PTFs for any module I've yet LISTed. If true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE everything back to the plain-vanilla base? It is a common practice not to accept maintenance for 3rd party products. I will not say it is good or bad, but it is common. In to restore to the environment "before the 2 PTFs", all non-accept PTFs must be restored and then re-applied (minus the two PTFS). This will accomplish what is desired in #1 above. Question #3) My partner the not-sysprog has in mind that maybe we need to set aside this CSI (which is dedicated to Top Secret) and create another one starting with the base software and build up from there. I didn't realize this could be done, but she thinks she can do it. If it'll work, I like it; we'll know in that case what we have, which we do not at present. Anyone have any thoughts on this plan? A re-install of the product into separate zones is certainly practical. IMO, less work, but also less of a learning experience Question #4) This is a less-important add-on: In both the online documentation and the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, including the GROUP operand causes SMP/E to add whatever other PTFs are required for various reasons. It doesn't seem to, though; it names them and complains about them, but doesn't add them to the list. Have I misunderstood something? I'm loathe to believe the documentation is flat wrong. RESTORE S(A,B) GROUPEXTEND will sometimes miss some items. Include them manually. E.g . RESTORE S(A,B,C) GROUPEXTEND will sometimes miss some items. If you're getting ready to send rushed messages saying "DON'T DO ANYTHING UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* Anyone can do any amount of work, provided it isn't the work he is supposed be doing at that moment. -Robert Benchley */ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO I
Style (was: Newbie SMP/E questions)
On Tue, 29 Jan 2019 16:23:06 +, David Spiegel wrote: >Hi Bob, >2) Yes for the current situation. If, however, PTFs between base and >your new PTFs are ACCEPTd, no. >> ... [about 20 lines skipped] >> Question #2) ... What ever became of the venerable practice of interleaving replies close to the paragraphs to which they refer so the reader doesn't need to hop up and down in the page? Top-posting is execrable. It's harder for both the poster and the reader. (Of course it helps if the depth of quoted text is clearly identified -- that was not a problem in this thread.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
Some of us developed a maintenance cycle of ACCEPT, RECEIVE, APPLY. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
Never heard of CA-MSM, but I'll look into it. (I've been in contact with Bob Boerum at CA, but he's never mentioned it.) We've been using the SMP/E panels, and, as you say, letting them construct the JCL. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* In its state of nature [a dog] has a smell, and habits, which frustrate man's love; he washes it, house-trains it, teaches it not to steal, and is so enabled to love it completely. To the puppy, the whole proceeding would seem, if it were a theologian, to cast grave doubts on the "goodness" of man; but the full-grown and full-trained dog, larger, healthier and longer-lived than the wild dog, and admitted, as it were by Grace, to a whole world of affections, loyalties, interests and comforts entirely beyond its animal destiny, would have no such doubt. -C S Lewis, _The Problem of Pain_ */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, January 29, 2019 11:17 The other option is to see if the ISPF environment has the ISPF SMP/E panels available. That also can help reduce the stress of using SMP/E. REC/APP/REST/REJ/ACC are pretty easy to do. Try not to get lost in the details. The panels will wrap JCL around what you are going to do. I save that off to a dataset and then I have a sample of how to do each. > -Original Message- > From: > Lizette Koehler > Sent: Tuesday, January 29, 2019 9:15 AM > > For supporting any CA Product, you should be using if possible, CA MSM. > This is a gui interface that makes CA SMP/E maintenance easier. It pulls > the fixes, and you just select what you want it does the rest. Do you have > CAMSM available to you? > > > -Original Message- > > From: Bob Bridges > > Sent: Tuesday, January 29, 2019 9:07 AM > > > > I'm the Top-Secret admin for a client whose system programmer retired > > a couple years ago. The client tapped another employee to take his > > place, and she's learning the job with frantic haste but insists with > > some justification that she's not a system programmer yet. Me, I came > > into security through the applications-development side so I'm not even > > close. > > > > Together she and I are trying to learn SMP/E. The immediate purpose > > is so we can apply some TSS-related PTFs, but really, it's become > > clear to me that we need no excuses to make it a priority; SMP/E is kind of > > important. > > > > I have embarked on a serious reading of the SMP/E User's Guide, but I > > still need help. I'll limit myself to a handful of questions to start > > with: > > > > Question #1) We started by applying a PTF - call it A for simplicity - > > and its prerequisite B. We did that last August and then the project > > languished for the sake of other priorities. Now we're working on it > > again and we want to restore those two PTFs and do the APPLY again. > > Why? Well, partly because it was 'way back in August and we're > > uncertain about exactly how we did it back then. We know more now. > > Partly because we know more now and we want to practice it better. I > > dunno, partly because we just want to. I think maybe we bypassed some > > HOLDs back then too. > > > > Anyway, we attempted the RESTORE, but we got lots and lots of error > > messages saying we need to include other PTFs in the RESTORE. Some of > > these have an indirect connection to A and B; B superceded at least > > three of them, for example, which I can see were applied some years > > ago. Others have no relation to our PTFs that I can discern. I > > haven't yet found the place in the User's Guide that explains these > > relationship and their relevance. Can someone give a helpful explanation? > > > > Question #2) So far as we can tell by issuing LIST XREF commands, > > whoever ran this thing in the past never did any ACCEPT, ever, except > > for the original function code. I see at least 11 PTFs that were > > applied (including our two), but the distribution library shows no PTFs for > > any module I've yet LISTed. If true, does that mean that to do a RESTORE > > of our two PTFs we'll have to RESTORE everything back to the plain-vanilla > > base? > > > > Question #3) My partner the not-sysprog has in mind that maybe we need > > to set aside this CSI (which is dedicated to Top Secret) and create > > another one starting with the base software and build up from there. > > I didn't realize this could be done, but she thinks she can do it. If > > it'll work, I like it; we'll know in that case what we have, which we > > do not at present. Anyone have any thoughts on this plan? > > > > Question #4) This is a less-important add-on: In both the online > > documentation and the User's Guide, I read if I'm doing a RESTORE and > > name PTFs A and B, including the GROUP operand causes SMP/E to add > > whatever other PTFs are required for various reasons. It doesn't seem
Re: Newbie SMP/E questions
On Tue, 29 Jan 2019 11:06:51 -0500, Bob Bridges wrote: >... >Anyway, we attempted the RESTORE, but we got lots and lots of error messages >saying we need to include other PTFs in the RESTORE. Some of these have an >indirect connection to A and B; B superceded at least three of them, for >example, which I can see were applied some years ago. Others have no relation >to our PTFs that I can discern. I haven't yet found the place in the User's >Guide that explains these relationship and their relevance. Can someone give >a helpful explanation? > >Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran >this thing in the past never did any ACCEPT, ever, except for the original >function code. I see at least 11 PTFs that were applied (including our two), >but the distribution library shows no PTFs for any module I've yet LISTed. If >true, does that mean that to do a RESTORE of our two PTFs we'll have to >RESTORE everything back to the plain-vanilla base? > Either that, or ACCEPT everything up to exactly the level you want to fall back to. RESTORE will revert only to an ACCEPTed service level. >Question #3) My partner the not-sysprog has in mind that maybe we need to set >aside this CSI (which is dedicated to Top Secret) and create another one >starting with the base software and build up from there. I didn't realize >this could be done, but she thinks she can do it. If it'll work, I like it; >we'll know in that case what we have, which we do not at present. Anyone have >any thoughts on this plan? > Good idea. Or, even, copy the CSI (SMP/E has commands for this) and experiment on the copy. >Question #4) This is a less-important add-on: In both the online >documentation and the User's Guide, I read if I'm doing a RESTORE and name >PTFs A and B, including the GROUP operand causes SMP/E to add whatever other >PTFs are required for various reasons. It doesn't seem to, though; it names >them and complains about them, but doesn't add them to the list. Have I >misunderstood something? I'm loathe to believe the documentation is flat >wrong. > >If you're getting ready to send rushed messages saying "DON'T DO ANYTHING >UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > Unfortunately ACCEPT CHECK does not set things up properly for a RESTORE CHECK. SMP/E sorely needs an "UNDO" command (and associated UNDO CHECK) to revert the state exactly to an earlier service level. ACCEPT-RESTORE doesn't come close. The alternative is to HSM restore from an HSM backup. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
I will second what Lizette said, but also, I have to ask, the 'other' person tapped to take over, was she a sysprog ? new to SMP/E? seems 2 years is a long time for any maint not applied to any security product. you should concentrate on your current situation, research the use of APPLY/ RESTORE with group or groupextend, research why a PTF will not apply or restore, it may be a valid reason, not all PTF's will apply or restore. I suggest an SMP/E course sooner than later Carmen Vitullo - Original Message - From: "Lizette Koehler" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, January 29, 2019 10:17:17 AM Subject: Re: Newbie SMP/E questions The other option is to see if the ISPF environment has the ISPF SMP/E panels available. That also can help reduce the stress of using SMP/E REC/APP/REST/REJ/ACC are pretty easy to do. Try not to get lost in the details. The panels will wrap JCL around what you are going to do. I save that off to a dataset and then I have a sample of how to do each. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Lizette Koehler > Sent: Tuesday, January 29, 2019 9:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Newbie SMP/E questions > > For supporting any CA Product, you should be using if possible, CA MSM. > > This is a gui interface that makes CA SMP/E maintenance easier > > It pulls the fixes, and you just select what you want it does the rest. > > Do you have CAMSM available to you? > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Bob Bridges > > Sent: Tuesday, January 29, 2019 9:07 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Newbie SMP/E questions > > > > I'm the Top-Secret admin for a client whose system programmer retired > > a couple years ago. The client tapped another employee to take his > > place, and she's learning the job with frantic haste but insists with > > some justification that she's not a system programmer yet. Me, I came > > into security through the applications-development side so I'm not even > close. > > > > Together she and I are trying to learn SMP/E. The immediate purpose > > is so we can apply some TSS-related PTFs, but really, it's become > > clear to me that we need no excuses to make it a priority; SMP/E is kind of > important. > > > > I have embarked on a serious reading of the SMP/E User's Guide, but I > > still need help. I'll limit myself to a handful of questions to start > with: > > > > Question #1) We started by applying a PTF - call it A for simplicity - > > and its prerequisite B. We did that last August and then the project > > languished for the sake of other priorities. Now we're working on it > > again and we want to restore those two PTFs and do the APPLY again. > > Why? Well, partly because it was 'way back in August and we're > > uncertain about exactly how we did it back then. We know more now. > > Partly because we know more now and we want to practice it better. I > > dunno, partly because we just want to. I think maybe we bypassed some > HOLDs back then too. > > > > Anyway, we attempted the RESTORE, but we got lots and lots of error > > messages saying we need to include other PTFs in the RESTORE. Some of > > these have an indirect connection to A and B; B superceded at least > > three of them, for example, which I can see were applied some years > > ago. Others have no relation to our PTFs that I can discern. I > > haven't yet found the place in the User's Guide that explains these > > relationship and their relevance. Can someone give a helpful explanation? > > > > Question #2) So far as we can tell by issuing LIST XREF commands, > > whoever ran this thing in the past never did any ACCEPT, ever, except > > for the original function code. I see at least 11 PTFs that were > > applied (including our two), but the distribution library shows no PTFs for > any module I've yet LISTed. > > If true, does that mean that to do a RESTORE of our two PTFs we'll > > have to RESTORE everything back to the plain-vanilla base? > > > > Question #3) My partner the not-sysprog has in mind that maybe we need > > to set aside this CSI (which is dedicated to Top Secret) and create > > another one starting with the base software and build up from there. > > I didn't realize this could be done, but she thinks she can do it. If > > it'll work, I like it; we'll know in that case what we have, which we > > do not at present. Anyone have any thoughts on this plan? > >
Re: Newbie SMP/E questions
Hi Bob, 2) Yes for the current situation. If, however, PTFs between base and your new PTFs are ACCEPTd, no. Regards, David On 2019-01-29 11:06, Bob Bridges wrote: > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. > > I have embarked on a serious reading of the SMP/E User's Guide, but I still > need help. I'll limit myself to a handful of questions to start with: > > Question #1) We started by applying a PTF - call it A for simplicity - and > its prerequisite B. We did that last August and then the project languished > for the sake of other priorities. Now we're working on it again and we want > to restore those two PTFs and do the APPLY again. Why? Well, partly because > it was 'way back in August and we're uncertain about exactly how we did it > back then. We know more now. Partly because we know more now and we want to > practice it better. I dunno, partly because we just want to. I think maybe > we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an > indirect connection to A and B; B superceded at least three of them, for > example, which I can see were applied some years ago. Others have no > relation to our PTFs that I can discern. I haven't yet found the place in > the User's Guide that explains these relationship and their relevance. Can > someone give a helpful explanation? > > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. I see at least 11 PTFs that were applied (including our two), > but the distribution library shows no PTFs for any module I've yet LISTed. > If true, does that mean that to do a RESTORE of our two PTFs we'll have to > RESTORE everything back to the plain-vanilla base? > > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever other > PTFs are required for various reasons. It doesn't seem to, though; it names > them and complains about them, but doesn't add them to the list. Have I > misunderstood something? I'm loathe to believe the documentation is flat > wrong. > > If you're getting ready to send rushed messages saying "DON'T DO ANYTHING > UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > > --- > Bob Bridges, cell 336 382-7313 >robhbrid...@gmail.com >rbrid...@infosecinc.com > > /* Anyone can do any amount of work, provided it isn't the work he is > supposed be doing at that moment. -Robert Benchley */ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newbie SMP/E questions
The other option is to see if the ISPF environment has the ISPF SMP/E panels available. That also can help reduce the stress of using SMP/E REC/APP/REST/REJ/ACC are pretty easy to do. Try not to get lost in the details. The panels will wrap JCL around what you are going to do. I save that off to a dataset and then I have a sample of how to do each. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Lizette Koehler > Sent: Tuesday, January 29, 2019 9:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Newbie SMP/E questions > > For supporting any CA Product, you should be using if possible, CA MSM. > > This is a gui interface that makes CA SMP/E maintenance easier > > It pulls the fixes, and you just select what you want it does the rest. > > Do you have CAMSM available to you? > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Bob Bridges > > Sent: Tuesday, January 29, 2019 9:07 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Newbie SMP/E questions > > > > I'm the Top-Secret admin for a client whose system programmer retired > > a couple years ago. The client tapped another employee to take his > > place, and she's learning the job with frantic haste but insists with > > some justification that she's not a system programmer yet. Me, I came > > into security through the applications-development side so I'm not even > close. > > > > Together she and I are trying to learn SMP/E. The immediate purpose > > is so we can apply some TSS-related PTFs, but really, it's become > > clear to me that we need no excuses to make it a priority; SMP/E is kind of > important. > > > > I have embarked on a serious reading of the SMP/E User's Guide, but I > > still need help. I'll limit myself to a handful of questions to start > with: > > > > Question #1) We started by applying a PTF - call it A for simplicity - > > and its prerequisite B. We did that last August and then the project > > languished for the sake of other priorities. Now we're working on it > > again and we want to restore those two PTFs and do the APPLY again. > > Why? Well, partly because it was 'way back in August and we're > > uncertain about exactly how we did it back then. We know more now. > > Partly because we know more now and we want to practice it better. I > > dunno, partly because we just want to. I think maybe we bypassed some > HOLDs back then too. > > > > Anyway, we attempted the RESTORE, but we got lots and lots of error > > messages saying we need to include other PTFs in the RESTORE. Some of > > these have an indirect connection to A and B; B superceded at least > > three of them, for example, which I can see were applied some years > > ago. Others have no relation to our PTFs that I can discern. I > > haven't yet found the place in the User's Guide that explains these > > relationship and their relevance. Can someone give a helpful explanation? > > > > Question #2) So far as we can tell by issuing LIST XREF commands, > > whoever ran this thing in the past never did any ACCEPT, ever, except > > for the original function code. I see at least 11 PTFs that were > > applied (including our two), but the distribution library shows no PTFs for > any module I've yet LISTed. > > If true, does that mean that to do a RESTORE of our two PTFs we'll > > have to RESTORE everything back to the plain-vanilla base? > > > > Question #3) My partner the not-sysprog has in mind that maybe we need > > to set aside this CSI (which is dedicated to Top Secret) and create > > another one starting with the base software and build up from there. > > I didn't realize this could be done, but she thinks she can do it. If > > it'll work, I like it; we'll know in that case what we have, which we > > do not at present. Anyone have any thoughts on this plan? > > > > Question #4) This is a less-important add-on: In both the online > > documentation and the User's Guide, I read if I'm doing a RESTORE and > > name PTFs A and B, including the GROUP operand causes SMP/E to add > > whatever other PTFs are required for various reasons. It doesn't seem > > to, though; it names them and complains about them, but doesn't add > > them to the list. Have I misunderstood something? I'm loathe to > > believe the documentation is flat wrong. > > > > If you're getting ready to send rushed messages saying "DON'T DO > > ANYTHING UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > > > >
Re: Newbie SMP/E questions
For supporting any CA Product, you should be using if possible, CA MSM. This is a gui interface that makes CA SMP/E maintenance easier It pulls the fixes, and you just select what you want it does the rest. Do you have CAMSM available to you? Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Bob Bridges > Sent: Tuesday, January 29, 2019 9:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Newbie SMP/E questions > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important. > > I have embarked on a serious reading of the SMP/E User's Guide, but I still > need help. I'll limit myself to a handful of questions to start with: > > Question #1) We started by applying a PTF - call it A for simplicity - and > its prerequisite B. We did that last August and then the project languished > for the sake of other priorities. Now we're working on it again and we want > to restore those two PTFs and do the APPLY again. Why? Well, partly because > it was 'way back in August and we're uncertain about exactly how we did it > back then. We know more now. Partly because we know more now and we want to > practice it better. I dunno, partly because we just want to. I think maybe > we bypassed some HOLDs back then too. > > Anyway, we attempted the RESTORE, but we got lots and lots of error messages > saying we need to include other PTFs in the RESTORE. Some of these have an > indirect connection to A and B; B superceded at least three of them, for > example, which I can see were applied some years ago. Others have no > relation to our PTFs that I can discern. I haven't yet found the place in > the User's Guide that explains these relationship and their relevance. Can > someone give a helpful explanation? > > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. I see at least 11 PTFs that were applied (including our two), > but the distribution library shows no PTFs for any module I've yet LISTed. > If true, does that mean that to do a RESTORE of our two PTFs we'll have to > RESTORE everything back to the plain-vanilla base? > > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? > > Question #4) This is a less-important add-on: In both the online > documentation and the User's Guide, I read if I'm doing a RESTORE and name > PTFs A and B, including the GROUP operand causes SMP/E to add whatever other > PTFs are required for various reasons. It doesn't seem to, though; it names > them and complains about them, but doesn't add them to the list. Have I > misunderstood something? I'm loathe to believe the documentation is flat > wrong. > > If you're getting ready to send rushed messages saying "DON'T DO ANYTHING > UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > > --- > Bob Bridges, cell 336 382-7313 > robhbrid...@gmail.com > rbrid...@infosecinc.com > > /* Anyone can do any amount of work, provided it isn't the work he is > supposed be doing at that moment. -Robert Benchley */ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Newbie SMP/E questions
I'm the Top-Secret admin for a client whose system programmer retired a couple years ago. The client tapped another employee to take his place, and she's learning the job with frantic haste but insists with some justification that she's not a system programmer yet. Me, I came into security through the applications-development side so I'm not even close. Together she and I are trying to learn SMP/E. The immediate purpose is so we can apply some TSS-related PTFs, but really, it's become clear to me that we need no excuses to make it a priority; SMP/E is kind of important. I have embarked on a serious reading of the SMP/E User's Guide, but I still need help. I'll limit myself to a handful of questions to start with: Question #1) We started by applying a PTF - call it A for simplicity - and its prerequisite B. We did that last August and then the project languished for the sake of other priorities. Now we're working on it again and we want to restore those two PTFs and do the APPLY again. Why? Well, partly because it was 'way back in August and we're uncertain about exactly how we did it back then. We know more now. Partly because we know more now and we want to practice it better. I dunno, partly because we just want to. I think maybe we bypassed some HOLDs back then too. Anyway, we attempted the RESTORE, but we got lots and lots of error messages saying we need to include other PTFs in the RESTORE. Some of these have an indirect connection to A and B; B superceded at least three of them, for example, which I can see were applied some years ago. Others have no relation to our PTFs that I can discern. I haven't yet found the place in the User's Guide that explains these relationship and their relevance. Can someone give a helpful explanation? Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran this thing in the past never did any ACCEPT, ever, except for the original function code. I see at least 11 PTFs that were applied (including our two), but the distribution library shows no PTFs for any module I've yet LISTed. If true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE everything back to the plain-vanilla base? Question #3) My partner the not-sysprog has in mind that maybe we need to set aside this CSI (which is dedicated to Top Secret) and create another one starting with the base software and build up from there. I didn't realize this could be done, but she thinks she can do it. If it'll work, I like it; we'll know in that case what we have, which we do not at present. Anyone have any thoughts on this plan? Question #4) This is a less-important add-on: In both the online documentation and the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, including the GROUP operand causes SMP/E to add whatever other PTFs are required for various reasons. It doesn't seem to, though; it names them and complains about them, but doesn't add them to the list. Have I misunderstood something? I'm loathe to believe the documentation is flat wrong. If you're getting ready to send rushed messages saying "DON'T DO ANYTHING UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. --- Bob Bridges, cell 336 382-7313 robhbrid...@gmail.com rbrid...@infosecinc.com /* Anyone can do any amount of work, provided it isn't the work he is supposed be doing at that moment. -Robert Benchley */ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
