Re: LzLabs
Just one county, Germany. 1400KM, 12 hours drive. On Sun, May 3, 2020 at 2:48 AM Tom Brennan wrote: > > Sounds great!! I'm sure I would have loved the country - I just wasn't > too keen on the company's product. By coincidence, my wife came by my > desk this morning and asked if Switzerland is far from Denmark, so she's > got something in the early planning stages. Probably for after the > vaccine is available, I would hope. > > On 5/2/2020 6:47 PM, scott Ford wrote: > > Tom, > > > > I got to Switzerland due to a job phase out in NYC. It was an overall great > > experience. > > > > Scott > > > > On Sat, May 2, 2020 at 9:38 PM Tom Brennan > > wrote: > > > >> Years ago I was offered a trip to Zurich (both me and my wife) to check > >> things out. I said no thank you. My wife was upset :) > >> > >> On 5/1/2020 3:59 AM, David Crayford wrote: > >>> I used to work with the guy that was the tech lead for the LzLabs CICS > >>> project. He tried to recruit some of us! > >> > >> -- > >> 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LzLabs
I loved the vacations, I had 5 weeks , man ..Denmark would also be nice. I saw France, Belgium, Italy, Netherlands and the U.K. working in several. Scott On Sat, May 2, 2020 at 10:48 PM Tom Brennan wrote: > Sounds great!! I'm sure I would have loved the country - I just wasn't > too keen on the company's product. By coincidence, my wife came by my > desk this morning and asked if Switzerland is far from Denmark, so she's > got something in the early planning stages. Probably for after the > vaccine is available, I would hope. > > On 5/2/2020 6:47 PM, scott Ford wrote: > > Tom, > > > > I got to Switzerland due to a job phase out in NYC. It was an overall > great > > experience. > > > > Scott > > > > On Sat, May 2, 2020 at 9:38 PM Tom Brennan > > wrote: > > > >> Years ago I was offered a trip to Zurich (both me and my wife) to check > >> things out. I said no thank you. My wife was upset :) > >> > >> On 5/1/2020 3:59 AM, David Crayford wrote: > >>> I used to work with the guy that was the tech lead for the LzLabs CICS > >>> project. He tried to recruit some of us! > >> > >> -- > >> 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
Re: LzLabs
Sounds great!! I'm sure I would have loved the country - I just wasn't too keen on the company's product. By coincidence, my wife came by my desk this morning and asked if Switzerland is far from Denmark, so she's got something in the early planning stages. Probably for after the vaccine is available, I would hope. On 5/2/2020 6:47 PM, scott Ford wrote: Tom, I got to Switzerland due to a job phase out in NYC. It was an overall great experience. Scott On Sat, May 2, 2020 at 9:38 PM Tom Brennan wrote: Years ago I was offered a trip to Zurich (both me and my wife) to check things out. I said no thank you. My wife was upset :) On 5/1/2020 3:59 AM, David Crayford wrote: I used to work with the guy that was the tech lead for the LzLabs CICS project. He tried to recruit some of us! -- 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: IEALIMIT Linkedit Example?
Not sure how this played out. In a previous life, we replaced IEALIMIT with USILIMIT when XA arrived. USILIMIT can control more areas of storage than USILIMIT. If both exits are present, USILIMIT takes precedence. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Thursday, March 19, 2020 10:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):IEALIMIT Linkedit Example? CAUTION EXTERNAL EMAIL Does anyone have an example JCL to link IEALIMIT into the nucleus? Im trying to determine if we’ve done that. I see an IEALIMIT module in IEANUC01 but it’s size is different (72 bytes). I suspect it’s the IBM default. But want to be sure. -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LzLabs
Tom, I got to Switzerland due to a job phase out in NYC. It was an overall great experience. Scott On Sat, May 2, 2020 at 9:38 PM Tom Brennan wrote: > Years ago I was offered a trip to Zurich (both me and my wife) to check > things out. I said no thank you. My wife was upset :) > > On 5/1/2020 3:59 AM, David Crayford wrote: > > I used to work with the guy that was the tech lead for the LzLabs CICS > > project. He tried to recruit some of us! > > -- > 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: LzLabs
Years ago I was offered a trip to Zurich (both me and my wife) to check things out. I said no thank you. My wife was upset :) On 5/1/2020 3:59 AM, David Crayford wrote: I used to work with the guy that was the tech lead for the LzLabs CICS project. He tried to recruit some of us! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: it was 20 years ago today ....
I don't agree that COVID-19 is more far reaching; if, e.g., the financial institutions, railroads, did not ultimately address their Y2K issues, it would have been grim. Likewise manufacturing relying on JIT inventory. But I was never concerned with, e.g., power generation, heavy manufacturing. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jesse 1 Robinson [jesse1.robin...@sce.com] Sent: Saturday, May 2, 2020 2:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: it was 20 years ago today (Old post) I don't have any citations, but some of the most notorious doomsters recanted their gloomy predictions well BEFORE January 2000. They presumably sold a lot of $19.99 books in the meantime. I doubt that Tom received an offer of refund. So how did we dodge the Y2K asteroid? I can testify from personal witness that we worked our *sses off and coincidentally spent tons of money. Catastrophe did not just happen to miss us. We took heroic evasive maneuvers. Fast forward to today. We're currently mired in a crisis even farther-reaching than Y2K. The question is increasingly asked: what will the 'new normal' look like once we're back to whatever? No predictions from me, but we can observe some changes in pre-2000 IT. A lot of the aforementioned Y2K spend was directed at and justified by replacing old hardware and software. I joined SCE in 1994. By early in the new century, not a single piece of mainframe hardware on the floor in the md-90s remained in use. All replaced by more modern gear or in some cases by changes in the way we did business. These changes were accomplished not so much by futuristic strategic planning as by the looming threat of jail time for corporate executives who failed to board the boat. Coercion at its sweetest. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Thursday, January 2, 2020 6:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: it was 20 years ago today > In the 90s Stewart Alsop famously predicted the end of the world. I just checked my old book collection and found "Time Bomb 2000" by Edward and Jennifer Yourdon. On the back it has questions like, Will your car run?, Will there be food?, Will your PC work? ... Yep, I fell for it. Marked $19.99 - I hope I got a really good discount. On 1/2/2020 4:18 PM, Jesse 1 Robinson wrote: > I heard a 'Y2K person' interviewed on NPR recently. Her point was that if the > IT industry had done nothing in advance to remediate, we would have had utter > chaos on 1/1/2000. But we did prepare. We undoubtedly overprepared, but by > how much will forever remain a mystery. > > In the 90s Stewart Alsop famously predicted the end of the world. He > retreated well before the event itself. We all buy insurance that we're > thrilled not to utilize. That doesn't make it a waste. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com -- 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: BPXBATSL and message "FSUM1007 Unable to open the message catalog"
I hit this recently too. As Seymour says, check your OMVS segment and any mandatory setup files that may be missing, or permissions. I'm not able to access our system but I did get this problem while installing and setting up RRSF and the PAGENT started task. Pretty annoying too, Google was no help. On Sun, May 3, 2020 at 10:37 AM Seymour J Metz wrote: > What's in your OMVS segment? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Steve Bagshaw [steve.bags...@itmetrics.com] > Sent: Saturday, May 2, 2020 8:21 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: BPXBATSL and message "FSUM1007 Unable to open the message catalog" > > Hi z/OS guys > > Does anyone know why I might be getting this message when I try and > execute the BPXBATSL TSO command? > > " > FSUM1007 Unable to open the message catalog. > FSUM1009 Unable to execute the shell. > " > > The IBM manual simply says: > " > Explanation > The message catalog cannot be opened. Processing continues. > > System programmer response > Verify that the message catalog exists in the file system. > > User response > Contact the system programmer. > " > > I am a very experienced z/OS Systems Programmer (65+) but have never seen > this message before and am not sure what "message catalog" is being > referred to here. > > I my case the SH is not executed and I get no output in > //STDOUT, only these above messages in //STDERR. > > Any and all help will be much appreciated :-) > > Cheers > Steve > > -- > 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 > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LzLabs
They are all the same, but it hardly qualifies as bait-and-switch. When has IBM denied that they were market segmentation? As for the 9370, you'd have to look at the CE manuals to be sure, although I'm inclined to doubt it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wayne Bickerdike [wayn...@gmail.com] Sent: Saturday, May 2, 2020 12:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LzLabs It's interesting that a zIIP can be described as a "speciality" engine yet the workload they run also run on a CP engine. I thought that they are the same basically and it's just another way to sell a piece of kit and play bait and switch on pricing. Years ago we had a 9370 and a company in Melbourne we had some support from ran an AS400. Their chief was convinced that the only difference was microcode (and price!). On Sat, May 2, 2020 at 1:28 PM Mike Schwab wrote: > > https://secure-web.cisco.com/1UsdeLcKDKStyHiH_Q4LZd0MutA814SVSnsZ5fust_HQ6mgBRHukeaRwGKqPI6-xol4K2RbcSj-1PSUNzQaTUkJC79hPQiozXeV-9be8V-rFkbT8-HtUkwPOOZ2-KsfXQoJJVLmasiNXtn4YA0YNaPM-_jjQ4B0sMhZlqxc5Een6LUKpK2D2r0ncu-dTSbNpJH0O4ZtuO20WGXS49i97O_vwi3Dsq-WsVvEdPDY0xk7j1JOKRIK03Q2hMITjXejjfMFw4NzR1IILSyMcNM2DBtsvvnjGaUfQznOxIOYY7xGo9HYsXMb-GCXs8IAjNDZX8IxW9KYSsUXA_94RoNK3UhqZeCFBESUHBPx9HKsEIR0q4QmZ_8kOqsBGkkW9xxLApEkQYftJebx0CZlLOvIRBOqiwkkpaGgZYD2EElMFE8eQ8K0LPArzEsvQOUu8gCGWl/https%3A%2F%2Fwww.eweek.com%2Fnetworking%2Fneon-settles-mainframe-software-lawsuit-with-ibm > > On Sat, May 2, 2020 at 3:18 AM Steve Beaver wrote: > > > > Actually they Did in Europe. European courts sided with Neon > > > > Sent from my iPhone > > > > > On May 1, 2020, at 22:07, Steve Smith wrote: > > > > > > No. Neon was a software company. They sold a product called zPrime > that > > > allowed unauthorized usage of zIIP and zAAP for almost any kind of > > > workload. IBM already runs much of DB2 on zIIP. > > > > > > IBM only allows code to run on zIIP when you have specific contracts > that > > > allow you to for specific things. Neon either violated those, or more > > > likely reverse-engineered it, which is almost certainly a violation of > some > > > other contract they were bound to. > > > > > > I don't know any details, but it's hard for me to see how that Neon > thought > > > they were going to get away with it. > > > > > > sas > > > > > > > > >> On Fri, May 1, 2020 at 8:42 PM Mike Schwab > wrote: > > >> > > >> Neon was a product to run some DB2 on zAAPs or zIIPs. Only the > > >> workload specified by IBM could run on those processors. > > >> > > >>> On Fri, May 1, 2020 at 5:45 PM Peter Baumann > wrote: > > >>> > > >>> In a lawsuit against Neon Enterprise (John Moores) the court ruled in > > >> favor of IBM. They had to take zPrime out of the market. There was > also a > > >> permanent injunction issued against Neon. > > >>> > > >> > > > > > > -- > > > 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 > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- 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: Mainframe user ID length
> You can specify pretty much anything you want in JCL. According to MVS JCL Reference, SA23-1385-40, both USER=abcdefghi and EMAIL=foo+...@patriot.net are illegal. That's not a JES issue. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Saturday, May 2, 2020 2:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on screen. >...Even if I've logged on from some other OS using a longer ID, >inside z/OS the system is still using an 8-byte ID. But "who cares?" Users presenting longer IDs or client certificates certainly don't. "If a tree falls in the woods" As long as there is at least adequate granularity in providing enough different security contexts it shouldn't particularly matter. For all we know (and I don't know) RACF already does something internally that has more breadth than maximum 8 character TSO/E user IDs would ordinarily suggest. Analogously, does it matter much that Microsoft Windows still only supports a
Re: LzLabs
360/44, 360/75, 360/95 and 360/195 were the only shipped S/360 models to be hard wired. The 360/44 wasn't a full S/360 but there was a feature for simulating the missing instructions in bump storage. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Schwab [mike.a.sch...@gmail.com] Sent: Saturday, May 2, 2020 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LzLabs Yep. They drop the interrupt handling in zIIPs and zAAPs to get full speed processing. Could have checked the chips on the boards. Most S/360 models had some microcode, only the highest model had all instructions in hardware. On Sat, May 2, 2020 at 4:58 AM Wayne Bickerdike wrote: > > It's interesting that a zIIP can be described as a "speciality" engine yet > the workload they run also run on a CP engine. > > I thought that they are the same basically and it's just another way to > sell a piece of kit and play bait and switch on pricing. > > Years ago we had a 9370 and a company in Melbourne we had some support from > ran an AS400. Their chief was convinced that the only difference was > microcode (and price!). > > > > > > On Sat, May 2, 2020 at 1:28 PM Mike Schwab wrote: > > > > > https://secure-web.cisco.com/1rR_dVgql8YSALoeyuf7ezcu9s1nlFAZyNS1Tk40yYGsfNW_QHjlyFLUEXqPwd5xpgWkK9dALsHZZpeAD-83O92yCnID8zfocAxbICK4xv6kbhJp4OQRdCUCqH4raKSeyat1qSfuGHXoyYJDbV0fbbu5gvmXL67i7fEnidt_j8jWVrk-sBYOOw2CICfxSCyG8DN_yA8VKlKjkPAYcUZB8_13txRX6E3xnEBmZiDZqrhUlJTI6g0PV1AgvOybajYj7Y8XjHxpCbQg1PnPXIvllEXLuhuT6Zjb8i_6IKNCe72XHYE_R9DdxefR6Zv_D_To-m7IFswfcvffjs7sd2LfUvn9faT21Fv0bHK0MMGGUcuXCZicKkim5E6kvCQpVEfitbAwK-XT8jEq-Q1G83znmWYP5d0gw2MCbxQeoNir3YNIn6NLQ13jN7GSdz8wsdU8v/https%3A%2F%2Fwww.eweek.com%2Fnetworking%2Fneon-settles-mainframe-software-lawsuit-with-ibm > > > > On Sat, May 2, 2020 at 3:18 AM Steve Beaver wrote: > > > > > > Actually they Did in Europe. European courts sided with Neon > > > > > > Sent from my iPhone > > > > > > > On May 1, 2020, at 22:07, Steve Smith wrote: > > > > > > > > No. Neon was a software company. They sold a product called zPrime > > that > > > > allowed unauthorized usage of zIIP and zAAP for almost any kind of > > > > workload. IBM already runs much of DB2 on zIIP. > > > > > > > > IBM only allows code to run on zIIP when you have specific contracts > > that > > > > allow you to for specific things. Neon either violated those, or more > > > > likely reverse-engineered it, which is almost certainly a violation of > > some > > > > other contract they were bound to. > > > > > > > > I don't know any details, but it's hard for me to see how that Neon > > thought > > > > they were going to get away with it. > > > > > > > > sas > > > > > > > > > > > >> On Fri, May 1, 2020 at 8:42 PM Mike Schwab > > wrote: > > > >> > > > >> Neon was a product to run some DB2 on zAAPs or zIIPs. Only the > > > >> workload specified by IBM could run on those processors. > > > >> > > > >>> On Fri, May 1, 2020 at 5:45 PM Peter Baumann > > wrote: > > > >>> > > > >>> In a lawsuit against Neon Enterprise (John Moores) the court ruled in > > > >> favor of IBM. They had to take zPrime out of the market. There was > > also a > > > >> permanent injunction issued against Neon. > > > >>> > > > >> > > > > > > > > -- > > > > 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 > > > > > > > > -- > > Mike A Schwab, Springfield IL USA > > Where do Forest Rangers go to get away from it all? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Wayne V. Bickerdike > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXBATSL and message "FSUM1007 Unable to open the message catalog"
What's in your OMVS segment? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Bagshaw [steve.bags...@itmetrics.com] Sent: Saturday, May 2, 2020 8:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BPXBATSL and message "FSUM1007 Unable to open the message catalog" Hi z/OS guys Does anyone know why I might be getting this message when I try and execute the BPXBATSL TSO command? " FSUM1007 Unable to open the message catalog. FSUM1009 Unable to execute the shell. " The IBM manual simply says: " Explanation The message catalog cannot be opened. Processing continues. System programmer response Verify that the message catalog exists in the file system. User response Contact the system programmer. " I am a very experienced z/OS Systems Programmer (65+) but have never seen this message before and am not sure what "message catalog" is being referred to here. I my case the SH is not executed and I get no output in //STDOUT, only these above messages in //STDERR. Any and all help will be much appreciated :-) Cheers Steve -- 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
BPXBATSL and message "FSUM1007 Unable to open the message catalog"
Hi z/OS guys Does anyone know why I might be getting this message when I try and execute the BPXBATSL TSO command? " FSUM1007 Unable to open the message catalog. FSUM1009 Unable to execute the shell. " The IBM manual simply says: " Explanation The message catalog cannot be opened. Processing continues. System programmer response Verify that the message catalog exists in the file system. User response Contact the system programmer. " I am a very experienced z/OS Systems Programmer (65+) but have never seen this message before and am not sure what "message catalog" is being referred to here. I my case the SH is not executed and I get no output in //STDOUT, only these above messages in //STDERR. Any and all help will be much appreciated :-) Cheers Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
Wow, thanks Mark. this is great. From: IBM Mainframe Discussion List on behalf of Mark A. Brooks Sent: Saturday, May 2, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. So you have only one signal structure per transport class? If your traffic is like most, the small traffic is an order of magnitude more than any other size, and it's all flowing to the same place. Each target system will have a unique list, so you get some distribution from that. But if you have high signals/sec to a given target, you may be getting some latch contention within the CF (but it all depends). Fussing with the transport class definitions will not help. If all else was well, I'd be looking to add another signal structure to the SML class. If you can't do a 5th structure, then I might consider revamping the classdefs so that I could reassign one of the other 3 structures to SML. However, it's not clear to me what your configuration is. I'm wondering if you are having path busy or subchannel busy conditions. Or perhaps shared engines for the CF. Just the one GP for the CF? Just the one CF? Those sorts of issues should be addressed first. What type of machine? Signal rates? Last I knew, the RMF %delay was based on periodic sampling, perhaps every second. They look at what XCF reports as "pending signals". If for example, 10 samples out of 100 catch XCF with a pending signal, they'd report 10% delay. So what's a pending signal? It's a signal whose send I/O has not yet completed and it's been at least a millisecond since the signal was accepted for delivery. If we assume there is nothing "funny", such as path restart or structure rebuild, then a signal is pending either because the signal is waiting for the I/O to be started (so we have queueing delay) or the I/O was started and we're waiting for the back end completion to run. You said "Async rate for IXCSTR1 is 120", by which I assume you mean average response time for the IXCSTR1 requests is 120 mics (as opposed to 120 requests/second). The standard deviation will give you a sense of the variation in the waiting for the async back end completion to run. But let's say 120 is the number. If your workload sends a burst of 20 small signals a millisecond before RMF takes their sample, you'll see %delay (XCF sends signals in batches of 4, 120 mics per batch, the 5th batch will be seen as pending). If that's the pattern, then even at 100% delay, I dare say your workload is not suffering in the least. So whenever RMF reports %delay for XCF, you have to go see if the XCF signal path activity reports are showing any signs of queueing. What is AVG Q LEN? What is AVAIL vs BUSY? AVG Q LEN is usually zero or close to it. I tend to be unconcerned until it becomes more than one. BUSY tends to suggest that the batches are backing up. Adding another signal path helps address both AVG Q LEN and high BUSY conditions. HOWEVER, one should always look to address factors that can contribute to these conditions: "no buffer" conditions on the inbound side, or path busy, subchannel busy delays for the CF. Mark A Brooks z/OS Sysplex 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: LzLabs
Yeah, I remember Neon On Sat, May 2, 2020 at 8:55 AM Mike Schwab wrote: > Yep. They drop the interrupt handling in zIIPs and zAAPs to get full > speed processing. > > Could have checked the chips on the boards. Most S/360 models had > some microcode, only the highest model had all instructions in > hardware. > > On Sat, May 2, 2020 at 4:58 AM Wayne Bickerdike wrote: > > > > It's interesting that a zIIP can be described as a "speciality" engine > yet > > the workload they run also run on a CP engine. > > > > I thought that they are the same basically and it's just another way to > > sell a piece of kit and play bait and switch on pricing. > > > > Years ago we had a 9370 and a company in Melbourne we had some support > from > > ran an AS400. Their chief was convinced that the only difference was > > microcode (and price!). > > > > > > > > > > > > On Sat, May 2, 2020 at 1:28 PM Mike Schwab > wrote: > > > > > > > > > https://www.eweek.com/networking/neon-settles-mainframe-software-lawsuit-with-ibm > > > > > > On Sat, May 2, 2020 at 3:18 AM Steve Beaver > wrote: > > > > > > > > Actually they Did in Europe. European courts sided with Neon > > > > > > > > Sent from my iPhone > > > > > > > > > On May 1, 2020, at 22:07, Steve Smith wrote: > > > > > > > > > > No. Neon was a software company. They sold a product called > zPrime > > > that > > > > > allowed unauthorized usage of zIIP and zAAP for almost any kind of > > > > > workload. IBM already runs much of DB2 on zIIP. > > > > > > > > > > IBM only allows code to run on zIIP when you have specific > contracts > > > that > > > > > allow you to for specific things. Neon either violated those, or > more > > > > > likely reverse-engineered it, which is almost certainly a > violation of > > > some > > > > > other contract they were bound to. > > > > > > > > > > I don't know any details, but it's hard for me to see how that Neon > > > thought > > > > > they were going to get away with it. > > > > > > > > > > sas > > > > > > > > > > > > > > >> On Fri, May 1, 2020 at 8:42 PM Mike Schwab < > mike.a.sch...@gmail.com> > > > wrote: > > > > >> > > > > >> Neon was a product to run some DB2 on zAAPs or zIIPs. Only the > > > > >> workload specified by IBM could run on those processors. > > > > >> > > > > >>> On Fri, May 1, 2020 at 5:45 PM Peter Baumann < > peterhbaum...@gmx.ch> > > > wrote: > > > > >>> > > > > >>> In a lawsuit against Neon Enterprise (John Moores) the court > ruled in > > > > >> favor of IBM. They had to take zPrime out of the market. There > was > > > also a > > > > >> permanent injunction issued against Neon. > > > > >>> > > > > >> > > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > -- > > > Mike A Schwab, Springfield IL USA > > > Where do Forest Rangers go to get away from it all? > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > -- > > Wayne V. Bickerdike > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- 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: z/OS performance question
So you have only one signal structure per transport class? If your traffic is like most, the small traffic is an order of magnitude more than any other size, and it's all flowing to the same place. Each target system will have a unique list, so you get some distribution from that. But if you have high signals/sec to a given target, you may be getting some latch contention within the CF (but it all depends). Fussing with the transport class definitions will not help. If all else was well, I'd be looking to add another signal structure to the SML class. If you can't do a 5th structure, then I might consider revamping the classdefs so that I could reassign one of the other 3 structures to SML. However, it's not clear to me what your configuration is. I'm wondering if you are having path busy or subchannel busy conditions. Or perhaps shared engines for the CF. Just the one GP for the CF? Just the one CF? Those sorts of issues should be addressed first. What type of machine? Signal rates? Last I knew, the RMF %delay was based on periodic sampling, perhaps every second. They look at what XCF reports as "pending signals". If for example, 10 samples out of 100 catch XCF with a pending signal, they'd report 10% delay. So what's a pending signal? It's a signal whose send I/O has not yet completed and it's been at least a millisecond since the signal was accepted for delivery. If we assume there is nothing "funny", such as path restart or structure rebuild, then a signal is pending either because the signal is waiting for the I/O to be started (so we have queueing delay) or the I/O was started and we're waiting for the back end completion to run. You said "Async rate for IXCSTR1 is 120", by which I assume you mean average response time for the IXCSTR1 requests is 120 mics (as opposed to 120 requests/second). The standard deviation will give you a sense of the variation in the waiting for the async back end completion to run. But let's say 120 is the number. If your workload sends a burst of 20 small signals a millisecond before RMF takes their sample, you'll see %delay (XCF sends signals in batches of 4, 120 mics per batch, the 5th batch will be seen as pending). If that's the pattern, then even at 100% delay, I dare say your workload is not suffering in the least. So whenever RMF reports %delay for XCF, you have to go see if the XCF signal path activity reports are showing any signs of queueing. What is AVG Q LEN? What is AVAIL vs BUSY? AVG Q LEN is usually zero or close to it. I tend to be unconcerned until it becomes more than one. BUSY tends to suggest that the batches are backing up. Adding another signal path helps address both AVG Q LEN and high BUSY conditions. HOWEVER, one should always look to address factors that can contribute to these conditions: "no buffer" conditions on the inbound side, or path busy, subchannel busy delays for the CF. Mark A Brooks z/OS Sysplex Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
> You talk about authenticating with a certificate, but how would
permissions work in that case?
FWIW, authentication ("signing on") and authorization ("permissions") are
separate issues. RACF (and its sisters) do both, so it is easy to run them
together, but they are separate issues.* You are correct -- one might
authenticate with an iris scanner, but you still need a decision "can Bob
update SYS1.LINKLIB or not?"
RACROUTE takes a USERID of up to 8 characters, but generally works not
directly from a USERID but rather from an existing ACEE. But yes, the ACEE
includes -- you guessed it -- the basic 1+8 USERID. Not every ACEE has a
USERID filled in, so perhaps -- perhaps, I don't know -- perhaps one could
go from certificate authentication to an ACEE to authorization.
*I heard Barry Shrager, a father of mainframe security, say words to the
effect that authentication is the more important issue, because without good
authentication that you really are RBRIDGES, what difference does it make
what resources RBRIDGES has access to?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bob Bridges
Sent: Saturday, May 2, 2020 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe user ID length
But...but... (Still expostulating, here, you see.) When I want to open a
dataset for editing in TSO, the OS sends a question to the security system,
asking "is allowed to ?".
To identify it specifies my ID. The question is routed to
RACF, ACF2 or Top Secret, and the part of the OS that is performing the
action doesn't know and doesn't care which one - but before it performs the
open, it requires an answer from the security system, and all three of them
have an 8-byte limit on the ID.
You talk about authenticating with a certificate, but how would permissions
work in that case? Isn't RACROUTE the funneling point for all such checks?
And doesn't RACROUTE require an 8-byte ID to identify the actor?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: it was 20 years ago today ....
(Old post) I don't have any citations, but some of the most notorious doomsters recanted their gloomy predictions well BEFORE January 2000. They presumably sold a lot of $19.99 books in the meantime. I doubt that Tom received an offer of refund. So how did we dodge the Y2K asteroid? I can testify from personal witness that we worked our *sses off and coincidentally spent tons of money. Catastrophe did not just happen to miss us. We took heroic evasive maneuvers. Fast forward to today. We're currently mired in a crisis even farther-reaching than Y2K. The question is increasingly asked: what will the 'new normal' look like once we're back to whatever? No predictions from me, but we can observe some changes in pre-2000 IT. A lot of the aforementioned Y2K spend was directed at and justified by replacing old hardware and software. I joined SCE in 1994. By early in the new century, not a single piece of mainframe hardware on the floor in the md-90s remained in use. All replaced by more modern gear or in some cases by changes in the way we did business. These changes were accomplished not so much by futuristic strategic planning as by the looming threat of jail time for corporate executives who failed to board the boat. Coercion at its sweetest. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Thursday, January 2, 2020 6:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: it was 20 years ago today > In the 90s Stewart Alsop famously predicted the end of the world. I just checked my old book collection and found "Time Bomb 2000" by Edward and Jennifer Yourdon. On the back it has questions like, Will your car run?, Will there be food?, Will your PC work? ... Yep, I fell for it. Marked $19.99 - I hope I got a really good discount. On 1/2/2020 4:18 PM, Jesse 1 Robinson wrote: > I heard a 'Y2K person' interviewed on NPR recently. Her point was that if the > IT industry had done nothing in advance to remediate, we would have had utter > chaos on 1/1/2000. But we did prepare. We undoubtedly overprepared, but by > how much will forever remain a mystery. > > In the 90s Stewart Alsop famously predicted the end of the world. He > retreated well before the event itself. We all buy insurance that we're > thrilled not to utilize. That doesn't make it a waste. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Sat, 2 May 2020 14:34:26 +0800, Timothy Sipples wrote: >Frank Swarbrick wrote: >>"more than 8"? What's the limit, if any? > >The z/OS LDAP Server's CN limit is 256 characters, so it's at least that >large. > >>Which system components/products permit/prohibit this? >>(Start your list with JCL.) > >You can specify pretty much anything you want in JCL. Do you mean JES2? If >so, that'll use maximum 8 character user IDs. > That appears to be the exception that proves the rule, so will JES3 (as opposed to JES2) accept such as: //TEST JOB 'D83,123456',USER='Влади́мир_Пу́тин',PASSWORD=ABCD ... if that user has been defined in RACF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
But...but... (Still expostulating, here, you see.) When I want to open a dataset for editing in TSO, the OS sends a question to the security system, asking "is allowed to ?". To identify it specifies my ID. The question is routed to RACF, ACF2 or Top Secret, and the part of the OS that is performing the action doesn't know and doesn't care which one - but before it performs the open, it requires an answer from the security system, and all three of them have an 8-byte limit on the ID. You talk about authenticating with a certificate, but how would permissions work in that case? Isn't RACROUTE the funneling point for all such checks? And doesn't RACROUTE require an 8-byte ID to identify the actor? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* To be humble to superiors is duty, to equals courtesy, to inferiors nobleness. -Poor Richard */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Saturday, May 2, 2020 02:34 RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ic ha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on screen. --- Bob Bridges wrote: >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how >does RACF-or-whatever determine permissions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
On Sat, 2 May 2020 10:51:01 -0600, Jack J. Woehr wrote: >On 5/2/20 9:53 AM, Wendell Lovewell wrote: >> When connecting to z/OS (USS) using ssh, I'd like the USS shell to handle >> keys the same way Ubuntu does. I have these settings: >> >> echo $TERM displays xterm-color256 >> echo $SHELL displays /bin/sh > >As Gil pointed out, run bash. It's often there somewhere. > >If not bash, use tcsh > Eek! https://www-uxsup.csx.cam.ac.uk/misc/csh.html >Also: >export TERM=xterm > Doesn't ssh supposed to set that up? But z/OS may not be savvy to the OP's TERM. Is it in terminfo? But z/OS used to deny login when TERM was not in terminfo. Did it ever get better? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
On 5/2/20 9:53 AM, Wendell Lovewell wrote: When connecting to z/OS (USS) using ssh, I'd like the USS shell to handle keys the same way Ubuntu does. I have these settings: echo $TERM displays xterm-color256 echo $SHELL displays /bin/sh As Gil pointed out, run bash. It's often there somewhere. If not bash, use tcsh Also: export TERM=xterm -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
In article <6643888504611180.wa.paulgboulderaim@listserv.ua.edu> you wrote: > On Sat, 2 May 2020 18:26:48 +0200, Mike Beer wrote: > >Maybe using putty might help: > >https://www.putty.org/ > >https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html > > > >Best regards > >Mike > > > >-Urspr??ngliche Nachricht- > >Von: IBM Mainframe Discussion List Im Auftrag von > >Wendell Lovewell > >Gesendet: Saturday, May 02, 2020 17:54 > >An: IBM-MAIN@LISTSERV.UA.EDU > >Betreff: Using Windows ssh with z/OS > > > >When connecting to z/OS (USS) using ssh, I'd like the USS shell to handle > >keys the same way Ubuntu does. I have these settings: > > > >echo $TERM displays xterm-color256 > >echo $SHELL displays /bin/sh > > > >Specifically, I'd like: > > > >a) The cursor-up key to perform the "history-search-backward" function > >b) The cursor-down key to perform the "history-search-forward" function > >c) The cursor-left and cursor-right keys to move thru the command just > >retrieved > >d) To be able to change the command by moving the cursor and typing over the > >retrieved command > > > Those are bash-isms. They may be unavailable in /bin/sh. > EXC-k and ESC-j are alternatives. > -- gil bash is available from Rocket: https://www.rocketsoftware.com/product-categories/mainframe/bash-zos -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Using Windows ssh with z/OS
On Sat, 2 May 2020 18:26:48 +0200, Mike Beer wrote: >Maybe using putty might help: >https://www.putty.org/ >https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html > >Best regards >Mike > >-Ursprüngliche Nachricht- >Von: IBM Mainframe Discussion List Im Auftrag von >Wendell Lovewell >Gesendet: Saturday, May 02, 2020 17:54 >An: IBM-MAIN@LISTSERV.UA.EDU >Betreff: Using Windows ssh with z/OS > >When connecting to z/OS (USS) using ssh, I'd like the USS shell to handle keys >the same way Ubuntu does. I have these settings: > >echo $TERM displays xterm-color256 >echo $SHELL displays /bin/sh > >Specifically, I'd like: > >a) The cursor-up key to perform the "history-search-backward" function >b) The cursor-down key to perform the "history-search-forward" function >c) The cursor-left and cursor-right keys to move thru the command just >retrieved >d) To be able to change the command by moving the cursor and typing over the >retrieved command > Those are bash-isms. They may be unavailable in /bin/sh. EXC-k and ESC-j are alternatives. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Using Windows ssh with z/OS
Maybe using putty might help: https://www.putty.org/ https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html Best regards Mike -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List Im Auftrag von Wendell Lovewell Gesendet: Saturday, May 02, 2020 17:54 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Using Windows ssh with z/OS When connecting to z/OS (USS) using ssh, I'd like the USS shell to handle keys the same way Ubuntu does. I have these settings: echo $TERM displays xterm-color256 echo $SHELL displays /bin/sh Specifically, I'd like: a) The cursor-up key to perform the "history-search-backward" function b) The cursor-down key to perform the "history-search-forward" function c) The cursor-left and cursor-right keys to move thru the command just retrieved d) To be able to change the command by moving the cursor and typing over the retrieved command I've been able to use stty erase ^? in /etc/profile to set the backspace key, but my attempts at using ~/.inputrc to control the cursor keys have been unsuccessful. Trying different terminal types (eg export TERM=xterm or export TERM=vt100) has also not helped. Does anyone know how to do this? Best Regards, Wendell Lovewell -- 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
Using Windows ssh with z/OS
When connecting to z/OS (USS) using ssh, I'd like the USS shell to handle keys the same way Ubuntu does. I have these settings: echo $TERM displays xterm-color256 echo $SHELL displays /bin/sh Specifically, I'd like: a) The cursor-up key to perform the "history-search-backward" function b) The cursor-down key to perform the "history-search-forward" function c) The cursor-left and cursor-right keys to move thru the command just retrieved d) To be able to change the command by moving the cursor and typing over the retrieved command I've been able to use stty erase ^? in /etc/profile to set the backspace key, but my attempts at using ~/.inputrc to control the cursor keys have been unsuccessful. Trying different terminal types (eg export TERM=xterm or export TERM=vt100) has also not helped. Does anyone know how to do this? Best Regards, Wendell Lovewell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LzLabs
Yep. They drop the interrupt handling in zIIPs and zAAPs to get full speed processing. Could have checked the chips on the boards. Most S/360 models had some microcode, only the highest model had all instructions in hardware. On Sat, May 2, 2020 at 4:58 AM Wayne Bickerdike wrote: > > It's interesting that a zIIP can be described as a "speciality" engine yet > the workload they run also run on a CP engine. > > I thought that they are the same basically and it's just another way to > sell a piece of kit and play bait and switch on pricing. > > Years ago we had a 9370 and a company in Melbourne we had some support from > ran an AS400. Their chief was convinced that the only difference was > microcode (and price!). > > > > > > On Sat, May 2, 2020 at 1:28 PM Mike Schwab wrote: > > > > > https://www.eweek.com/networking/neon-settles-mainframe-software-lawsuit-with-ibm > > > > On Sat, May 2, 2020 at 3:18 AM Steve Beaver wrote: > > > > > > Actually they Did in Europe. European courts sided with Neon > > > > > > Sent from my iPhone > > > > > > > On May 1, 2020, at 22:07, Steve Smith wrote: > > > > > > > > No. Neon was a software company. They sold a product called zPrime > > that > > > > allowed unauthorized usage of zIIP and zAAP for almost any kind of > > > > workload. IBM already runs much of DB2 on zIIP. > > > > > > > > IBM only allows code to run on zIIP when you have specific contracts > > that > > > > allow you to for specific things. Neon either violated those, or more > > > > likely reverse-engineered it, which is almost certainly a violation of > > some > > > > other contract they were bound to. > > > > > > > > I don't know any details, but it's hard for me to see how that Neon > > thought > > > > they were going to get away with it. > > > > > > > > sas > > > > > > > > > > > >> On Fri, May 1, 2020 at 8:42 PM Mike Schwab > > wrote: > > > >> > > > >> Neon was a product to run some DB2 on zAAPs or zIIPs. Only the > > > >> workload specified by IBM could run on those processors. > > > >> > > > >>> On Fri, May 1, 2020 at 5:45 PM Peter Baumann > > wrote: > > > >>> > > > >>> In a lawsuit against Neon Enterprise (John Moores) the court ruled in > > > >> favor of IBM. They had to take zPrime out of the market. There was > > also a > > > >> permanent injunction issued against Neon. > > > >>> > > > >> > > > > > > > > -- > > > > 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 > > > > > > > > -- > > Mike A Schwab, Springfield IL USA > > Where do Forest Rangers go to get away from it all? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Wayne V. Bickerdike > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on screen. >...Even if I've logged on from some other OS using a longer ID, >inside z/OS the system is still using an 8-byte ID. But "who cares?" Users presenting longer IDs or client certificates certainly don't. "If a tree falls in the woods" As long as there is at least adequate granularity in providing enough different security contexts it shouldn't particularly matter. For all we know (and I don't know) RACF already does something internally that has more breadth than maximum 8 character TSO/E user IDs would ordinarily suggest. Analogously, does it matter much that Microsoft Windows still only supports a maximum of 26 single character drive letters (A to Z)? Not really, no. Microsoft (and IBM) sidestepped that limitation a long time ago by providing an alternate way to refer to disks: \\DiskABC123456\... (for example). Older software (that only understands D:\...) doesn't break because you can assign and reassign the old drive letters, while newer software and user interfaces forge ahead. You then decide whether and how quickly you'd like to move forward. I
