Re: CPACF for TN3270 encryption
there is a relatively new red piece on how to configure TLS with tn3270: IBM z/OS IBM Personal Communications TTLS Enablement at http://www.redbooks.ibm.com/redpapers/pdfs/redp5538.pdf ITschak On Sat, Nov 9, 2019 at 4:08 AM Greg Boyd wrote: > System SSL (aka TLS) will work without ICSF being active and without CEX > cards being available. You may not like the performance and some functions > (i.e. specifically ECC) may not work. Elliptic Curve (ECC) requires that > CEX cards are available and ICSF is active, to drive those operations to > the card. > > Keep in mind that TLS (and System SSL) have two phases: > > The handshake phase performs authentication and requires public/private > keys which relies on either CEX cards or software routines. A low number > of handshakes per second can be handled in software, but if you have any > volume, having the cards can provide a significant savings in MIPS as well > as helping performance. Handshakes also do some hashing, which is done on > the CPACF (ICSF is not required on the latest versions of z/OS). > > The record phase uses symmetric encryption to protect the data and hashing > for integrity. The symmetric encryption is done on the CPACF, if you are > using DES/TDES or AES (if that is what is negotiated). Long ago, ICSF had > to be active to do AES, if you were running on a machine that didn't > support AES on the CPACF hardware ... circa z/890 and z990. But ICSF is > not required on the latest versions of z/OS, System SSL uses the native > crypto instructions on the CPACF. Hashing for the record phase is also > done on the CPACF (no ICSF required, on current versions of z/OS) if you > are using SHA-1, SHA-2. > > Greg Boyd > Mainframe Crypto > www.mainframecrypto.com > > > On Fri, 8 Nov 2019 01:05:42 -0600, Barbara Nitz wrote: > > >> Do we need ICSF to be running while implementing ATTLS ? > >I ran AT-TLS on a 2.1 RDT system *without* ICSF without a problem. And it > was for more than just TN3270 traffic at TLS 1.2. I haven't tried at a > higher z/OS level, but I don't think you need ICSF. > > > >Regards, Barbara > > > >-- > >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 > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES NOTIFY EMAIL=
On Fri, 8 Nov 2019 09:35:43 -0600, Carmen Vitullo wrote: >David I feel your pain, we are also a TSS shop, CA (BROADCOM) has some good >doc on converting RACF to TSS, if you need I'll see if I can get the link to >you. > >my previous reply to Brian never was posted, > >agree, and what I do not understand, is the freebee software like JES2MAIL and >other paid products work well, access our SMTP passthru server with no issues, >this is not just a JES2EDS issue, but a normal notification issue from z/OSMF, >I can sent email's from OPS, from JCL batch, no issues, using the same >configuration, I'm trying to get ahead of the game and setup all the parts >pieces for z/OSMF, I suspect the notification, once we're are forced to us >this POC, will be very important. >another trace yesterday sent to level 2, SEV2 ticket still open since Aug 27th >:( > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Yes, the problem with the new JES mail option isn't getting CSSMTP to work with it, you will likely find that you missed one of the install steps or misinterpreted the results like I did (3 times). I ended up going through the entire install 4 times before I got it "right" thinking that everything was fine each time and it turned out that while the steps all seemed to have worked, checking the content of the issued messages themselves pointed to the problem I had with the izudflt.zosmf.notification.notify part. It turned out that no one (except zosmf itself) was authorized to send the email. :( But even when it was done and completely implemented, it wasn't even as nice as the stuff you can get off the freeware tapes. It is a particular pain to have to actually add the notify card to the jobs. I think there are several better ways that it could have been handled and it could have been much more comprehensively implemented. While it doesn't "suck" per se, it's not really worth the enormous effort for such a small "feature". If you already are running z/OSMF, then adding it is not going to really be a big deal, but I don't see any part of it which is worth the effort to implement (and actually run since z/OSMF is installed for you at serverpak now), all of z/OSMF just to get the notify part. I just keep falling back to the fact that if you don't make something simple and easy to use, that most people just won't bother to use it, at least not when it counts. We made SyzMPF/z and SyzMAIL/z so that normal installation is on the order of 10 minutes or less. I can't imagine what they were thinking when they decided to design the notify feature of z/OSMF but I'm thinking that it wasn't ease of implementation or use. :) Brian Westerman Syzygy Incorporated www.SyzygyInc.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Worse, I can't find the general description that existed way back when about R15-R1 being transient. If it's still there, it's not in the obvious location. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Saturday, November 9, 2019 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO On Sat, 9 Nov 2019 at 15:07, Seymour J Metz wrote: > > I would assume that any system macro destroys R15-R1 unless the documentation > says otherwise. In the case of WTO, the documentation decribes the use of all > three registers. For that matter, the documentation mentions the use of > AR14-AR1. Yes it's documented and legit, but it's a change in behaviour over the last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15, and STORAGE OBTAIN did not change the high half of R1. 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: WTO
On Sat, 9 Nov 2019 at 15:07, Seymour J Metz wrote: > > I would assume that any system macro destroys R15-R1 unless the documentation > says otherwise. In the case of WTO, the documentation decribes the use of all > three registers. For that matter, the documentation mentions the use of > AR14-AR1. Yes it's documented and legit, but it's a change in behaviour over the last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15, and STORAGE OBTAIN did not change the high half of R1. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
A WTO will use R1 as a parameter register. If you need the value in 1 prior to the WTO then you must sae and restore it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Friday, November 8, 2019 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: WTO All: I have a bit of an issue I am trying to resolve in Assembler. We use a skeleton exit from another vendor and it has been working fine. It is re-entrant and keep seeing normal WTO's , i.e. ; WTO 'X',ROUTCDE=11 , are not appearing on SYSLOG. We are using the WTOS to track through the flow of the exit. Could what i am seeing the exit being re-entrant and since WTO's use R1 that R1 is being destroyed by some task ?? Scott -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” http://secure-web.cisco.com/1MCsm5P9uz16YQS78luElxkTOhJhtMu3q1EZbyhOzrthTh9gpAdZFw8zEL9fYZBDZm0rUwmeLAVsDAIQ0_z6c_ZeBvgW8vV0nugIaoxbpf3w6kzVvoMkSZaw1mB0aneC6w5SvDYOZgj4H7YHsmY2gDz42oyQyJZDy8UUH0aWYcFkPKJVzFMQTmqJon_SU9bR5AUp8a3BYuKumFFoWqZhwuWELFbQIK-GRWDUm0r1h98dDtgwckkf0agIoqpF1OQ8sz-DFW6CLoDpu0dtEhonN60bGOSXGgAWdk05Fu5prOyt5sQ7mQCAXZpOr1vhrcxtnoYpSPCZHyU2e5zY9GzkAGaZttyfXNWAnS-ULzVlB2BwSQ1HIDJMCZ9kfZMTp4RaplQrOwXPEY3DFw-X2UWmMnPWrwytIrr4dqBImLcI1WwZAkVni3LuIsaPasHLZvvsW/http%3A%2F%2Fwww.idmworks.com scott.f...@idmworks.com Blog: http://secure-web.cisco.com/17JpeUfrLYdjT1N7uv37Nzg7XiwnFw-G0ByYcmNMwEDo-LlyRnUhFWWjQVtcFL4F4vSHzWmyvCzIzqS6wtw2KhMFMaYr7RAH9iC4A_5rLQpyFZLKM8el_tOS4CIUGBcxgxkK7GVcObDogl1JiYo_bP6Z9bsnpzj3uVENtHkF0dHhjtWULOKaKf-WFUZ0zOuX2YqCUJ08RrrSGhavMjwmcxyBO4wdshJZNXdD19VyKj8Jst7to8U6pvBaJLtz_RWiTpIr-XdzNB9WFjtPCVQb40XXgB7TukparmuxLzDaSXDf_8YC56UZIO3YjAfgmb8KcQoyZYJdcYgxL5o6nwEzO9kKF3tDQcSMTEgiZTaun3VCB6TdN-P0MBhnApwXy4ygU39Y5Bpkp-X8sG-h06yGJV7TOSYjynGE0Gzq-v5DXrlLqdOs73ebt4Ur-zyjkEqzs/http%3A%2F%2Fwww.idmworks.com%2Fblog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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: WTO
I would assume that any system macro destroys R15-R1 unless the documentation says otherwise. In the case of WTO, the documentation decribes the use of all three registers. For that matter, the documentation mentions the use of AR14-AR1. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Rupert Reynolds Sent: Friday, November 8, 2019 4:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO Perhaps I misunderstood, but it seems more likely that WTO has changed registers and affected the processing of the exit. Obvious candidates are condition code and regs 0,1,15 (I can't remember whether R0 is used). Are you using MF=(E, PARMLIST)? Time for a test module to run the edit where you can debug it interactively? Rupert On Fri, 8 Nov 2019, 20:29 scott Ford, wrote: > All: > > I have a bit of an issue I am trying to resolve in Assembler. We use a > skeleton exit from another vendor and it has been working fine. > It is re-entrant and keep seeing normal WTO's , i.e. ; WTO > 'X',ROUTCDE=11 , are not appearing on SYSLOG. We are using the > WTOS to track through the flow of the exit. Could what i am seeing the exit > being re-entrant and since WTO's use R1 that R1 is being destroyed by > some task ?? > > Scott > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > http://secure-web.cisco.com/1Y9RGaDY1lsLpqlnmCd7fGFWlUeTiPSkPZXtT9huDbeYCLBl8qMZQT97ZjLxkcVVk3AaNwyepCDPRRusSgTEzgnu-6gH_bXJ_rvDvdTYK7H69eNj_uO7PRbR-yLOZVd1hmPrz00usZHuuO9iCZX_nhbXEYYW4XWkwZAy0szI3GsS12MRg2URPkSqdAjIZamDP3OidQQgoy5uQ5lOX4FbzIHkJ_nk4iJoROihx-8C1r08djM0F60rzJz_gDueGTdlmtlh6BmcE0QU2sxiS3H9Ejni_1MyfA9aCpMDeSSPZYGvlSUXnShvDOWGQsfMlw7hD68mKISFnNvQ77n6VGC2RgmxUC9PpAqmZ2NTfBHsR8Du741Nzsvryq61Ezm2LId8-OysS-sdKqrP8VJRLtHiICmlQoYjsUULdpD9pdHJIwLRk7T6T71_9L_HZSLCDB8j7/http%3A%2F%2Fwww.idmworks.com > > scott.f...@idmworks.com > > Blog: > http://secure-web.cisco.com/1Fv8GdSDGaZNUpBv4m3tDHWdxoG9YP7DuVfUqWRhCyIwEqYOeeOBGhFaN30l7w8qYj4l_tSXfBoemX8byFyPw6mJMM5eSHyNd8Kyg1aT-je4lCDxhHsvCfWeDDGJAAn4b8TtTSpxgmTEFO_J_hKLayHC_AcZh8SXhtTByGQJH39oRxAAogbkJkEu_ny9LvqFiTMDjxqKlKqHmkuqk11b-4pRDZNR6bkgTV2mgNa547-8nfOUsJi6ZDu2ejBTFWP89SiTcHO88iqE11O0NPRvQ3YeO_9hy-JLNyrKwADD47eiBjLdOMzKBSJaS7UPKxi-mLyx-P1kEgF2qrjinFtszso3hhShrscrO0HqJmZtOqkBvs8wkewQ-aBR0I5PdqYVsT7aW4Mi-JyrNSpujnnhJjHJtcOr1GsyoRuubPGM_TkZhrQSHDjB7rfguvF8_5ZqG/http%3A%2F%2Fwww.idmworks.com%2Fblog > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from > disclosure. If the reader of this message is not the intended recipient, > you are hereby notified that any dissemination, distribution, copying or > use of this message and any attachment is strictly prohibited. If you have > received this message in error, please notify us immediately by replying to > the message and permanently delete it from your computer and destroy any > printout thereof.* > > -- > 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: WTO
Charles, I will have to try MCSFLAG= HRDCPY .. On Sat, Nov 9, 2019 at 11:18 AM Steve Smith wrote: > iirc (it was decades ago), WTL drops the exact text into the log. None of > the ~80 bytes of timestamp, flags, job ID, etc. is prefixed. So, WTO is > better in that you do get all that. > > If WTL suits the purpose though, I don't see much harm in using it. > However, if you have any log post-processing, you should check to see if > it's going to gag on your non-standard messages. > > sas > > On Sat, Nov 9, 2019 at 10:27 AM Jeremy Nicoll < > jn.ls.mfrm...@letterboxes.org> > wrote: > > > On Sat, 9 Nov 2019, at 15:14, Charles Mills wrote: > > > Possibly because AT LEAST since z/OS 1.10 (and I think long before > that) > > IBM > > > has been saying > > > > > > Note: IBM recommends you use the WTO macro with the MCSFLAG=HRDCPY > > parameter > > > instead of WTL, because WTO supplies more data than WTL. > > > > What does that mean? Surely in both cases the data is what the > programmer > > elects to send? > > > > I'd have thought there'd be advantages in not sending log data through > > message processing. > > > > -- > > Jeremy Nicoll - my opinions are my own. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > sas > > -- > 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: BPXWUNIX Improvements
On Sat, 9 Nov 2019 14:13:31 +0800, David Crayford wrote: >... >> If that's the UNIX/shell command "env", use some caution because its >> output may not have metacharacters in variable values properly quoted. >> "export -p" does better. > >Do you have an example of "env" with the meta-characters issue? > >Maybe "printenv" would be better as it only has one purpose. The trouble >with "export -p" is that the output needs to be parsed and reformatted >before it can be used in a environment variable stem. > Consider: ( set -x; export wombat="foobar xyzzy=barfoo"; env; export -p; printenv ) | grep foo wombat=foobar xyzzy=barfoo export wombat="foobar xyzzy=barfoo" wombat=foobar xyzzy=barfoo ... none of them produces Rexx-friendly output, and only "export -p" produces sh-friendly. Yes, I'm wearing my Black Team cloak. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
iirc (it was decades ago), WTL drops the exact text into the log. None of the ~80 bytes of timestamp, flags, job ID, etc. is prefixed. So, WTO is better in that you do get all that. If WTL suits the purpose though, I don't see much harm in using it. However, if you have any log post-processing, you should check to see if it's going to gag on your non-standard messages. sas On Sat, Nov 9, 2019 at 10:27 AM Jeremy Nicoll wrote: > On Sat, 9 Nov 2019, at 15:14, Charles Mills wrote: > > Possibly because AT LEAST since z/OS 1.10 (and I think long before that) > IBM > > has been saying > > > > Note: IBM recommends you use the WTO macro with the MCSFLAG=HRDCPY > parameter > > instead of WTL, because WTO supplies more data than WTL. > > What does that mean? Surely in both cases the data is what the programmer > elects to send? > > I'd have thought there'd be advantages in not sending log data through > message processing. > > -- > Jeremy Nicoll - my opinions are my own. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Sat, 9 Nov 2019, at 15:14, Charles Mills wrote: > Possibly because AT LEAST since z/OS 1.10 (and I think long before that) IBM > has been saying > > Note: IBM recommends you use the WTO macro with the MCSFLAG=HRDCPY parameter > instead of WTL, because WTO supplies more data than WTL. What does that mean? Surely in both cases the data is what the programmer elects to send? I'd have thought there'd be advantages in not sending log data through message processing. -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Possibly because AT LEAST since z/OS 1.10 (and I think long before that) IBM has been saying Note: IBM recommends you use the WTO macro with the MCSFLAG=HRDCPY parameter instead of WTL, because WTO supplies more data than WTL. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeremy Nicoll Sent: Saturday, November 9, 2019 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO On Sat, 9 Nov 2019, at 13:26, Peter Relson wrote: > But of course you can configure your system to have even those messages > sent to syslog. I wonder why the OP isn't using WTL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Sat, 9 Nov 2019, at 13:26, Peter Relson wrote: > But of course you can configure your system to have even those messages > sent to syslog. I wonder why the OP isn't using WTL. -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
ROUTCDE 11 is commonly thought of as "write to programmer". It is generally intended not to go to the SYSLOG -- the WTO is providing information to the job, not the system. But of course you can configure your system to have even those messages sent to syslog. 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
