Re: websphere-liberty question
Why does your application have to be deployed in Liberty? What's wrong with a free, open source servlet container? I noticed that the API mediation layer in Zowe is a Spring Boot application. Spring Boot has to be the most popular Java web framework right now especially for REST APIs, micro-services etc. Are you sure you really need a application server? If all you want to do is use the z/OSMF TSO API you don't need a server to do that. On 27/09/2018 7:09 AM, scott Ford wrote: Matt, Yes sir as far as I know. Scott On Wed, Sep 26, 2018 at 4:06 PM Matt Hogstrom wrote: z/OSMF has services that enable TSO services … your App is in Java and you want to host it in a Liberty container ? Matt Hogstrom m...@hogstrom.org +1-919-656-0564 PGP Key: 0x90ECB270 I just read a book on Stockholm Syndrome, it was pretty bad at first, but, by the end I kind of liked it. On Sep 26, 2018, at 12:04 PM, scott Ford wrote: We are developing solutions for a product and are a Partnerworld partner of course. Basic sending TSO code retrieving output. Scott On Wed, Sep 26, 2018 at 1:59 AM David Crayford wrote: If you have purchased CICS you get CICS WLP. Same for IMS and WAS. There is no free WLP. IBM don't give away freebies on z/OS. Also, only IBM signed code can run in z/OSMF. Why do you ask? What are you trying to achieve? On 25/09/2018 11:47 PM, scott Ford wrote: Does anyone know when you order z/OS new or otherwise if Websphere and CICS Liberty are optional costs or are they included. Thanks in advance. Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Scott Ford IDMWORKS z/OS Development -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why Salesforce for SR?
Word on the street is IBM is moving off of RETAIN entirely. Get used to salesforce... On Wed, Sep 26, 2018 at 7:45 PM Clark Morris wrote: > Since Salesforce isn't owned by IBM why is what could be something > requiring potential decent degree of confidentiality such as Service > Request when dumps are involved being migrated there? > > Clark Morris > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- zMan -- "I've got a mainframe and I'm not afraid to use it" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why Salesforce for SR?
I don't have a dog in this fight. IBM can use dBase III to store their data for all I care. I don't own Salesforce stock. But I would assume that every company that uses Salesforce considers their data to be super confidential. What could a company consider more confidential than sales leads, customer lists, customer dollar volume, customer contacts and so forth? And apparently Salesforce has satisfied those customers that it is up to the task. Given GDPR, *all* PII is super confidential now. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Wednesday, September 26, 2018 4:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why Salesforce for SR? Since Salesforce isn't owned by IBM why is what could be something requiring potential decent degree of confidentiality such as Service Request when dumps are involved being migrated there? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Why Salesforce for SR?
Since Salesforce isn't owned by IBM why is what could be something requiring potential decent degree of confidentiality such as Service Request when dumps are involved being migrated there? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Annoying sign in button for SR
What I have done is go through the Signon Process Then use the Back Page at the top and find my entry I had started on. I usually can save my details by going back one or two pages It seems that I only have 5 mins before I am timed out. I have sent in an SR HELP DESK REQUEST. Maybe if we all do that, it will make a difference ;-D Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Jousma, David > Sent: Wednesday, September 26, 2018 9:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Annoying sign in button for SR > > Yes, along with what seems to be about a 15 minute timeout. I've had SR's > open keyed in lengthy update, only to press submit, and get sent to the logon > screen again, and my updates gone. I've had to get back into the habit of > cutting/paste my updates into notepad "just in case" the update didn’t go > through. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Pinnacle > Sent: Wednesday, September 26, 2018 12:51 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Annoying sign in button for SR > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Anybody else enjoy logging on to IBMLink, hitting the SR link, then being > presented a sign-in button that only requires you to press it, but doesn't > prompt you again for sign-on credentials? Maybe IBM > forcin...er...encouraging us to go to Salesforce? > > 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: DISA STIG and permission/audit bits
On 9/26/2018 9:33 AM, Larre Shiller wrote: As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... If these changes are a "best practice" then perhaps IBM could be similarly "goaded" via the requirements process? -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM options for dataset back-up
Unfortunately for me, we discontinued my Resolve for zService subscription with the migration to MFaaS. I admit I haven't tried to enter a SR recently (my IBM id is still good), but I think I'd need to go through our host's service account. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ed Jaffe > Sent: Wednesday, September 26, 2018 4:21 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM options for dataset back-up > > On 9/26/2018 10:21 AM, Gibney, Dave wrote: > > Since moving to MFaaS, my ibmlink access is reduced. > > This hasn't got anything to do with IBMLink. ETR disappeared a while back. > > This complaint is about Service Request, which is transitioning to > Salesforce... > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.phoenixsoftware.com_=DwICaQ=C3yme8gMkxg_ihJNXS06Z > yWk4EJm8LdrrvxQb- > Je7sw=u9g8rUevBoyCPAdo5sWE9w=rWlOnySLSnh4kwHL0CTWWClgLy > 4froVy6-gKq-9r5- > o=Kw3RfKMiei265Ng1fqiHx8wLjAb3Ctm0FQQqD_Eh0VU= > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to > be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > 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: DFHSM options for dataset back-up
On 9/26/2018 10:21 AM, Gibney, Dave wrote: Since moving to MFaaS, my ibmlink access is reduced. This hasn't got anything to do with IBMLink. ETR disappeared a while back. This complaint is about Service Request, which is transitioning to Salesforce... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: websphere-liberty question
Matt, Yes sir as far as I know. Scott On Wed, Sep 26, 2018 at 4:06 PM Matt Hogstrom wrote: > z/OSMF has services that enable TSO services … your App is in Java and you > want to host it in a Liberty container ? > > > > Matt Hogstrom > m...@hogstrom.org > +1-919-656-0564 > PGP Key: 0x90ECB270 > > I just read a book on Stockholm Syndrome, > it was pretty bad at first, but, by the end I kind of liked it. > > > On Sep 26, 2018, at 12:04 PM, scott Ford wrote: > > > > We are developing solutions for a product and are a Partnerworld partner > of > > course. > > Basic sending TSO code retrieving output. > > > > Scott > > > > On Wed, Sep 26, 2018 at 1:59 AM David Crayford > wrote: > > > >> If you have purchased CICS you get CICS WLP. Same for IMS and WAS. There > >> is no free WLP. IBM don't give away freebies on z/OS. > >> > >> Also, only IBM signed code can run in z/OSMF. > >> > >> Why do you ask? What are you trying to achieve? > >> > >> > >> On 25/09/2018 11:47 PM, scott Ford wrote: > >>> Does anyone know when you order z/OS new or otherwise if Websphere and > >>> CICS Liberty are optional costs or are they included. > >>> > >>> Thanks in advance. > >>> > >>> Scott > >>> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > -- > > Scott Ford > > IDMWORKS > > z/OS Development > > > > -- > > 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Take out the garbage
It's bad enough we have to see the useless crap appended to emails from all the silly-ass companies that do it, but now we have to deal with URL vandalism by Microsoft and Cisco. Recent posts show some links wrapped by one, and then re-wrapped by the other. Take a second and delete all that junk before sending your reply, please. The signal-to-noise ratio is getting pretty low. -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECB in XMEM Post
I don't know but it would seem not, wouldn't it? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, September 26, 2018 11:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post Is that true for address spaces with non-reusable ASIDs? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: websphere-liberty question
z/OSMF has services that enable TSO services … your App is in Java and you want to host it in a Liberty container ? Matt Hogstrom m...@hogstrom.org +1-919-656-0564 PGP Key: 0x90ECB270 I just read a book on Stockholm Syndrome, it was pretty bad at first, but, by the end I kind of liked it. > On Sep 26, 2018, at 12:04 PM, scott Ford wrote: > > We are developing solutions for a product and are a Partnerworld partner of > course. > Basic sending TSO code retrieving output. > > Scott > > On Wed, Sep 26, 2018 at 1:59 AM David Crayford wrote: > >> If you have purchased CICS you get CICS WLP. Same for IMS and WAS. There >> is no free WLP. IBM don't give away freebies on z/OS. >> >> Also, only IBM signed code can run in z/OSMF. >> >> Why do you ask? What are you trying to achieve? >> >> >> On 25/09/2018 11:47 PM, scott Ford wrote: >>> Does anyone know when you order z/OS new or otherwise if Websphere and >>> CICS Liberty are optional costs or are they included. >>> >>> Thanks in advance. >>> >>> Scott >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- > Scott Ford > IDMWORKS > z/OS Development > > -- > 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: ECB in XMEM Post
Is that true for address spaces with non-reusable ASIDs? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Wednesday, September 26, 2018 12:20 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: ECB in XMEM Post Definitely take a look at IEAMSXMP *if you will always be running on a supported version of z/OS.* As I understand things it is impossible to do a perfect job of X-memory POST. There is no way to write code that with absolute certainty will not POST after its partner program has terminated and been replaced by some other process -- and thus "POST" into the middle of some unrelated code or data. You can do a pretty good job -- but with z/OS one can certainly argue that pretty good is not good enough. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Wednesday, September 26, 2018 7:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post I would be concerned in the fact that cross-memory POST is only deemed safe in certain circumstances. I believe that normal cross-memory POST does not validate the ECB-owning address space STOKEN or TCB token. IBM do offer IEAMSXMP which is a safe cross-memory POST protocol if pause/release or PC-ss cannot be used. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Wednesday, September 26, 2018 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post Rob This is just a question is your comment based on the fact the ECB might be in pageable non/fixed storage and has potential for s0c4 Thanks > On Sep 26, 2018, at 9:23 AM, Rob Scott wrote: > > Both Pause/Release and PC-ss are supported in SRB mode. > > The fact that you are in recovery code (and possibly unsure of the status of > both ECB-owner and client) makes me believe that cross-memory POST is even > more undesirable. > > Not saying that it cannot be done with cross-memory POST, but Pause/Release > offers more environmental validation prior to execution and encapsulating a > PC-ss "POST" function isolates the recovery code from ECB-owner architecture > and may allow recovery code to run problem state. > > As ever in the case of things like this, it is never what you *intend* to do > that causes the problem.. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Wednesday, September 26, 2018 1:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ECB in XMEM Post > > You are right as it kills all registers besides 9 If memory serves me > right I think the for the system or PC call > > I know you are going to scream at me but the reason I choose the post > is because I’m posting This from a recovery routine as I don’t know > whether it’s TCB mode or SRB I’m using the system call I.E pc I am > passing the SDWA storage area back in the 3 byte 24 bit comp code area > The 3 byte comp code makes this convenient for me > > >> On Sep 26, 2018, at 8:11 AM, Rob Scott wrote: >> >> Please be aware that cross-memory POSTs are not ideal and if possible I >> would consider a redesign of your code to use other methods - for example : >> >> (1) Pause/Release >> (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf >> >> Just my 2c. >> >> Rob Scott >> Rocket Software >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman >> Sent: Wednesday, September 26, 2018 1:01 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: ECB in XMEM Post >> >> Sorry I misunderstood >> So if Address Space A would like to post Address B the ECB must be >> addressable to to B as that is the Target the ASCB is that of the >> target Address space B the ECB can be B private area in A all I need >> is the address of the ECB even in private and ASCB of B >> >> Thanks >> >> >> On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: >> This is just another way of saying that for XMEM the ECB is in CSA right >>> ? >>> No, not right. >>> >>> What within the wording "must be addressable from the address space >>> identified by the ASCB parameter" makes you say that? Storage >>> addressable from an address space includes common storage (whether >>> CSA or SQA) and private storage of the address space. The ECB can be >>> in any of those areas. >>> >>> Peter Relson >>> z/OS Core Technology Design >>> >>> >>> >>> -- 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: ECB in XMEM Post
Pageable should not be a problem. If the ECB is in a swappable address space, that could be a problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Wednesday, September 26, 2018 9:31 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: ECB in XMEM Post Rob This is just a question is your comment based on the fact the ECB might be in pageable non/fixed storage and has potential for s0c4 Thanks > On Sep 26, 2018, at 9:23 AM, Rob Scott wrote: > > Both Pause/Release and PC-ss are supported in SRB mode. > > The fact that you are in recovery code (and possibly unsure of the status of > both ECB-owner and client) makes me believe that cross-memory POST is even > more undesirable. > > Not saying that it cannot be done with cross-memory POST, but Pause/Release > offers more environmental validation prior to execution and encapsulating a > PC-ss "POST" function isolates the recovery code from ECB-owner architecture > and may allow recovery code to run problem state. > > As ever in the case of things like this, it is never what you *intend* to do > that causes the problem.. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Wednesday, September 26, 2018 1:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ECB in XMEM Post > > You are right as it kills all registers besides 9 If memory serves me right I > think the for the system or PC call > > I know you are going to scream at me but the reason I choose the post is > because I’m posting This from a recovery routine as I don’t know whether it’s > TCB mode or SRB I’m using the system call I.E pc I am passing the SDWA > storage area back in the 3 byte 24 bit comp code area The 3 byte comp code > makes this convenient for me > > >> On Sep 26, 2018, at 8:11 AM, Rob Scott wrote: >> >> Please be aware that cross-memory POSTs are not ideal and if possible I >> would consider a redesign of your code to use other methods - for example : >> >> (1) Pause/Release >> (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf >> >> Just my 2c. >> >> Rob Scott >> Rocket Software >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Joseph Reichman >> Sent: Wednesday, September 26, 2018 1:01 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: ECB in XMEM Post >> >> Sorry I misunderstood >> So if Address Space A would like to post Address B the ECB must be >> addressable to to B as that is the Target the ASCB is that of the target >> Address space B the ECB can be B private area in A all I need is the address >> of the ECB even in private and ASCB of B >> >> Thanks >> >> >> On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: >> This is just another way of saying that for XMEM the ECB is in CSA right >>> ? >>> No, not right. >>> >>> What within the wording "must be addressable from the address space >>> identified by the ASCB parameter" makes you say that? Storage >>> addressable from an address space includes common storage (whether CSA >>> or SQA) and private storage of the address space. The ECB can be in >>> any of those areas. >>> >>> Peter Relson >>> z/OS Core Technology Design >>> >>> >>> -- >>> 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 >> >> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 >> ■ Main Office Toll Free Number: +1 855.577.4323 >> Contact Customer Support: >> https://secure-web.cisco.com/1Ii---t4ISkTb3Cw4LvQoU_ptHQeciWelMqfXbGZIfxh1341MrEuuqaMQJ7uWjB9I7yLrtpSqacsJeDxnO2kDnjqd91InI4_iDxssCnQmPyoEOqMNkWfBGJlJLbMKh9oezS-UXNV1e1IXrhSkzhdst_ovNbkie1wIqxt7vPxfcFxF_0IHK1fv7lRKQ7jn_QUA33GRPeL6Vv6d2duufAVTlQtsP3kgpd4uQThBmlJV3sL17Ql3ls14y6KjkDD5owD8jw0oIzFjWTevXv2oEkkPtKnypmGtIgZOZk5QeE9XjMrz2Z5tvaUATk6oEtEKnxWejV3fGCjxj-cQi859o5jAMfXlGbFUcjCOpyoB1XbmbEPjs7NotqD8jPzaDTVKguDmYf0Ca-k1y5F7le5Yxs3b-gnGP43lpctrQjcRsnHa7amGdcVcRMpavJ-kRmMJVo_KW53CD11TPiy25ZvFZ7rh8Q/https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fmy.rocketsoftware.com%252FRocketCommunity%252FRCEmailSupport%26data%3D02%257C01%257CRScott%2540ROCKETSOFTWARE.COM%257C9d76c8e06d0243b3b78e08d623aadd75%257C79544c1eed224879a082b67a9a672aae%257C0%257C0%257C636735614108579486%26sdata%3DrG7j%252B1He%252FF8yklpcRgE3iVYMQ4B7XWkiVzlStrEPE%252FQ%253D%26reserved%3D0 >> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - >>
Re: DISA STIG and permission/audit bits
Have you discussed with your auditors the risks associated with changing the permission bits set by the product and service installs? Compliance with the STIG could conceivably break something, and denial of service is itself a security violation. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Larre Shiller <0102cb4997b0-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 26, 2018 12:33 PM To: IBM-MAIN@listserv.ua.edu Subject: DISA STIG and permission/audit bits As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... Thanks. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- 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: TSO RENAME broke?
ObNit; okay, a wrapper for IDCAMS ALTER NEWNAME -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Wednesday, September 26, 2018 1:03 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: TSO RENAME broke? On 25 September 2018 at 15:30, Seymour J Metz wrote: > TSO RENAME is just a wrapper for IDCAMS RENAME. No. It's a standalone TSO CP, IKJEHREN, that does all the work itself. Well obviously it calls various services like DAIR, CAMLST, and so on, but it is not a front end for IDCAMS. Not that IDCAMS *has* a RENAME command, for that matter... Tony H. -- 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: Annoying sign in button for SR
On Wed, 26 Sep 2018 13:09:05 -0400, Tom Conley wrote: >On 9/26/2018 12:53 PM, Jousma, David wrote: >> Yes, along with what seems to be about a 15 minute timeout. I've had SR's >> open keyed in lengthy update, only to press submit, and get sent to the >> logon screen again, and my updates gone. I've had to get back into the >> habit of cutting/paste my updates into notepad "just in case" the update >> didn’t go through. >> >GIT THYSELF TO SALESFORCE!!! > Assume the timeout is desired for security. In that case the screen should be cleared lest the terminal be unattended, but redisplayed on reconnect. How about, at timeout, READ SCREEN into a buffer; return to logon; display buffer at reconnect? If timeout is to conserve resources, how costly is it to store that buffer? Block mode terminals are not ideal for this purpose. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] DISA STIG and permission/audit bits
Yeah... I know. That being said... perhaps the READ ONLY option is something that we can try. Thanks for making that suggestion. Larre There is no way in that I'd be messing with permissions bits on anything IBM provided. We do mount all of that READ only however so that contents cannot be changed. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Larre Shiller Sent: Wednesday, September 26, 2018 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] DISA STIG and permission/audit bits As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... Thanks. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM options for dataset back-up
I guess I will look at my own trail. That's when I put the UPDATEFLAG=NOCHANGE into our FDRABR SMS pool back-up. I should have opened a PMR/SR then, when we we a direct IBM customer. Since moving to MFaaS, my ibmlink access is reduced. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Richards, Robert B. > Sent: Wednesday, September 26, 2018 3:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM options for dataset back-up > > Dave, > > You had a similar thread on a variation of this topic in May of 2010. History > repeating itself? :-) > > Open a PMR/SR to DFSMShsm development. I could not find a specific PATCH > example matching your need in any of the usual manuals containing PATCH > criteria. > > Bob > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Tuesday, September 25, 2018 7:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM options for dataset back-up > > I will RTFM, but don't feel like starting there. For many historical (some > hysterical) we run both DFHSM and FDRABR against our SMS managed disk. > FDRABR does full-volume and incremental back-ups. DFHSM is just dataset > back-up. Bad experience with DFHSM DUMP a couple decades ago. > We use the FDRABR option UPDATEFLAG=NOCHANGE so DFHSM will back-up > (and maybe migrate) the datasets. Which means I must run FDRABR first. > > Does DFHSM have a similar option (PATCH or FIXCDS) to not set the change > bit? I'd like to switch the order (well, I already did and it isn't good) of > processing. > > Dave Gibney > Information Technology Services > Washington State University > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] DISA STIG and permission/audit bits
There is no way in that I'd be messing with permissions bits on anything IBM provided. We do mount all of that READ only however so that contents cannot be changed. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nash, Jonathan S. Sent: Wednesday, September 26, 2018 1:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] DISA STIG and permission/audit bits **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Dont sys admins usually write a shell script that sets premissions with chmod or something like that ? Do you guys have a guy who is good with shell scripts ? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Larre Shiller Sent: Wednesday, September 26, 2018 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] DISA STIG and permission/audit bits As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... Thanks. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- 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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] DISA STIG and permission/audit bits
Dont sys admins usually write a shell script that sets premissions with chmod or something like that ? Do you guys have a guy who is good with shell scripts ? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Larre Shiller Sent: Wednesday, September 26, 2018 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] DISA STIG and permission/audit bits As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... Thanks. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- 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: Annoying sign in button for SR
On 9/26/2018 12:53 PM, Jousma, David wrote: Yes, along with what seems to be about a 15 minute timeout. I've had SR's open keyed in lengthy update, only to press submit, and get sent to the logon screen again, and my updates gone. I've had to get back into the habit of cutting/paste my updates into notepad "just in case" the update didn’t go through. GIT THYSELF TO SALESFORCE!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RENAME broke?
On 25 September 2018 at 15:30, Seymour J Metz wrote: > TSO RENAME is just a wrapper for IDCAMS RENAME. No. It's a standalone TSO CP, IKJEHREN, that does all the work itself. Well obviously it calls various services like DAIR, CAMLST, and so on, but it is not a front end for IDCAMS. Not that IDCAMS *has* a RENAME command, for that matter... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Annoying sign in button for SR
Yes, along with what seems to be about a 15 minute timeout. I've had SR's open keyed in lengthy update, only to press submit, and get sent to the logon screen again, and my updates gone. I've had to get back into the habit of cutting/paste my updates into notepad "just in case" the update didn’t go through. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pinnacle Sent: Wednesday, September 26, 2018 12:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Annoying sign in button for SR **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Anybody else enjoy logging on to IBMLink, hitting the SR link, then being presented a sign-in button that only requires you to press it, but doesn't prompt you again for sign-on credentials? Maybe IBM forcin...er...encouraging us to go to Salesforce? Regards, Tom Conley -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Annoying sign in button for SR
Anybody else enjoy logging on to IBMLink, hitting the SR link, then being presented a sign-in button that only requires you to press it, but doesn't prompt you again for sign-on credentials? Maybe IBM forcin...er...encouraging us to go to Salesforce? Regards, Tom Conley -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DISA STIG and permission/audit bits
As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... Thanks. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECB in XMEM Post
Definitely take a look at IEAMSXMP *if you will always be running on a supported version of z/OS.* As I understand things it is impossible to do a perfect job of X-memory POST. There is no way to write code that with absolute certainty will not POST after its partner program has terminated and been replaced by some other process -- and thus "POST" into the middle of some unrelated code or data. You can do a pretty good job -- but with z/OS one can certainly argue that pretty good is not good enough. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Wednesday, September 26, 2018 7:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post I would be concerned in the fact that cross-memory POST is only deemed safe in certain circumstances. I believe that normal cross-memory POST does not validate the ECB-owning address space STOKEN or TCB token. IBM do offer IEAMSXMP which is a safe cross-memory POST protocol if pause/release or PC-ss cannot be used. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Wednesday, September 26, 2018 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post Rob This is just a question is your comment based on the fact the ECB might be in pageable non/fixed storage and has potential for s0c4 Thanks > On Sep 26, 2018, at 9:23 AM, Rob Scott wrote: > > Both Pause/Release and PC-ss are supported in SRB mode. > > The fact that you are in recovery code (and possibly unsure of the status of > both ECB-owner and client) makes me believe that cross-memory POST is even > more undesirable. > > Not saying that it cannot be done with cross-memory POST, but Pause/Release > offers more environmental validation prior to execution and encapsulating a > PC-ss "POST" function isolates the recovery code from ECB-owner architecture > and may allow recovery code to run problem state. > > As ever in the case of things like this, it is never what you *intend* to do > that causes the problem.. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Wednesday, September 26, 2018 1:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ECB in XMEM Post > > You are right as it kills all registers besides 9 If memory serves me > right I think the for the system or PC call > > I know you are going to scream at me but the reason I choose the post > is because I’m posting This from a recovery routine as I don’t know > whether it’s TCB mode or SRB I’m using the system call I.E pc I am > passing the SDWA storage area back in the 3 byte 24 bit comp code area > The 3 byte comp code makes this convenient for me > > >> On Sep 26, 2018, at 8:11 AM, Rob Scott wrote: >> >> Please be aware that cross-memory POSTs are not ideal and if possible I >> would consider a redesign of your code to use other methods - for example : >> >> (1) Pause/Release >> (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf >> >> Just my 2c. >> >> Rob Scott >> Rocket Software >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman >> Sent: Wednesday, September 26, 2018 1:01 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: ECB in XMEM Post >> >> Sorry I misunderstood >> So if Address Space A would like to post Address B the ECB must be >> addressable to to B as that is the Target the ASCB is that of the >> target Address space B the ECB can be B private area in A all I need >> is the address of the ECB even in private and ASCB of B >> >> Thanks >> >> >> On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: >> This is just another way of saying that for XMEM the ECB is in CSA right >>> ? >>> No, not right. >>> >>> What within the wording "must be addressable from the address space >>> identified by the ASCB parameter" makes you say that? Storage >>> addressable from an address space includes common storage (whether >>> CSA or SQA) and private storage of the address space. The ECB can be >>> in any of those areas. >>> >>> Peter Relson >>> z/OS Core Technology Design >>> >>> >>> >>> -- 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 Rocket Software, Inc. and >> subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll >> Free Number: +1 855.577.4323 Contact Customer Support: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.r >>
Re: websphere-liberty question
We are developing solutions for a product and are a Partnerworld partner of course. Basic sending TSO code retrieving output. Scott On Wed, Sep 26, 2018 at 1:59 AM David Crayford wrote: > If you have purchased CICS you get CICS WLP. Same for IMS and WAS. There > is no free WLP. IBM don't give away freebies on z/OS. > > Also, only IBM signed code can run in z/OSMF. > > Why do you ask? What are you trying to achieve? > > > On 25/09/2018 11:47 PM, scott Ford wrote: > > Does anyone know when you order z/OS new or otherwise if Websphere and > > CICS Liberty are optional costs or are they included. > > > > Thanks in advance. > > > > Scott > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RENAME broke?
Works on Tops r15 no problem here, we have 2.2 and 2.3 z Scott On Wed, Sep 26, 2018 at 9:43 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > I'm hoping not on both accounts! If something in Roscoe breaks, we'll > have to address that. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Paul Gilmartin > Sent: Wednesday, September 26, 2018 9:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: TSO RENAME broke? > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > On Wed, 26 Sep 2018 11:16:01 +, Jousma, David wrote: > > >Well, mystery solved. It's been broken at my installation for MANY > years (pre-dates my employment here).SYS1.CMDLIB was in LINKLST > concatenation after my favorite product (CA-Roscoe) which also has a member > called RENAME. Somehow, it never occurred to me to check this. > > > If you swap them, will that break Roscoe? Will anyone care? Will you > need an alternate TASKLIB concatenation? "[F]avorite"? Decades ago I was > delighted to abandon Roscoe in favor of TSO/SPF. SDSF made it better yet. > > What's a good diagnostic tool for this? ISRDDN MEMBER? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION > EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Master cats as user cats on other systems - why?
We don't share mastercats, because there was not yet really a reason for it and we have the updates well synchronized. The pro is of course that a mastercat problem will be isolated to a single system. Besides that, you will always have a number of mastercatalogs, at least 3 per Sysplex, because you cannot share data with your 2 GDPS K-systems and more groups of 3 if you have more sysplexes that you must keep synchronized for most of the entries. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: 26 September, 2018 16:10 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Master cats as user cats on other systems - why? > > I tend to generally concur w/Brian, but I do want to add an observation. > > Any time there are (three of something) vs (one of something) you are > (almost certainly) guaranteed to the one or more of the three, out of > sync. > Correction of "out of sync" conditions is generally painful and involves > a great deal of research and time to correct. > > Or to say the above in the short and sweet manner: > Two or more of something that don't agree, is worse than having nothing. > > The above being said, most "out of sync" conditions can be prevented by > application of appropriate operational discipline. > It has been my experience that very few shops employ appropriate > operational discipline. > > For this reason, I lean towards shared, rather than separate. > > My $0.02 USD > > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Brian Westerman > Sent: Wednesday, September 26, 2018 1:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Master cats as user cats on other systems - why? > > I think the op might really be trying to decide if it's "better" to have > a single MCAT for the site and thus have the same view of "everything" > or if having individual MCATs for each LPAR and then sharing them as > UCATs with the "other" LPARs is better. > > I have operated both ways and I really don't see a "super" benefit in > one method over the other that gives it something "more" than the other > way, I think that there are sites that have a philosophy of one MCAT for > the site and some that feel that each LPAR "needs" it's own MCAT. > > As for why they are shared, if you have multiple MCATs (one per LPAR) > and you want to be able to access data that is in MCAT-1 (on LPAR-1) > from a system that is using MCAT-2 (on LPAR-2) as it's MCAT, then you > need to make sure that MCAT-1 is available to LPAR-2 and since you can't > use STEPCAT and/or JOBCAT (any more) it's much simpler to define MCAT-1 > as a usercatalog of MCAT-2 (and MCAT-2 as a usercatalog of MCAT-1). > > I find that it's easy to get confused if you aren't careful in a > multiple MCAT system, and it's simple to overdo it with symbolics > whether you have a single MCAT or multiple MCATs, but that doesn't make > multiple MCAT's any less useful than a single MCAT, just different. > > With all of the things that IBM forces on us with z/OS, allowing you to > have a "choice" once it a while is (to me) a good thing. > > Brian > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > > > -- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > may contain viruses in transmission. The e mail and its contents (with > or without referred errors) shall therefore not attach any liability on > the originator or HCL or its affiliates. Views or opinions, if any, > presented in this email are solely those of the author and may not > necessarily reflect the views or opinions of HCL or its affiliates. Any > form of reproduction, dissemination, copying, disclosure, modification, > distribution and / or publication of this message without the prior > written consent of authorized representative of HCL is strictly > prohibited. If you have received this email in error please delete it > and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > > >
Re: Master cats as user cats on other systems - why?
Classification: Public The "platinum" (or ) build says to have a single master cat for all systems in a sysplex. Now I get that not everything is a sysplex, but where it is, take caution. Where you have master cats for other systems as user cats, there's a big red flag - the system won't let you delete the active master cat for the system you're on (you get IDC3009I, RC 90, RSN 2), but nothing stops you deleting a user cat that is also the master cat for another system. Once that "user cat" has been deleted, the other system very quickly decides that it can no longer continue life. (page datasets, from memory, are what it complained about first..) Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: 26 September 2018 15:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Master cats as user cats on other systems - why? -- This email has reached the Bank via an external source -- On Wed, 26 Sep 2018 14:09:48 +, Allan Staller wrote: >I tend to generally concur w/Brian, but I do want to add an observation. > >Any time there are (three of something) vs (one of something) you are (almost >certainly) guaranteed to the one or more of the three, out of sync. >Correction of "out of sync" conditions is generally painful and involves a >great deal of research and time to correct. > >Or to say the above in the short and sweet manner: >Two or more of something that don't agree, is worse than having nothing. > “never go to sea with two chronometers, take one or three” -- The Mythical Man-Month https://blog.ipspace.net/2017/01/never-take-two-chronometers-to-sea.html >The above being said, most "out of sync" conditions can be prevented by >application of appropriate operational discipline. >It has been my experience that very few shops employ appropriate operational >discipline. > >For this reason, I lean towards shared, rather than separate. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Master cats as user cats on other systems - why?
On Wed, 26 Sep 2018 14:09:48 +, Allan Staller wrote: >I tend to generally concur w/Brian, but I do want to add an observation. > >Any time there are (three of something) vs (one of something) you are (almost >certainly) guaranteed to the one or more of the three, out of sync. >Correction of "out of sync" conditions is generally painful and involves a >great deal of research and time to correct. > >Or to say the above in the short and sweet manner: >Two or more of something that don't agree, is worse than having nothing. > “never go to sea with two chronometers, take one or three” -- The Mythical Man-Month https://blog.ipspace.net/2017/01/never-take-two-chronometers-to-sea.html >The above being said, most "out of sync" conditions can be prevented by >application of appropriate operational discipline. >It has been my experience that very few shops employ appropriate operational >discipline. > >For this reason, I lean towards shared, rather than separate. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Master cats as user cats on other systems - why?
I tend to generally concur w/Brian, but I do want to add an observation. Any time there are (three of something) vs (one of something) you are (almost certainly) guaranteed to the one or more of the three, out of sync. Correction of "out of sync" conditions is generally painful and involves a great deal of research and time to correct. Or to say the above in the short and sweet manner: Two or more of something that don't agree, is worse than having nothing. The above being said, most "out of sync" conditions can be prevented by application of appropriate operational discipline. It has been my experience that very few shops employ appropriate operational discipline. For this reason, I lean towards shared, rather than separate. My $0.02 USD -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Wednesday, September 26, 2018 1:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Master cats as user cats on other systems - why? I think the op might really be trying to decide if it's "better" to have a single MCAT for the site and thus have the same view of "everything" or if having individual MCATs for each LPAR and then sharing them as UCATs with the "other" LPARs is better. I have operated both ways and I really don't see a "super" benefit in one method over the other that gives it something "more" than the other way, I think that there are sites that have a philosophy of one MCAT for the site and some that feel that each LPAR "needs" it's own MCAT. As for why they are shared, if you have multiple MCATs (one per LPAR) and you want to be able to access data that is in MCAT-1 (on LPAR-1) from a system that is using MCAT-2 (on LPAR-2) as it's MCAT, then you need to make sure that MCAT-1 is available to LPAR-2 and since you can't use STEPCAT and/or JOBCAT (any more) it's much simpler to define MCAT-1 as a usercatalog of MCAT-2 (and MCAT-2 as a usercatalog of MCAT-1). I find that it's easy to get confused if you aren't careful in a multiple MCAT system, and it's simple to overdo it with symbolics whether you have a single MCAT or multiple MCATs, but that doesn't make multiple MCAT's any less useful than a single MCAT, just different. With all of the things that IBM forces on us with z/OS, allowing you to have a "choice" once it a while is (to me) a good thing. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECB in XMEM Post
I would be concerned in the fact that cross-memory POST is only deemed safe in certain circumstances. I believe that normal cross-memory POST does not validate the ECB-owning address space STOKEN or TCB token. IBM do offer IEAMSXMP which is a safe cross-memory POST protocol if pause/release or PC-ss cannot be used. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Wednesday, September 26, 2018 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post Rob This is just a question is your comment based on the fact the ECB might be in pageable non/fixed storage and has potential for s0c4 Thanks > On Sep 26, 2018, at 9:23 AM, Rob Scott wrote: > > Both Pause/Release and PC-ss are supported in SRB mode. > > The fact that you are in recovery code (and possibly unsure of the status of > both ECB-owner and client) makes me believe that cross-memory POST is even > more undesirable. > > Not saying that it cannot be done with cross-memory POST, but Pause/Release > offers more environmental validation prior to execution and encapsulating a > PC-ss "POST" function isolates the recovery code from ECB-owner architecture > and may allow recovery code to run problem state. > > As ever in the case of things like this, it is never what you *intend* to do > that causes the problem.. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Wednesday, September 26, 2018 1:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ECB in XMEM Post > > You are right as it kills all registers besides 9 If memory serves me > right I think the for the system or PC call > > I know you are going to scream at me but the reason I choose the post > is because I’m posting This from a recovery routine as I don’t know > whether it’s TCB mode or SRB I’m using the system call I.E pc I am > passing the SDWA storage area back in the 3 byte 24 bit comp code area > The 3 byte comp code makes this convenient for me > > >> On Sep 26, 2018, at 8:11 AM, Rob Scott wrote: >> >> Please be aware that cross-memory POSTs are not ideal and if possible I >> would consider a redesign of your code to use other methods - for example : >> >> (1) Pause/Release >> (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf >> >> Just my 2c. >> >> Rob Scott >> Rocket Software >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman >> Sent: Wednesday, September 26, 2018 1:01 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: ECB in XMEM Post >> >> Sorry I misunderstood >> So if Address Space A would like to post Address B the ECB must be >> addressable to to B as that is the Target the ASCB is that of the >> target Address space B the ECB can be B private area in A all I need >> is the address of the ECB even in private and ASCB of B >> >> Thanks >> >> >> On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: >> This is just another way of saying that for XMEM the ECB is in CSA right >>> ? >>> No, not right. >>> >>> What within the wording "must be addressable from the address space >>> identified by the ASCB parameter" makes you say that? Storage >>> addressable from an address space includes common storage (whether >>> CSA or SQA) and private storage of the address space. The ECB can be >>> in any of those areas. >>> >>> Peter Relson >>> z/OS Core Technology Design >>> >>> >>> >>> -- 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 Rocket Software, Inc. and >> subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll >> Free Number: +1 855.577.4323 Contact Customer Support: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.r >> ocketsoftware.com%2FRocketCommunity%2FRCEmailSupportdata=02%7C01 >> %7CRScott%40ROCKETSOFTWARE.COM%7Cd997bf72252b48399ec008d623b4583b%7C7 >> 9544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735654825882842sdat >> a=FCzgvDLPFFnT99MDixYUBiA4e1Gnz39JBPLIeRNLApE%3Dreserved=0 >> Unsubscribe from Marketing Messages/Manage Your Subscription >> Preferences - >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r >> ocketsoftware.com%2Fmanage-your-email-preferencesdata=02%7C01%7C >> RScott%40ROCKETSOFTWARE.COM%7Cd997bf72252b48399ec008d623b4583b%7C7954 >> 4c1eed224879a082b67a9a672aae%7C0%7C0%7C636735654825882842sdata=c >> BXxvzlrU3dvgZwkYz7B3LWOz7HGGwKFiTt7uPYlsZ4%3Dreserved=0 >> Privacy Policy - >>
Re: TSO RENAME broke?
I'm hoping not on both accounts! If something in Roscoe breaks, we'll have to address that. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Wednesday, September 26, 2018 9:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RENAME broke? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On Wed, 26 Sep 2018 11:16:01 +, Jousma, David wrote: >Well, mystery solved. It's been broken at my installation for MANY years >(pre-dates my employment here).SYS1.CMDLIB was in LINKLST concatenation >after my favorite product (CA-Roscoe) which also has a member called RENAME. >Somehow, it never occurred to me to check this. > If you swap them, will that break Roscoe? Will anyone care? Will you need an alternate TASKLIB concatenation? "[F]avorite"? Decades ago I was delighted to abandon Roscoe in favor of TSO/SPF. SDSF made it better yet. What's a good diagnostic tool for this? ISRDDN MEMBER? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RENAME broke?
On Wed, 26 Sep 2018 11:16:01 +, Jousma, David wrote: >Well, mystery solved. It's been broken at my installation for MANY years >(pre-dates my employment here).SYS1.CMDLIB was in LINKLST concatenation >after my favorite product (CA-Roscoe) which also has a member called RENAME. >Somehow, it never occurred to me to check this. > If you swap them, will that break Roscoe? Will anyone care? Will you need an alternate TASKLIB concatenation? "[F]avorite"? Decades ago I was delighted to abandon Roscoe in favor of TSO/SPF. SDSF made it better yet. What's a good diagnostic tool for this? ISRDDN MEMBER? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECB in XMEM Post
Rob This is just a question is your comment based on the fact the ECB might be in pageable non/fixed storage and has potential for s0c4 Thanks > On Sep 26, 2018, at 9:23 AM, Rob Scott wrote: > > Both Pause/Release and PC-ss are supported in SRB mode. > > The fact that you are in recovery code (and possibly unsure of the status of > both ECB-owner and client) makes me believe that cross-memory POST is even > more undesirable. > > Not saying that it cannot be done with cross-memory POST, but Pause/Release > offers more environmental validation prior to execution and encapsulating a > PC-ss "POST" function isolates the recovery code from ECB-owner architecture > and may allow recovery code to run problem state. > > As ever in the case of things like this, it is never what you *intend* to do > that causes the problem.. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Wednesday, September 26, 2018 1:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ECB in XMEM Post > > You are right as it kills all registers besides 9 If memory serves me right I > think the for the system or PC call > > I know you are going to scream at me but the reason I choose the post is > because I’m posting This from a recovery routine as I don’t know whether it’s > TCB mode or SRB I’m using the system call I.E pc I am passing the SDWA > storage area back in the 3 byte 24 bit comp code area The 3 byte comp code > makes this convenient for me > > >> On Sep 26, 2018, at 8:11 AM, Rob Scott wrote: >> >> Please be aware that cross-memory POSTs are not ideal and if possible I >> would consider a redesign of your code to use other methods - for example : >> >> (1) Pause/Release >> (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf >> >> Just my 2c. >> >> Rob Scott >> Rocket Software >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Joseph Reichman >> Sent: Wednesday, September 26, 2018 1:01 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: ECB in XMEM Post >> >> Sorry I misunderstood >> So if Address Space A would like to post Address B the ECB must be >> addressable to to B as that is the Target the ASCB is that of the target >> Address space B the ECB can be B private area in A all I need is the address >> of the ECB even in private and ASCB of B >> >> Thanks >> >> >> On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: >> This is just another way of saying that for XMEM the ECB is in CSA right >>> ? >>> No, not right. >>> >>> What within the wording "must be addressable from the address space >>> identified by the ASCB parameter" makes you say that? Storage >>> addressable from an address space includes common storage (whether CSA >>> or SQA) and private storage of the address space. The ECB can be in >>> any of those areas. >>> >>> Peter Relson >>> z/OS Core Technology Design >>> >>> >>> -- >>> 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 >> >> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 >> ■ Main Office Toll Free Number: +1 855.577.4323 >> Contact Customer Support: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupportdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C9d76c8e06d0243b3b78e08d623aadd75%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735614108579486sdata=rG7j%2B1He%2FF8yklpcRgE3iVYMQ4B7XWkiVzlStrEPE%2FQ%3Dreserved=0 >> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferencesdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C9d76c8e06d0243b3b78e08d623aadd75%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735614108579486sdata=W1mSCHKvOe2ihbeA03r15AzqaXeUVPBiFeIAhM%2BYuCU%3Dreserved=0 >> Privacy Policy - >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policydata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C9d76c8e06d0243b3b78e08d623aadd75%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735614108579486sdata=2tCttWPQXiOLGihkj2r6j51ozO1WFPY7XOReo0EZkZk%3Dreserved=0 >> >> >> This communication and any attachments may contain confidential information >> of Rocket Software, Inc. All unauthorized use, disclosure or distribution is >> prohibited. If you are not the intended recipient, please notify Rocket >> Software
Re: ECB in XMEM Post
Both Pause/Release and PC-ss are supported in SRB mode. The fact that you are in recovery code (and possibly unsure of the status of both ECB-owner and client) makes me believe that cross-memory POST is even more undesirable. Not saying that it cannot be done with cross-memory POST, but Pause/Release offers more environmental validation prior to execution and encapsulating a PC-ss "POST" function isolates the recovery code from ECB-owner architecture and may allow recovery code to run problem state. As ever in the case of things like this, it is never what you *intend* to do that causes the problem.. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Wednesday, September 26, 2018 1:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post You are right as it kills all registers besides 9 If memory serves me right I think the for the system or PC call I know you are going to scream at me but the reason I choose the post is because I’m posting This from a recovery routine as I don’t know whether it’s TCB mode or SRB I’m using the system call I.E pc I am passing the SDWA storage area back in the 3 byte 24 bit comp code area The 3 byte comp code makes this convenient for me > On Sep 26, 2018, at 8:11 AM, Rob Scott wrote: > > Please be aware that cross-memory POSTs are not ideal and if possible I would > consider a redesign of your code to use other methods - for example : > > (1) Pause/Release > (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf > > Just my 2c. > > Rob Scott > Rocket Software > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Wednesday, September 26, 2018 1:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ECB in XMEM Post > > Sorry I misunderstood > So if Address Space A would like to post Address B the ECB must be > addressable to to B as that is the Target the ASCB is that of the target > Address space B the ECB can be B private area in A all I need is the address > of the ECB even in private and ASCB of B > > Thanks > > > On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: > >>> This is just another way of saying that for XMEM the ECB is in CSA >>> right >> ? >> No, not right. >> >> What within the wording "must be addressable from the address space >> identified by the ASCB parameter" makes you say that? Storage >> addressable from an address space includes common storage (whether CSA >> or SQA) and private storage of the address space. The ECB can be in >> any of those areas. >> >> Peter Relson >> z/OS Core Technology Design >> >> >> -- >> 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 > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ > Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupportdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C9d76c8e06d0243b3b78e08d623aadd75%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735614108579486sdata=rG7j%2B1He%2FF8yklpcRgE3iVYMQ4B7XWkiVzlStrEPE%2FQ%3Dreserved=0 > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferencesdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C9d76c8e06d0243b3b78e08d623aadd75%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735614108579486sdata=W1mSCHKvOe2ihbeA03r15AzqaXeUVPBiFeIAhM%2BYuCU%3Dreserved=0 > Privacy Policy - > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policydata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C9d76c8e06d0243b3b78e08d623aadd75%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735614108579486sdata=2tCttWPQXiOLGihkj2r6j51ozO1WFPY7XOReo0EZkZk%3Dreserved=0 > > > This communication and any attachments may contain confidential information > of Rocket Software, Inc. All unauthorized use, disclosure or distribution is > prohibited. If you are not the intended recipient, please notify Rocket > Software immediately and destroy all copies of this communication. Thank you. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECB in XMEM Post
You are right as it kills all registers besides 9 If memory serves me right I think the for the system or PC call I know you are going to scream at me but the reason I choose the post is because I’m posting This from a recovery routine as I don’t know whether it’s TCB mode or SRB I’m using the system call I.E pc I am passing the SDWA storage area back in the 3 byte 24 bit comp code area The 3 byte comp code makes this convenient for me > On Sep 26, 2018, at 8:11 AM, Rob Scott wrote: > > Please be aware that cross-memory POSTs are not ideal and if possible I would > consider a redesign of your code to use other methods - for example : > > (1) Pause/Release > (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf > > Just my 2c. > > Rob Scott > Rocket Software > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Wednesday, September 26, 2018 1:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ECB in XMEM Post > > Sorry I misunderstood > So if Address Space A would like to post Address B the ECB must be > addressable to to B as that is the Target the ASCB is that of the target > Address space B the ECB can be B private area in A all I need is the address > of the ECB even in private and ASCB of B > > Thanks > > > On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: > >>> This is just another way of saying that for XMEM the ECB is in CSA >>> right >> ? >> No, not right. >> >> What within the wording "must be addressable from the address space >> identified by the ASCB parameter" makes you say that? Storage >> addressable from an address space includes common storage (whether CSA >> or SQA) and private storage of the address space. The ECB can be in >> any of those areas. >> >> Peter Relson >> z/OS Core Technology Design >> >> >> -- >> 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 > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ > Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy > > > This communication and any attachments may contain confidential information > of Rocket Software, Inc. All unauthorized use, disclosure or distribution is > prohibited. If you are not the intended recipient, please notify Rocket > Software immediately and destroy all copies of this communication. Thank you. > > -- > 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: ECB in XMEM Post
Please be aware that cross-memory POSTs are not ideal and if possible I would consider a redesign of your code to use other methods - for example : (1) Pause/Release (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf Just my 2c. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Wednesday, September 26, 2018 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECB in XMEM Post Sorry I misunderstood So if Address Space A would like to post Address B the ECB must be addressable to to B as that is the Target the ASCB is that of the target Address space B the ECB can be B private area in A all I need is the address of the ECB even in private and ASCB of B Thanks On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: >> This is just another way of saying that for XMEM the ECB is in CSA >> right > ? > No, not right. > > What within the wording "must be addressable from the address space > identified by the ASCB parameter" makes you say that? Storage > addressable from an address space includes common storage (whether CSA > or SQA) and private storage of the address space. The ECB can be in > any of those areas. > > Peter Relson > z/OS Core Technology Design > > > -- > 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECB in XMEM Post
Sorry I misunderstood So if Address Space A would like to post Address B the ECB must be addressable to to B as that is the Target the ASCB is that of the target Address space B the ECB can be B private area in A all I need is the address of the ECB even in private and ASCB of B Thanks On Sep 26, 2018, at 7:41 AM, Peter Relson wrote: >> This is just another way of saying that for XMEM the ECB is in CSA right > ? > No, not right. > > What within the wording "must be addressable from the address space > identified by the ASCB parameter" makes you say that? Storage addressable > from an address space includes common storage (whether CSA or SQA) and > private storage of the address space. The ECB can be in any of those > areas. > > Peter Relson > z/OS Core Technology Design > > > -- > 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: ECB in XMEM Post
>This is just another way of saying that for XMEM the ECB is in CSA right ? No, not right. What within the wording "must be addressable from the address space identified by the ASCB parameter" makes you say that? Storage addressable from an address space includes common storage (whether CSA or SQA) and private storage of the address space. The ECB can be in any of those areas. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RENAME broke?
Well, mystery solved. It's been broken at my installation for MANY years (pre-dates my employment here).SYS1.CMDLIB was in LINKLST concatenation after my favorite product (CA-Roscoe) which also has a member called RENAME. Somehow, it never occurred to me to check this. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Tuesday, September 25, 2018 3:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: TSO RENAME broke? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Anyone use TSO rename anymore? Just tried it. Don't get any errors, but it doesn't do it either. Tried in batch, and get a RC8 but no messages. Tried in ispf option 6, READY prompt, nothing different. Can't say I've used it in years, so maybe its been retired? We are at V2.3 FYI. _ Dave Jousma Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM options for dataset back-up
Dave, You had a similar thread on a variation of this topic in May of 2010. History repeating itself? :-) Open a PMR/SR to DFSMShsm development. I could not find a specific PATCH example matching your need in any of the usual manuals containing PATCH criteria. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Tuesday, September 25, 2018 7:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM options for dataset back-up I will RTFM, but don't feel like starting there. For many historical (some hysterical) we run both DFHSM and FDRABR against our SMS managed disk. FDRABR does full-volume and incremental back-ups. DFHSM is just dataset back-up. Bad experience with DFHSM DUMP a couple decades ago. We use the FDRABR option UPDATEFLAG=NOCHANGE so DFHSM will back-up (and maybe migrate) the datasets. Which means I must run FDRABR first. Does DFHSM have a similar option (PATCH or FIXCDS) to not set the change bit? I'd like to switch the order (well, I already did and it isn't good) of processing. Dave Gibney Information Technology Services Washington State University -- 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: ECB in XMEM Post
Thanks Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Sep 26, 2018, at 3:46 AM, Binyamin Dissen > wrote: > > No, it means unlike the MF=E list, the ecb itself must be addressable from the > target address space, not the POSTers primary. > > On Tue, 25 Sep 2018 19:49:54 -0400 Joseph Reichman > wrote: > > :>Hi > :> > :> > :> > :>In XMEM Post bases on the fact that's ASC is Primary and in the control > :>parameters specify "If the caller specifies the ASCB parameter, the event > :>control block (ECB) must be addressable from the address space > :> > :>identified by the ASCB parameter. " > :> > :> > :> > :> > :> > :>This is just another way of saying that for XMEM The ECB is in CSA right ? > :> > :> > :>-- > :>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. > > -- > 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: ECB in XMEM Post
No, it means unlike the MF=E list, the ecb itself must be addressable from the target address space, not the POSTers primary. On Tue, 25 Sep 2018 19:49:54 -0400 Joseph Reichman wrote: :>Hi :> :> :> :>In XMEM Post bases on the fact that's ASC is Primary and in the control :>parameters specify "If the caller specifies the ASCB parameter, the event :>control block (ECB) must be addressable from the address space :> :>identified by the ASCB parameter. " :> :> :> :> :> :>This is just another way of saying that for XMEM The ECB is in CSA right ? :> :> :>-- :>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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Master cats as user cats on other systems - why?
I think the op might really be trying to decide if it's "better" to have a single MCAT for the site and thus have the same view of "everything" or if having individual MCATs for each LPAR and then sharing them as UCATs with the "other" LPARs is better. I have operated both ways and I really don't see a "super" benefit in one method over the other that gives it something "more" than the other way, I think that there are sites that have a philosophy of one MCAT for the site and some that feel that each LPAR "needs" it's own MCAT. As for why they are shared, if you have multiple MCATs (one per LPAR) and you want to be able to access data that is in MCAT-1 (on LPAR-1) from a system that is using MCAT-2 (on LPAR-2) as it's MCAT, then you need to make sure that MCAT-1 is available to LPAR-2 and since you can't use STEPCAT and/or JOBCAT (any more) it's much simpler to define MCAT-1 as a usercatalog of MCAT-2 (and MCAT-2 as a usercatalog of MCAT-1). I find that it's easy to get confused if you aren't careful in a multiple MCAT system, and it's simple to overdo it with symbolics whether you have a single MCAT or multiple MCATs, but that doesn't make multiple MCAT's any less useful than a single MCAT, just different. With all of the things that IBM forces on us with z/OS, allowing you to have a "choice" once it a while is (to me) a good thing. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
