Re: Architectural Level Sets
Assuming that the universe of discourse here is MVS *as supplied by IBM*, DAS support was introduced in MVS SP1.2 JBB1226, and was never rolled back to anything lower. SP1.2 never GAed, so unless you were an SP1.2 ESP customer, DAS support was introduced in SP1.3 JBB1326. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/02/2020 12:26:37 AM: > From: "Joe Monk" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/02/2020 01:38 AM > Subject: Re: Architectural Level Sets > Sent by: "IBM Mainframe Discussion List" > > "WTF? DAS requires MVS/SP." > > Nope. :) > > It is available via USERMOD in MVS 3.8J. > > Joe > > On Tue, Sep 1, 2020 at 7:01 PM Seymour J Metz wrote: > > > WTF? DAS requires MVS/SP. > > > > That said, MVS/SP ran just fine on a 4341. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
As far as I know, MVS always used only 4K pages in DAT. My evidence is that the oldest MVS IEAVNIP0 source that I can find unconditionally uses 4K pages in DAT. What is your evidence? The hardware storage keys were still on a 2K basis, so two SSKs were done for each 4K page, until the >16MB of real storage support was added to the 3033. That introduced the ISKE and SSKE instructions, which required only on SSKE for a 4K page. The MVS SP1.3 JBB1326 version of IEAVNIP0 tried an SSKE, and if it didn't program check, assumed that the machine had the new instructions and DAT support for >16MB of real stroage. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/02/2020 12:27:34 AM: > From: "Joe Monk" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/02/2020 01:29 AM > Subject: Re: Architectural Level Sets > Sent by: "IBM Mainframe Discussion List" > > "MVS didn't use 2KiB pages," > > Yes, MVS 3.8J does use 2KB pages. > > Joe > > On Tue, Sep 1, 2020 at 7:20 PM Seymour J Metz wrote: > > > MVS didn't use 2KiB pages, so I never paid any attention to whether the > > 4341 or 3081 had them, but MVS/XA required DAS. Access registers came > > later, on the 3090, and were part of ESA. > > > > The 4341 most definitely was not limited to a single address space; It ran > > MVS/SP 1.3 just fine. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setting up CSSMTP to use TLS-SSL
Okay, I see now. The client cert is available from our email server, i twas just a matter of downloading it and adding to RACF. Thanks, Brian On Tue, 1 Sep 2020 08:21:13 -0500, Peter Vander Woude wrote: >Brian, > >I do use AT-TLS with CSSMTP to our internal e-mail relay. For the keyring, >you need to add the CA's that have signed the ssl cert for the server. > >If the e-mail server is using a self-signed certificate, you need them to send >a copy of it (only the public portion) and it has to be added as a certificate >authority. > >Peter > >-- >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: Architectural Level Sets
"MVS didn't use 2KiB pages," Yes, MVS 3.8J does use 2KB pages. Joe On Tue, Sep 1, 2020 at 7:20 PM Seymour J Metz wrote: > MVS didn't use 2KiB pages, so I never paid any attention to whether the > 4341 or 3081 had them, but MVS/XA required DAS. Access registers came > later, on the 3090, and were part of ESA. > > The 4341 most definitely was not limited to a single address space; It ran > MVS/SP 1.3 just fine. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Mike Schwab > Sent: Tuesday, September 1, 2020 5:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Architectural Level Sets > > Well, XA+ machines only supported 4K pages / 1M segments and not 2K > pages / 64K segments. Then DAS and Access register additions. The > 43xx series only supported a single virtual address space, like > DOS/VSE. 3090s were the only processors to support Vector > instructions, and op codes were re-used in z series. > > On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: > > > > I was thinking more along the lines of things that prevented earlier > > operating systems from even IPLing on newer boxes. Such as z13 is the > > last processor to have ESA/390 mode. I also have it in my head that at > > some point there were changes to the page size and virtual storage > > tables that caused havoc. > > > > Tony Thigpen > > > > Seymour J Metz wrote on 9/1/20 3:30 PM: > > > Typically the new features reqiured by a level set were added over > several generations, and each generation added more than one feature. > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > > > > > > > From: IBM Mainframe Discussion List on > behalf of Tony Thigpen > > > Sent: Tuesday, September 1, 2020 3:25 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Architectural Level Sets > > > > > > IBM has had several Architectural Level Set points where there were > > > significant changes to the CPU that prevented earlier operating systems > > > from running on them. > > > > > > What CPU's were involved with each level, and what was the real > > > underlying item changed on the CPU that forced a new level? (Let's keep > > > it limited to z990 and newer.) > > > > > > > > > Tony Thigpen > > > > > > -- > > > 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 > > > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
"WTF? DAS requires MVS/SP." Nope. :) It is available via USERMOD in MVS 3.8J. Joe On Tue, Sep 1, 2020 at 7:01 PM Seymour J Metz wrote: > WTF? DAS requires MVS/SP. > > That said, MVS/SP ran just fine on a 4341. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Joe Monk > Sent: Tuesday, September 1, 2020 5:55 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Architectural Level Sets > > 370 supported DAS (the code is in MVS3.8J). > > 43XX running MVS supported DAS also. 4381 could have up to 64M of main > storage... > > Joe > > On Tue, Sep 1, 2020 at 4:26 PM Mike Schwab > wrote: > > > Well, XA+ machines only supported 4K pages / 1M segments and not 2K > > pages / 64K segments. Then DAS and Access register additions. The > > 43xx series only supported a single virtual address space, like > > DOS/VSE. 3090s were the only processors to support Vector > > instructions, and op codes were re-used in z series. > > > > On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: > > > > > > I was thinking more along the lines of things that prevented earlier > > > operating systems from even IPLing on newer boxes. Such as z13 is the > > > last processor to have ESA/390 mode. I also have it in my head that at > > > some point there were changes to the page size and virtual storage > > > tables that caused havoc. > > > > > > Tony Thigpen > > > > > > Seymour J Metz wrote on 9/1/20 3:30 PM: > > > > Typically the new features reqiured by a level set were added over > > several generations, and each generation added more than one feature. > > > > > > > > > > > > -- > > > > Shmuel (Seymour J.) Metz > > > > http://mason.gmu.edu/~smetz3 > > > > > > > > > > > > > > > > From: IBM Mainframe Discussion List on > > behalf of Tony Thigpen > > > > Sent: Tuesday, September 1, 2020 3:25 PM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Architectural Level Sets > > > > > > > > IBM has had several Architectural Level Set points where there were > > > > significant changes to the CPU that prevented earlier operating > systems > > > > from running on them. > > > > > > > > What CPU's were involved with each level, and what was the real > > > > underlying item changed on the CPU that forced a new level? (Let's > keep > > > > it limited to z990 and newer.) > > > > > > > > > > > > Tony Thigpen > > > > > > > > > -- > > > > 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 > > > > > > > > -- > > 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 > > -- > 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: Architectural Level Sets
And that's better than the obvious MVC of 'JESSE' because? Because with MVCIN 'JESSE' does not appear in the literal pool and make it masquerade as the control block? I find it hard to accept that this method's obscurity would be outweighed by its usefulness. Looks to me like a convoluted solution in search of a problem. I believe in eschewing obfuscation, especially in assembler code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, September 1, 2020 8:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets On 9/1/2020 6:36 PM, Jesse 1 Robinson wrote: > As for a vanishing instruction, I once wrote some code using the Move Inverse > (MVCIN) instruction, which greatly simplified scanning data for a terminating > character. Apparently MVCIN was introduced on the 4341 (?) but not carried > forward to subsequent models. So S0C1. A rude shock for a clever programmer > looking for ingenious solutions. MVCIN is a standard part of z/Architecture. We use it *heavily* for setting control block eyecatchers e.g.: MVCIN CBlockEyeCatch,=C' ESSEJ'+5 Set eyecatcher to 'JESSE ' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
Yes. I took care of VS1 1.7D with BPE (Basic Programming Extensions) on a 4341. On 2020-09-01 22:56, Mike Schwab wrote: Well, this is what confused me. OS/VS1 1.7 was released to run on the IBM 4300. VS2 is multiple address spaces, vs VS1 is a single 16MB address space, correct? https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FIBM_4300%23Operating_systemsdata=02%7C01%7C%7C6fa1bedaf4bb4215188808d84eebd988%7C84df9e7fe9f640afb435%7C1%7C0%7C637346122168286714sdata=WbBo0CYQaxXI%2B%2B8BSChV1384pI802SAupW8ye5QjTQw%3Dreserved=0 On Tue, Sep 1, 2020 at 6:27 PM Phil Smith III wrote: mike.a.sch...@gmail.com (Mike Schwab) wrote: Well, XA+ machines only supported 4K pages / 1M segments and not 2K pages / 64K segments. Then DAS and Access register additions. The 43xx series only supported a single virtual address space, like DOS/VSE. 3090s were the only processors to support Vector instructions, and op codes were re-used in z series. What does this mean, "a single virtual address space"? VM ran fine on it, with many virtual address spaces. Are you perhaps thinking of V=R/V=F? I disremember whether 43xx supported those. ...phsiii P.S. "zSeries" (RIP) -- 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: Architectural Level Sets
On 9/1/2020 6:36 PM, Jesse 1 Robinson wrote: As for a vanishing instruction, I once wrote some code using the Move Inverse (MVCIN) instruction, which greatly simplified scanning data for a terminating character. Apparently MVCIN was introduced on the 4341 (?) but not carried forward to subsequent models. So S0C1. A rude shock for a clever programmer looking for ingenious solutions. MVCIN is a standard part of z/Architecture. We use it *heavily* for setting control block eyecatchers e.g.: MVCIN CBlockEyeCatch,=C' ESSEJ'+5 Set eyecatcher to 'JESSE ' -- 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: Architectural Level Sets
Well, this is what confused me. OS/VS1 1.7 was released to run on the IBM 4300. VS2 is multiple address spaces, vs VS1 is a single 16MB address space, correct? https://en.wikipedia.org/wiki/IBM_4300#Operating_systems On Tue, Sep 1, 2020 at 6:27 PM Phil Smith III wrote: > > mike.a.sch...@gmail.com (Mike Schwab) wrote: > > >Well, XA+ machines only supported 4K pages / 1M segments and not 2K > > >pages / 64K segments. Then DAS and Access register additions. The > > >43xx series only supported a single virtual address space, like > > >DOS/VSE. 3090s were the only processors to support Vector > > >instructions, and op codes were re-used in z series. > > > > What does this mean, "a single virtual address space"? VM ran fine on it, > with many virtual address spaces. Are you perhaps thinking of V=R/V=F? I > disremember whether 43xx supported those. > > > > ...phsiii > > > > P.S. "zSeries" (RIP) > > > -- > 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: Architectural Level Sets
And, to make matters worse, IBM reinstated the MVCIN on later processors after having dropped it for at least one machine built after the 43xx machines. It works now and has since at least the MP3k. Tony Thigpen Jesse 1 Robinson wrote on 9/1/20 9:36 PM: Instructions come and--believe it or not--instructions go. I once read some doc on a newly introduced instruction. Don't remember the timeframe or the exact instruction, but it came with this interesting comment. This instruction, being new, will not cause a problem for existing code unless that code expects the instruction *not* to exist. In that case the new instruction will do something that the program does not expect. Right. One sort-of case occurred in JES2, whose error handling for 3900 printers had become increasingly convoluted to the point that the simplest short term 'fix' was to force a S0C1 abend and let JES2 internal error routines perform recovery using built-in code. This was accomplished by deliberately branching to an invalid 'instruction'. JES2 would clean up the printer and move on. Unfortunately, the APAR delivering this change branched to character data that looked like a packed decimal instruction. So instead of S0C1, the resulting S0C7 caused a JES2 abend. Not at all what was intended. As for a vanishing instruction, I once wrote some code using the Move Inverse (MVCIN) instruction, which greatly simplified scanning data for a terminating character. Apparently MVCIN was introduced on the 4341 (?) but not carried forward to subsequent models. So S0C1. A rude shock for a clever programmer looking for ingenious solutions. . . 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 Seymour J Metz Sent: Tuesday, September 1, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Architectural Level Sets CAUTION EXTERNAL EMAIL Well, a S/360 program that depends on getting PIC 06 for an unaligned load won't work correctly on a 360/85 or S/370. S/370 supported 2 KiB pages, and those are history. MVS/370 uses SIO, whch only exists in S/370 mode: also history. So carrying an old OS forward has always has issues. Sure, IBM could ensure absolute compatibiity for old releaes, but TANSTAAFL. Only IBM knows what the extra cost would be, but I guaranty that there would be an extra cost. I'm sure that this has been discussed at Share. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Thigpen Sent: Tuesday, September 1, 2020 5:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets I was thinking more along the lines of things that prevented earlier operating systems from even IPLing on newer boxes. Such as z13 is the last processor to have ESA/390 mode. I also have it in my head that at some point there were changes to the page size and virtual storage tables that caused havoc. Tony Thigpen Seymour J Metz wrote on 9/1/20 3:30 PM: Typically the new features reqiured by a level set were added over several generations, and each generation added more than one feature. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Thigpen Sent: Tuesday, September 1, 2020 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Architectural Level Sets IBM has had several Architectural Level Set points where there were significant changes to the CPU that prevented earlier operating systems from running on them. What CPU's were involved with each level, and what was the real underlying item changed on the CPU that forced a new level? (Let's keep it limited to z990 and newer.) Tony Thigpen -- 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 -- 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
Re: Architectural Level Sets
Instructions come and--believe it or not--instructions go. I once read some doc on a newly introduced instruction. Don't remember the timeframe or the exact instruction, but it came with this interesting comment. This instruction, being new, will not cause a problem for existing code unless that code expects the instruction *not* to exist. In that case the new instruction will do something that the program does not expect. Right. One sort-of case occurred in JES2, whose error handling for 3900 printers had become increasingly convoluted to the point that the simplest short term 'fix' was to force a S0C1 abend and let JES2 internal error routines perform recovery using built-in code. This was accomplished by deliberately branching to an invalid 'instruction'. JES2 would clean up the printer and move on. Unfortunately, the APAR delivering this change branched to character data that looked like a packed decimal instruction. So instead of S0C1, the resulting S0C7 caused a JES2 abend. Not at all what was intended. As for a vanishing instruction, I once wrote some code using the Move Inverse (MVCIN) instruction, which greatly simplified scanning data for a terminating character. Apparently MVCIN was introduced on the 4341 (?) but not carried forward to subsequent models. So S0C1. A rude shock for a clever programmer looking for ingenious solutions. . . 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 Seymour J Metz Sent: Tuesday, September 1, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Architectural Level Sets CAUTION EXTERNAL EMAIL Well, a S/360 program that depends on getting PIC 06 for an unaligned load won't work correctly on a 360/85 or S/370. S/370 supported 2 KiB pages, and those are history. MVS/370 uses SIO, whch only exists in S/370 mode: also history. So carrying an old OS forward has always has issues. Sure, IBM could ensure absolute compatibiity for old releaes, but TANSTAAFL. Only IBM knows what the extra cost would be, but I guaranty that there would be an extra cost. I'm sure that this has been discussed at Share. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Thigpen Sent: Tuesday, September 1, 2020 5:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets I was thinking more along the lines of things that prevented earlier operating systems from even IPLing on newer boxes. Such as z13 is the last processor to have ESA/390 mode. I also have it in my head that at some point there were changes to the page size and virtual storage tables that caused havoc. Tony Thigpen Seymour J Metz wrote on 9/1/20 3:30 PM: > Typically the new features reqiured by a level set were added over several > generations, and each generation added more than one feature. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on > behalf of Tony Thigpen > Sent: Tuesday, September 1, 2020 3:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Architectural Level Sets > > IBM has had several Architectural Level Set points where there were > significant changes to the CPU that prevented earlier operating > systems from running on them. > > What CPU's were involved with each level, and what was the real > underlying item changed on the CPU that forced a new level? (Let's > keep it limited to z990 and newer.) > > > Tony Thigpen > > -- > 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 -- 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: Architectural Level Sets
Well, a S/360 program that depends on getting PIC 06 for an unaligned load won't work correctly on a 360/85 or S/370. S/370 supported 2 KiB pages, and those are history. MVS/370 uses SIO, whch only exists in S/370 mode: also history. So carrying an old OS forward has always has issues. Sure, IBM could ensure absolute compatibiity for old releaes, but TANSTAAFL. Only IBM knows what the extra cost would be, but I guaranty that there would be an extra cost. I'm sure that this has been discussed at Share. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Thigpen Sent: Tuesday, September 1, 2020 5:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets I was thinking more along the lines of things that prevented earlier operating systems from even IPLing on newer boxes. Such as z13 is the last processor to have ESA/390 mode. I also have it in my head that at some point there were changes to the page size and virtual storage tables that caused havoc. Tony Thigpen Seymour J Metz wrote on 9/1/20 3:30 PM: > Typically the new features reqiured by a level set were added over several > generations, and each generation added more than one feature. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > Tony Thigpen > Sent: Tuesday, September 1, 2020 3:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Architectural Level Sets > > IBM has had several Architectural Level Set points where there were > significant changes to the CPU that prevented earlier operating systems > from running on them. > > What CPU's were involved with each level, and what was the real > underlying item changed on the CPU that forced a new level? (Let's keep > it limited to z990 and newer.) > > > Tony Thigpen > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
MVS didn't use 2KiB pages, so I never paid any attention to whether the 4341 or 3081 had them, but MVS/XA required DAS. Access registers came later, on the 3090, and were part of ESA. The 4341 most definitely was not limited to a single address space; It ran MVS/SP 1.3 just fine. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Tuesday, September 1, 2020 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets Well, XA+ machines only supported 4K pages / 1M segments and not 2K pages / 64K segments. Then DAS and Access register additions. The 43xx series only supported a single virtual address space, like DOS/VSE. 3090s were the only processors to support Vector instructions, and op codes were re-used in z series. On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: > > I was thinking more along the lines of things that prevented earlier > operating systems from even IPLing on newer boxes. Such as z13 is the > last processor to have ESA/390 mode. I also have it in my head that at > some point there were changes to the page size and virtual storage > tables that caused havoc. > > Tony Thigpen > > Seymour J Metz wrote on 9/1/20 3:30 PM: > > Typically the new features reqiured by a level set were added over several > > generations, and each generation added more than one feature. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > > > From: IBM Mainframe Discussion List on behalf of > > Tony Thigpen > > Sent: Tuesday, September 1, 2020 3:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Architectural Level Sets > > > > IBM has had several Architectural Level Set points where there were > > significant changes to the CPU that prevented earlier operating systems > > from running on them. > > > > What CPU's were involved with each level, and what was the real > > underlying item changed on the CPU that forced a new level? (Let's keep > > it limited to z990 and newer.) > > > > > > Tony Thigpen > > > > -- > > 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 -- 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: Architectural Level Sets
WTF? DAS requires MVS/SP. That said, MVS/SP ran just fine on a 4341. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Joe Monk Sent: Tuesday, September 1, 2020 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets 370 supported DAS (the code is in MVS3.8J). 43XX running MVS supported DAS also. 4381 could have up to 64M of main storage... Joe On Tue, Sep 1, 2020 at 4:26 PM Mike Schwab wrote: > Well, XA+ machines only supported 4K pages / 1M segments and not 2K > pages / 64K segments. Then DAS and Access register additions. The > 43xx series only supported a single virtual address space, like > DOS/VSE. 3090s were the only processors to support Vector > instructions, and op codes were re-used in z series. > > On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: > > > > I was thinking more along the lines of things that prevented earlier > > operating systems from even IPLing on newer boxes. Such as z13 is the > > last processor to have ESA/390 mode. I also have it in my head that at > > some point there were changes to the page size and virtual storage > > tables that caused havoc. > > > > Tony Thigpen > > > > Seymour J Metz wrote on 9/1/20 3:30 PM: > > > Typically the new features reqiured by a level set were added over > several generations, and each generation added more than one feature. > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > > > > > > > From: IBM Mainframe Discussion List on > behalf of Tony Thigpen > > > Sent: Tuesday, September 1, 2020 3:25 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Architectural Level Sets > > > > > > IBM has had several Architectural Level Set points where there were > > > significant changes to the CPU that prevented earlier operating systems > > > from running on them. > > > > > > What CPU's were involved with each level, and what was the real > > > underlying item changed on the CPU that forced a new level? (Let's keep > > > it limited to z990 and newer.) > > > > > > > > > Tony Thigpen > > > > > > -- > > > 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 > > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
mike.a.sch...@gmail.com (Mike Schwab) wrote: >Well, XA+ machines only supported 4K pages / 1M segments and not 2K >pages / 64K segments. Then DAS and Access register additions. The >43xx series only supported a single virtual address space, like >DOS/VSE. 3090s were the only processors to support Vector >instructions, and op codes were re-used in z series. What does this mean, "a single virtual address space"? VM ran fine on it, with many virtual address spaces. Are you perhaps thinking of V=R/V=F? I disremember whether 43xx supported those. ...phsiii P.S. "zSeries" (RIP) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
4342 and 4381 ran MVS was Re: Architectural Level Sets
[Default] On 1 Sep 2020 14:26:32 -0700, in bit.listserv.ibm-main mike.a.sch...@gmail.com (Mike Schwab) wrote: >Well, XA+ machines only supported 4K pages / 1M segments and not 2K >pages / 64K segments. Then DAS and Access register additions. The >43xx series only supported a single virtual address space, like >DOS/VSE. 3090s were the only processors to support Vector >instructions, and op codes were re-used in z series. The 4341 and 4381 could and did run MVS. I was responsible for MVs on them at my site. Clark Morris > >On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: >> >> I was thinking more along the lines of things that prevented earlier >> operating systems from even IPLing on newer boxes. Such as z13 is the >> last processor to have ESA/390 mode. I also have it in my head that at >> some point there were changes to the page size and virtual storage >> tables that caused havoc. >> >> Tony Thigpen >> >> Seymour J Metz wrote on 9/1/20 3:30 PM: >> > Typically the new features reqiured by a level set were added over several >> > generations, and each generation added more than one feature. >> > >> > >> > -- >> > Shmuel (Seymour J.) Metz >> > http://mason.gmu.edu/~smetz3 >> > >> > >> > >> > From: IBM Mainframe Discussion List on behalf >> > of Tony Thigpen >> > Sent: Tuesday, September 1, 2020 3:25 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Architectural Level Sets >> > >> > IBM has had several Architectural Level Set points where there were >> > significant changes to the CPU that prevented earlier operating systems >> > from running on them. >> > >> > What CPU's were involved with each level, and what was the real >> > underlying item changed on the CPU that forced a new level? (Let's keep >> > it limited to z990 and newer.) >> > >> > >> > Tony Thigpen >> > >> > -- >> > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
370 supported DAS (the code is in MVS3.8J). 43XX running MVS supported DAS also. 4381 could have up to 64M of main storage... Joe On Tue, Sep 1, 2020 at 4:26 PM Mike Schwab wrote: > Well, XA+ machines only supported 4K pages / 1M segments and not 2K > pages / 64K segments. Then DAS and Access register additions. The > 43xx series only supported a single virtual address space, like > DOS/VSE. 3090s were the only processors to support Vector > instructions, and op codes were re-used in z series. > > On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: > > > > I was thinking more along the lines of things that prevented earlier > > operating systems from even IPLing on newer boxes. Such as z13 is the > > last processor to have ESA/390 mode. I also have it in my head that at > > some point there were changes to the page size and virtual storage > > tables that caused havoc. > > > > Tony Thigpen > > > > Seymour J Metz wrote on 9/1/20 3:30 PM: > > > Typically the new features reqiured by a level set were added over > several generations, and each generation added more than one feature. > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > > > > > > > From: IBM Mainframe Discussion List on > behalf of Tony Thigpen > > > Sent: Tuesday, September 1, 2020 3:25 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Architectural Level Sets > > > > > > IBM has had several Architectural Level Set points where there were > > > significant changes to the CPU that prevented earlier operating systems > > > from running on them. > > > > > > What CPU's were involved with each level, and what was the real > > > underlying item changed on the CPU that forced a new level? (Let's keep > > > it limited to z990 and newer.) > > > > > > > > > Tony Thigpen > > > > > > -- > > > 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 > > > > -- > 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: Architectural Level Sets
Well, XA+ machines only supported 4K pages / 1M segments and not 2K pages / 64K segments. Then DAS and Access register additions. The 43xx series only supported a single virtual address space, like DOS/VSE. 3090s were the only processors to support Vector instructions, and op codes were re-used in z series. On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: > > I was thinking more along the lines of things that prevented earlier > operating systems from even IPLing on newer boxes. Such as z13 is the > last processor to have ESA/390 mode. I also have it in my head that at > some point there were changes to the page size and virtual storage > tables that caused havoc. > > Tony Thigpen > > Seymour J Metz wrote on 9/1/20 3:30 PM: > > Typically the new features reqiured by a level set were added over several > > generations, and each generation added more than one feature. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > > > From: IBM Mainframe Discussion List on behalf of > > Tony Thigpen > > Sent: Tuesday, September 1, 2020 3:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Architectural Level Sets > > > > IBM has had several Architectural Level Set points where there were > > significant changes to the CPU that prevented earlier operating systems > > from running on them. > > > > What CPU's were involved with each level, and what was the real > > underlying item changed on the CPU that forced a new level? (Let's keep > > it limited to z990 and newer.) > > > > > > Tony Thigpen > > > > -- > > 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 -- 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: Architectural Level Sets
I was thinking more along the lines of things that prevented earlier operating systems from even IPLing on newer boxes. Such as z13 is the last processor to have ESA/390 mode. I also have it in my head that at some point there were changes to the page size and virtual storage tables that caused havoc. Tony Thigpen Seymour J Metz wrote on 9/1/20 3:30 PM: Typically the new features reqiured by a level set were added over several generations, and each generation added more than one feature. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Thigpen Sent: Tuesday, September 1, 2020 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Architectural Level Sets IBM has had several Architectural Level Set points where there were significant changes to the CPU that prevented earlier operating systems from running on them. What CPU's were involved with each level, and what was the real underlying item changed on the CPU that forced a new level? (Let's keep it limited to z990 and newer.) Tony Thigpen -- 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: Architectural Level Sets
Typically the new features reqiured by a level set were added over several generations, and each generation added more than one feature. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Thigpen Sent: Tuesday, September 1, 2020 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Architectural Level Sets IBM has had several Architectural Level Set points where there were significant changes to the CPU that prevented earlier operating systems from running on them. What CPU's were involved with each level, and what was the real underlying item changed on the CPU that forced a new level? (Let's keep it limited to z990 and newer.) Tony Thigpen -- 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
Architectural Level Sets
IBM has had several Architectural Level Set points where there were significant changes to the CPU that prevented earlier operating systems from running on them. What CPU's were involved with each level, and what was the real underlying item changed on the CPU that forced a new level? (Let's keep it limited to z990 and newer.) Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dovetail/Kirk Wolf?
Unfortunately, the Tomcat security interface classes often change between major releases and we are required to refit and test our SAF/RACF Security classes. On Tue, Sep 1, 2020 at 10:15 AM David Crayford wrote: > Steve, > > Maybe you could just also just supply the jar files so a full install > isn't required. A script to install would be a nice to have. > > On 2020-09-01 10:59 PM, Steve Goetze wrote: > > Trust me, it's better for everybody that Kirk deleted his twitter > account. > > > > To the OP - we've updated T:Z Quickstart for Tomcat to support the > upstream > > version 9.0.37. You can download the new release here: > > https://dovetail.com/downloads/tomcat/index.html > > > > If you have any issues or questions, please post on our community forum: > > https://dovetail.com/forum > > > > Regards, > > Steve Goetze > > Dovetailed Technologies > > www.dovetail.com > > > > > > On Tue, Sep 1, 2020 at 8:47 AM scott Ford wrote: > > > >> Wolf, wolf . > >> > >> We here have a pack including a Siberian, welcome to the pack ... > >> > >> Scott, now retired > >> > >> On Tue, Sep 1, 2020 at 8:24 AM Joe Monk wrote: > >> > >>> Dave, > >>> > >>> > >>> > >>> I would encourage you to check whether websockets are enabled on the > T:Z > >>> > >>> product. If not, nothing to worry about, and you can report the issue > to > >>> > >>> your security team as mitigated. > >>> > >>> > >>> > >>> Joe > >>> > >>> > >>> > >>> On Tue, Sep 1, 2020 at 6:00 AM Jousma, David < > >>> > >>> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > >>> > >>> > >>> > Thanks Kirk, > Totally understand re free z/OS distribution. Any plans to port a > >> newer > version? We've got a lot of time/effort in our Tech support wiki, > and > >>> all > >>> > the documentation that is in it. I don’t want to be forced to shut > it > down due to the reported vulnerability. Is there a RYO path to newer > version on z/OS with SAF support? > >> > _ > Dave Jousma > AVP | Director, Technology Engineering > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > Rapids, MI 49546 > 616.653.8429 | fax: 616.653.2717 > -Original Message- > From: IBM Mainframe Discussion List On > >> Behalf > Of Kirk Wolf > Sent: Monday, August 31, 2020 5:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dovetail/Kirk Wolf? > **CAUTION EXTERNAL EMAIL** > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > I'm fine (and utterly amused that my status might be inferred from my > cancelled Twitter account :-) > We wanted to look into your Tomcat request from Thursday before > >>> responding. > >>> > We do offer a z/OS distribution of Tomcat free without support, so > sometimes other things take precedence. > To confirm: Tomcat 8.5.6 is the last z/OS integration build that we > currently offer. > Kirk Wolf > Dovetailed Technologies > >> > https://protect2.fireeye.com/url?k=c6be0738-9ae2f337-c6be2da0-0cc47a33347c-7966752b50828413=http://dovetail.com/ > On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma < > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > Has anyone heard from Kirk Wolf recently? I don’t see much action > >> on > his > > community forum over at dovetail.com either. > > I ask because we have been running Dovetail’s port of TOMCAT on Z > >> that > > has the SAF interfaces added to it to house our internal team > documentation. > > We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails > > site, and our security folks have identified a security > > vulnerability(WebSocket DoS CVE-2020-13935) in all releases older > >> than > 9.0.37. > >> -- > > 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
Re: sort join keys not correctly working
> As the 1'st file has leading zeros for some of the records 2.73 are > not getting matched . could someone please let me know how to get > this addressed? Ron, If you looked up the Joinkeys description for FIELDS in the DFSORT Application programming guide you would have found this The keys will be treated as binary, so they must be "normalized". For example, if the keys are actually zoned decimal, they must have all C and D signs, or all F and D signs. You can use an INREC statement in JNF1CNTL and/or JNF2CNTL to normalize the keys for the F1 file and/or F2 file, respectively, if appropriate. Here is the link to that piece of documentation. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.icea100/ice2ca_JOINKEYS_statements.htm So convert your Unsigned Free Format (UFF) to Binary format using INREC and put it at the end of the record (F1 at position 3422 and F2 at position 40) using JNF1CNTL and JNF2CNTL statements respectively). Then adjust the positions on the FIELDS statement to point to the new Binary fields. Coming to the control cards, if you are interested ONLY in the matched record, why bother about unmatched records from F1 and F2 ? By default DFSORT JOINKEYS would always write out only MATCHED records unless you have a JOIN statement. Thanks, Kolusu DFSORT Development IBM Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
sort join keys not correctly working
Hello We are using DFSORT and we have a input file as follows File- 1 (key 12 bytes) 998962 998969 998976 99905 99921 0001 0002 0003 0006 0007 0016 0019 0073 0092 File -2 (key 12 bytes 2 73 18 100907 101007 101749 101887 101894 101903 102081 102093 102101 Sort card coded JOINKEYS FILES=F1,FIELDS=(1,12,A) JOINKEYS FILES=F2,FIELDS=(1,12,A) REFORMAT FIELDS=(F1:01,3421,F2:01,39,?) OPTION COPY JOIN UNPAIRED,F1,F2 OUTFIL FNAMES=BOTH, INCLUDE=(3461,1,CH,EQ,C'B'),BUILD=(1,515,516:3435,12,528:528,2894) As the 1'st file has leading zeros for some of the records 2.73 are not getting matched . could someone please let me know how to get this addressed? Regards Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dovetail/Kirk Wolf?
Steve, Maybe you could just also just supply the jar files so a full install isn't required. A script to install would be a nice to have. On 2020-09-01 10:59 PM, Steve Goetze wrote: Trust me, it's better for everybody that Kirk deleted his twitter account. To the OP - we've updated T:Z Quickstart for Tomcat to support the upstream version 9.0.37. You can download the new release here: https://dovetail.com/downloads/tomcat/index.html If you have any issues or questions, please post on our community forum: https://dovetail.com/forum Regards, Steve Goetze Dovetailed Technologies www.dovetail.com On Tue, Sep 1, 2020 at 8:47 AM scott Ford wrote: Wolf, wolf . We here have a pack including a Siberian, welcome to the pack ... Scott, now retired On Tue, Sep 1, 2020 at 8:24 AM Joe Monk wrote: Dave, I would encourage you to check whether websockets are enabled on the T:Z product. If not, nothing to worry about, and you can report the issue to your security team as mitigated. Joe On Tue, Sep 1, 2020 at 6:00 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: Thanks Kirk, Totally understand re free z/OS distribution. Any plans to port a newer version? We've got a lot of time/effort in our Tech support wiki, and all the documentation that is in it. I don’t want to be forced to shut it down due to the reported vulnerability. Is there a RYO path to newer version on z/OS with SAF support? _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Monday, August 31, 2020 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dovetail/Kirk Wolf? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I'm fine (and utterly amused that my status might be inferred from my cancelled Twitter account :-) We wanted to look into your Tomcat request from Thursday before responding. We do offer a z/OS distribution of Tomcat free without support, so sometimes other things take precedence. To confirm: Tomcat 8.5.6 is the last z/OS integration build that we currently offer. Kirk Wolf Dovetailed Technologies https://protect2.fireeye.com/url?k=c6be0738-9ae2f337-c6be2da0-0cc47a33347c-7966752b50828413=http://dovetail.com/ On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: Has anyone heard from Kirk Wolf recently? I don’t see much action on his community forum over at dovetail.com either. I ask because we have been running Dovetail’s port of TOMCAT on Z that has the SAF interfaces added to it to house our internal team documentation. We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails site, and our security folks have identified a security vulnerability(WebSocket DoS CVE-2020-13935) in all releases older than 9.0.37. -- 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 -- 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: Dovetail/Kirk Wolf?
Trust me, it's better for everybody that Kirk deleted his twitter account. To the OP - we've updated T:Z Quickstart for Tomcat to support the upstream version 9.0.37. You can download the new release here: https://dovetail.com/downloads/tomcat/index.html If you have any issues or questions, please post on our community forum: https://dovetail.com/forum Regards, Steve Goetze Dovetailed Technologies www.dovetail.com On Tue, Sep 1, 2020 at 8:47 AM scott Ford wrote: > Wolf, wolf . > > We here have a pack including a Siberian, welcome to the pack ... > > Scott, now retired > > On Tue, Sep 1, 2020 at 8:24 AM Joe Monk wrote: > > > Dave, > > > > > > > > I would encourage you to check whether websockets are enabled on the T:Z > > > > product. If not, nothing to worry about, and you can report the issue to > > > > your security team as mitigated. > > > > > > > > Joe > > > > > > > > On Tue, Sep 1, 2020 at 6:00 AM Jousma, David < > > > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > > > Thanks Kirk, > > > > > > > > > > Totally understand re free z/OS distribution. Any plans to port a > newer > > > > > version? We've got a lot of time/effort in our Tech support wiki, and > > all > > > > > the documentation that is in it. I don’t want to be forced to shut it > > > > > down due to the reported vulnerability. Is there a RYO path to newer > > > > > version on z/OS with SAF support? > > > > > > > > > > > > > > > > > > _ > > > > > Dave Jousma > > > > > AVP | Director, Technology Engineering > > > > > > > > > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > > > > > Rapids, MI 49546 > > > > > 616.653.8429 | fax: 616.653.2717 > > > > > > > > > > > > > > > -Original Message- > > > > > From: IBM Mainframe Discussion List On > Behalf > > > > > Of Kirk Wolf > > > > > Sent: Monday, August 31, 2020 5:23 PM > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > Subject: Re: Dovetail/Kirk Wolf? > > > > > > > > > > **CAUTION EXTERNAL EMAIL** > > > > > > > > > > **DO NOT open attachments or click on links from unknown senders or > > > > > unexpected emails** > > > > > > > > > > I'm fine (and utterly amused that my status might be inferred from my > > > > > cancelled Twitter account :-) > > > > > > > > > > We wanted to look into your Tomcat request from Thursday before > > responding. > > > > > We do offer a z/OS distribution of Tomcat free without support, so > > > > > sometimes other things take precedence. > > > > > To confirm: Tomcat 8.5.6 is the last z/OS integration build that we > > > > > currently offer. > > > > > > > > > > Kirk Wolf > > > > > Dovetailed Technologies > > > > > > > > > > > > > https://protect2.fireeye.com/url?k=c6be0738-9ae2f337-c6be2da0-0cc47a33347c-7966752b50828413=http://dovetail.com/ > > > > > > > > > > On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma < > > > > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > > > > > Has anyone heard from Kirk Wolf recently? I don’t see much action > on > > > > > his > > > > > > community forum over at dovetail.com either. > > > > > > > > > > > > I ask because we have been running Dovetail’s port of TOMCAT on Z > that > > > > > > has the SAF interfaces added to it to house our internal team > > > > > documentation. > > > > > > We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails > > > > > > site, and our security folks have identified a security > > > > > > vulnerability(WebSocket DoS CVE-2020-13935) in all releases older > than > > > > > 9.0.37. > > > > > > > > > > > > > -- > > > > > > 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
Re: setting up CSSMTP to use TLS-SSL
Brian, I do use AT-TLS with CSSMTP to our internal e-mail relay. For the keyring, you need to add the CA's that have signed the ssl cert for the server. If the e-mail server is using a self-signed certificate, you need them to send a copy of it (only the public portion) and it has to be added as a certificate authority. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setting up CSSMTP to use TLS-SSL
We have ours setup to use TLS from CSSMTP to an internal Proofpoint mail server. We have Secure set to Yes in the CSSMTP config and then use Policy Agent (AT-TLS) to handle the handshake. David -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Monday, August 31, 2020 11:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: setting up CSSMTP to use TLS-SSL So does this all mean that (currently) no one on the list uses TLS-SSL to forward their mail from CSSMTP to the target mail server? Brian -- 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: Dovetail/Kirk Wolf?
Wolf, wolf . We here have a pack including a Siberian, welcome to the pack ... Scott, now retired On Tue, Sep 1, 2020 at 8:24 AM Joe Monk wrote: > Dave, > > > > I would encourage you to check whether websockets are enabled on the T:Z > > product. If not, nothing to worry about, and you can report the issue to > > your security team as mitigated. > > > > Joe > > > > On Tue, Sep 1, 2020 at 6:00 AM Jousma, David < > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Thanks Kirk, > > > > > > Totally understand re free z/OS distribution. Any plans to port a newer > > > version? We've got a lot of time/effort in our Tech support wiki, and > all > > > the documentation that is in it. I don’t want to be forced to shut it > > > down due to the reported vulnerability. Is there a RYO path to newer > > > version on z/OS with SAF support? > > > > > > > > > > _ > > > Dave Jousma > > > AVP | Director, Technology Engineering > > > > > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > > > Rapids, MI 49546 > > > 616.653.8429 | fax: 616.653.2717 > > > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On Behalf > > > Of Kirk Wolf > > > Sent: Monday, August 31, 2020 5:23 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Dovetail/Kirk Wolf? > > > > > > **CAUTION EXTERNAL EMAIL** > > > > > > **DO NOT open attachments or click on links from unknown senders or > > > unexpected emails** > > > > > > I'm fine (and utterly amused that my status might be inferred from my > > > cancelled Twitter account :-) > > > > > > We wanted to look into your Tomcat request from Thursday before > responding. > > > We do offer a z/OS distribution of Tomcat free without support, so > > > sometimes other things take precedence. > > > To confirm: Tomcat 8.5.6 is the last z/OS integration build that we > > > currently offer. > > > > > > Kirk Wolf > > > Dovetailed Technologies > > > > > > > https://protect2.fireeye.com/url?k=c6be0738-9ae2f337-c6be2da0-0cc47a33347c-7966752b50828413=http://dovetail.com/ > > > > > > On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma < > > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > Has anyone heard from Kirk Wolf recently? I don’t see much action on > > > his > > > > community forum over at dovetail.com either. > > > > > > > > I ask because we have been running Dovetail’s port of TOMCAT on Z that > > > > has the SAF interfaces added to it to house our internal team > > > documentation. > > > > We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails > > > > site, and our security folks have identified a security > > > > vulnerability(WebSocket DoS CVE-2020-13935) in all releases older than > > > 9.0.37. > > > > > > > > -- > > > > 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 > > > > > > > -- > > 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: setting up CSSMTP to use TLS-SSL
I think the most common approach is to have CSSMTP send the mail to an enterprise (internal) mail server and let it take care of security going out to the internet. On 8/31/20 11:33 PM, Brian Westerman wrote: So does this all mean that (currently) no one on the list uses TLS-SSL to forward their mail from CSSMTP to the target mail server? Brian -- 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: Dovetail/Kirk Wolf?
Dave, I would encourage you to check whether websockets are enabled on the T:Z product. If not, nothing to worry about, and you can report the issue to your security team as mitigated. Joe On Tue, Sep 1, 2020 at 6:00 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Thanks Kirk, > > Totally understand re free z/OS distribution. Any plans to port a newer > version? We've got a lot of time/effort in our Tech support wiki, and all > the documentation that is in it. I don’t want to be forced to shut it > down due to the reported vulnerability. Is there a RYO path to newer > version on z/OS with SAF support? > > > _ > Dave Jousma > AVP | Director, Technology Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > Rapids, MI 49546 > 616.653.8429 | fax: 616.653.2717 > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Kirk Wolf > Sent: Monday, August 31, 2020 5:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dovetail/Kirk Wolf? > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > I'm fine (and utterly amused that my status might be inferred from my > cancelled Twitter account :-) > > We wanted to look into your Tomcat request from Thursday before responding. > We do offer a z/OS distribution of Tomcat free without support, so > sometimes other things take precedence. > To confirm: Tomcat 8.5.6 is the last z/OS integration build that we > currently offer. > > Kirk Wolf > Dovetailed Technologies > > https://protect2.fireeye.com/url?k=c6be0738-9ae2f337-c6be2da0-0cc47a33347c-7966752b50828413=http://dovetail.com/ > > On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma < > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > Has anyone heard from Kirk Wolf recently? I don’t see much action on > his > > community forum over at dovetail.com either. > > > > I ask because we have been running Dovetail’s port of TOMCAT on Z that > > has the SAF interfaces added to it to house our internal team > documentation. > > We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails > > site, and our security folks have identified a security > > vulnerability(WebSocket DoS CVE-2020-13935) in all releases older than > 9.0.37. > > > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dovetail/Kirk Wolf?
I sincerely hope that one's existence and status isn't based on being a twit-wit. Only an iron-clad contract guaranteeing large sums of hard, spendable currency on a regular schedule would entice me to join such an anti-social "social network". Subject: Re: Dovetail/Kirk Wolf? If one does not use Twitter does one truly exist? Bruce Lightsey Database Manager MS Department of Information Technology Services 601-432-8144 | www.its.ms.gov DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dovetail/Kirk Wolf?
I suspect if you install Tomcat 9.0.37 and copy the zos-*.jars from Dovetails tomcat it will work. On 2020-09-01 6:58 PM, Jousma, David wrote: Thanks Kirk, Totally understand re free z/OS distribution. Any plans to port a newer version? We've got a lot of time/effort in our Tech support wiki, and all the documentation that is in it. I don’t want to be forced to shut it down due to the reported vulnerability. Is there a RYO path to newer version on z/OS with SAF support? _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Monday, August 31, 2020 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dovetail/Kirk Wolf? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I'm fine (and utterly amused that my status might be inferred from my cancelled Twitter account :-) We wanted to look into your Tomcat request from Thursday before responding. We do offer a z/OS distribution of Tomcat free without support, so sometimes other things take precedence. To confirm: Tomcat 8.5.6 is the last z/OS integration build that we currently offer. Kirk Wolf Dovetailed Technologies https://protect2.fireeye.com/url?k=c6be0738-9ae2f337-c6be2da0-0cc47a33347c-7966752b50828413=http://dovetail.com/ On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: Has anyone heard from Kirk Wolf recently? I don’t see much action on his community forum over at dovetail.com either. I ask because we have been running Dovetail’s port of TOMCAT on Z that has the SAF interfaces added to it to house our internal team documentation. We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails site, and our security folks have identified a security vulnerability(WebSocket DoS CVE-2020-13935) in all releases older than 9.0.37. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dovetail/Kirk Wolf?
Thanks Kirk, Totally understand re free z/OS distribution. Any plans to port a newer version? We've got a lot of time/effort in our Tech support wiki, and all the documentation that is in it. I don’t want to be forced to shut it down due to the reported vulnerability. Is there a RYO path to newer version on z/OS with SAF support? _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Monday, August 31, 2020 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dovetail/Kirk Wolf? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I'm fine (and utterly amused that my status might be inferred from my cancelled Twitter account :-) We wanted to look into your Tomcat request from Thursday before responding. We do offer a z/OS distribution of Tomcat free without support, so sometimes other things take precedence. To confirm: Tomcat 8.5.6 is the last z/OS integration build that we currently offer. Kirk Wolf Dovetailed Technologies https://protect2.fireeye.com/url?k=c6be0738-9ae2f337-c6be2da0-0cc47a33347c-7966752b50828413=http://dovetail.com/ On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Has anyone heard from Kirk Wolf recently? I don’t see much action on his > community forum over at dovetail.com either. > > I ask because we have been running Dovetail’s port of TOMCAT on Z that > has the SAF interfaces added to it to house our internal team documentation. > We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails > site, and our security folks have identified a security > vulnerability(WebSocket DoS CVE-2020-13935) in all releases older than 9.0.37. > > -- > 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
JES2 £DPATH Output Misleading
Morning Listers I am implementing a new NJE topology which involves multiple hops through store-and-forward nodes to the final destination - NODEA to NODEB to NODEC to NODED. I have existing direct connectivity between NODEA and NODED which I am looking to replace with the longer route (the reasons for which are not up for debate). On NJEDEF I have RESTMODE=100,RESTMAX=800 for all participating systems. I think I only need RESTMAX=600. My query is around the £DPATH command, or rather its output. From NODEA £DPATH(NODEB),LONG shows a connection with resistance of 200. £DPATH(NODEC),LONG shows a connection with resistance of 400. Similar commands on NODEB/NODEC show that there is connectivity with the expected resistance. For £DPATH(NODED),LONG I only see the direct path with resistance of 200 and not the long route with a resistance of 600. I was expecting to see the long route also shown in the output of £DPATH but I can't determine from the manual whether that is a reasonable expectation. Anyone had any experience in this area? Any IBM JES2 folks listening? Thanks Andrew Metcalfe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
