Re: [Public] RE: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4
Maybe this is a better pointer https://www.ibm.com/docs/en/zos/2.3.0?topic=ulero-storage#clstora Stay Safe > On Oct 3, 2022, at 21:07, Doug Shupe wrote: > > Possibly the WSCLEAR LE runtime option? > > https://www.ibm.com/support/pages/wsclear-runtime-option-vs-cobol-ii-not-supported-current-cics-releases > > Just a thought as you said old cobol and CICS. > Best Regards, Doug > > >>> On Oct 3, 2022, at 15:59, Usher, Darrold >>> <014f796d148d-dmarc-requ...@listserv.ua.edu> wrote: >>> >> What is your CEECOPT STORAGE Setting in SYS1.PARMLIB(CEEPRM00)? >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Crusty Old Guy >> Sent: Monday, October 3, 2022 2:19 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4 >> >> I have further information from the programmers. >> >> These are CICS programs. The programs do not initialize their working >> storage. I'm told everything is fine under z/OS 2.1. >> >> Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know >> why it runs OK under 2.1. >> I have not found an answer for them in the migration guide. Can anyone help? >> >> COG >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send email >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> USAA Classification: Public >> >> Disclaimer: This email and any attachments are the property of USAA and may >> contain confidential and/or privileged material. If you are not the intended >> recipient, any use, disclosure or copying of this email or any attachments >> is unauthorized. If you received this email in error, please immediately >> notify the sender and delete the email and any attachments from your >> computer. >> >> >> -- >> 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: [Public] RE: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4
Possibly the WSCLEAR LE runtime option? https://www.ibm.com/support/pages/wsclear-runtime-option-vs-cobol-ii-not-supported-current-cics-releases Just a thought as you said old cobol and CICS. Best Regards, Doug > On Oct 3, 2022, at 15:59, Usher, Darrold > <014f796d148d-dmarc-requ...@listserv.ua.edu> wrote: > > What is your CEECOPT STORAGE Setting in SYS1.PARMLIB(CEEPRM00)? > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Crusty Old Guy > Sent: Monday, October 3, 2022 2:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4 > > I have further information from the programmers. > > These are CICS programs. The programs do not initialize their working > storage. I'm told everything is fine under z/OS 2.1. > > Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know > why it runs OK under 2.1. > I have not found an answer for them in the migration guide. Can anyone help? > > COG > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > USAA Classification: Public > > Disclaimer: This email and any attachments are the property of USAA and may > contain confidential and/or privileged material. If you are not the intended > recipient, any use, disclosure or copying of this email or any attachments is > unauthorized. If you received this email in error, please immediately notify > the sender and delete the email and any attachments from your computer. > > > -- > 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: COBOL - z/OS 2.1 vs 2.4
I would suggest checking your LE parms between the two systems. It almost feels like there is a difference in the setting between to two systems around how CICS is handled. Paul Feller GTS Mainframe Technical Support From: IBM Mainframe Discussion List On Behalf Of Crusty Old Guy Sent: Monday, October 3, 2022 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL - z/OS 2.1 vs 2.4 I have further information from the programmers. These are CICS programs. The programs do not initialize their working storage. I'm told everything is fine under z/OS 2. 1. Under z/OS 2. 4, they are getting garbage in the COMMAREA. They want I have further information from the programmers. These are CICS programs. The programs do not initialize their working storage. I'm told everything is fine under z/OS 2.1. Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know why it runs OK under 2.1. I have not found an answer for them in the migration guide. Can anyone help? COG -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto: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: COBOL - z/OS 2.1 vs 2.4
Interesting business model. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert Prins Sent: Monday, October 3, 2022 3:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL - z/OS 2.1 vs 2.4 https://www.fiverr.com/devoutoccamist/answer-your-questions-regarding-zos-and-the-mainframe-3a9c And are you going to share the proceeds. Do you by any chance work for a company that provides support to companies that have cancelled their support contracts with IBM? Just asking, I've opted not to sign a contract with them... Robert On Fri, 30 Sept 2022 at 13:24, Crusty Old Guy wrote: > We have a client with loadmods that are ancient. Some are very ancient. > All of those loadmods are currently running under z/OS 2.1. > Under z/OS 2.4, some of these loadmods are abending. Others are creating > incorrect output. > > What could account for this behavior? What has changed between 2.1 & 2.4? > > Regards, > Crusty Old Guy > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather <https://prino.neocities.org/index.html> Some REXX code for use on z/OS <https://prino.neocities.org/zOS/zOS-Tools.html> -- 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: COBOL - z/OS 2.1 vs 2.4
https://www.fiverr.com/devoutoccamist/answer-your-questions-regarding-zos-and-the-mainframe-3a9c And are you going to share the proceeds. Do you by any chance work for a company that provides support to companies that have cancelled their support contracts with IBM? Just asking, I've opted not to sign a contract with them... Robert On Fri, 30 Sept 2022 at 13:24, Crusty Old Guy wrote: > We have a client with loadmods that are ancient. Some are very ancient. > All of those loadmods are currently running under z/OS 2.1. > Under z/OS 2.4, some of these loadmods are abending. Others are creating > incorrect output. > > What could account for this behavior? What has changed between 2.1 & 2.4? > > Regards, > Crusty Old Guy > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather <https://prino.neocities.org/index.html> Some REXX code for use on z/OS <https://prino.neocities.org/zOS/zOS-Tools.html> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL - z/OS 2.1 vs 2.4
Can you post a CEDF trace? Joe On Mon, Oct 3, 2022 at 2:19 PM Crusty Old Guy wrote: > I have further information from the programmers. > > These are CICS programs. The programs do not initialize their working > storage. I'm told everything is fine under z/OS 2.1. > > Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to > know why it runs OK under 2.1. > I have not found an answer for them in the migration guide. Can anyone > help? > > COG > > -- > 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
[Public] RE: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4
What is your CEECOPT STORAGE Setting in SYS1.PARMLIB(CEEPRM00)? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Crusty Old Guy Sent: Monday, October 3, 2022 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: COBOL - z/OS 2.1 vs 2.4 I have further information from the programmers. These are CICS programs. The programs do not initialize their working storage. I'm told everything is fine under z/OS 2.1. Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know why it runs OK under 2.1. I have not found an answer for them in the migration guide. Can anyone help? COG -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN USAA Classification: Public Disclaimer: This email and any attachments are the property of USAA and may contain confidential and/or privileged material. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is unauthorized. If you received this email in error, please immediately notify the sender and delete the email and any attachments from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL - z/OS 2.1 vs 2.4
Level of CIS would be in play. This is likely one of the changes in how and where memory gets allocated and initialized in 2.2 or 2.3 on. There are some compatibility DIAGxx parms > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Crusty Old Guy > Sent: Monday, October 03, 2022 12:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL - z/OS 2.1 vs 2.4 > > [EXTERNAL EMAIL] > > I have further information from the programmers. > > These are CICS programs. The programs do not initialize their working > storage. I'm told everything is fine under z/OS 2.1. > > Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to > know why it runs OK under 2.1. > I have not found an answer for them in the migration guide. Can anyone > help? > > COG > > -- > 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: COBOL - z/OS 2.1 vs 2.4
I have further information from the programmers. These are CICS programs. The programs do not initialize their working storage. I'm told everything is fine under z/OS 2.1. Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to know why it runs OK under 2.1. I have not found an answer for them in the migration guide. Can anyone help? COG -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
[Public] RE: EXTERNAL: COBOL - z/OS 2.1 vs 2.4
We encountered a fair amount of U4088-63 abends with z/OS v2.4. Relinks were required to ensure called utilities by the application were LE-compliant. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Crusty Old Guy Sent: Friday, September 30, 2022 8:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: COBOL - z/OS 2.1 vs 2.4 We have a client with loadmods that are ancient. Some are very ancient. All of those loadmods are currently running under z/OS 2.1. Under z/OS 2.4, some of these loadmods are abending. Others are creating incorrect output. What could account for this behavior? What has changed between 2.1 & 2.4? Regards, Crusty Old Guy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN USAA Classification: Public Disclaimer: This email and any attachments are the property of USAA and may contain confidential and/or privileged material. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is unauthorized. If you received this email in error, please immediately notify the sender and delete the email and any attachments from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL - z/OS 2.1 vs 2.4
On 9/30/2022 6:14 AM, Crusty Old Guy wrote: Under z/OS 2.4, some of these loadmods are abending. Others are creating incorrect output. What could account for this behavior? A bug. Open a case with IBM support. -- 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: COBOL - z/OS 2.1 vs 2.4
Paul Gorlinsky wrote: >There are some notes that the language environment is dropping off some >prior versions of COBOL. Do you have a link to the IBM Language Environment documentation to which you are referring? I'm not sure what you're referring to. >IBM is requiring V6 COBOL on the most current version of z/OS of which LE >is a major component. Although I don't speak for IBM (as a reminder), no, IBM isn't doing that. IBM requires that you adhere to your contractual agreements with IBM including license agreements (and otherwise respect applicable legal provisions such as copyrights and patents), but that's about as far as it goes. Let's separate runtime from compilation. In terms of runtime IBM continues to support COBOL programs compiled with older, unsupported COBOL compilers. If you suspect a defect in the z/OS runtime you should open a problem case with IBM. Fierce dedication to backward compatibility is one of the hallmarks of this platform, and to my knowledge this IBM commitment is enduring. In terms of compilers IBM recommends that you run an IBM supported compiler. Currently this means Enterprise COBOL Version 6 (recent release, preferably current release) unless you have a support extension for an older release. You may wish to recompile older programs for performance and other reasons using the newer compiler (or to use Automatic Binary Optimizer), but you are not required to do so. — — — — — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL - z/OS 2.1 vs 2.4
Did someone move them from a PDS to a PDSE? On 9/30/22 09:14, Crusty Old Guy wrote: We have a client with loadmods that are ancient. Some are very ancient. All of those loadmods are currently running under z/OS 2.1. Under z/OS 2.4, some of these loadmods are abending. Others are creating incorrect output. What could account for this behavior? What has changed between 2.1 & 2.4? Regards, Crusty Old Guy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL - z/OS 2.1 vs 2.4
Why? Both the linkage editor and the binder accept input from a load module. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gorlinsky [p...@atsmigrations.com] Sent: Friday, September 30, 2022 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL - z/OS 2.1 vs 2.4 I wonder if the Delink program on CBT-TAPE could be used to pull the code apart and rebind it? -- 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: COBOL - z/OS 2.1 vs 2.4
I wonder if the Delink program on CBT-TAPE could be used to pull the code apart and rebind it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL - z/OS 2.1 vs 2.4
Overlay? Scatter load? I thought that those were already dead, but still worth checking. What are the ABEND details, including reason code and message? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Crusty Old Guy [devoutoccam...@gmail.com] Sent: Friday, September 30, 2022 9:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: COBOL - z/OS 2.1 vs 2.4 We have a client with loadmods that are ancient. Some are very ancient. All of those loadmods are currently running under z/OS 2.1. Under z/OS 2.4, some of these loadmods are abending. Others are creating incorrect output. What could account for this behavior? What has changed between 2.1 & 2.4? Regards, Crusty Old Guy -- 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: COBOL - z/OS 2.1 vs 2.4
Please be more specific. Are these BATCH or CICS? What version of COBOL or other compiler? There are some notes that the language environment is dropping off some prior versions of COBOL. CICS is another issue. IBM is requiring V6 COBOL on the most current version of z/OS of which LE is a major component. The ABEND will tell all. S806? S878? S80A? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL - z/OS 2.1 vs 2.4
We have a client with loadmods that are ancient. Some are very ancient. All of those loadmods are currently running under z/OS 2.1. Under z/OS 2.4, some of these loadmods are abending. Others are creating incorrect output. What could account for this behavior? What has changed between 2.1 & 2.4? Regards, Crusty Old Guy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
Sorry I wasn't able to jump in several days ago. Back to back customer briefings, conferences, and long travel has made it hard for me to catch up on IBM-MAIN until this weekend. I certainly don't want to beat a dead horse on this - I know that this has been well hashed at this point and this topic has probably closed itself out. Some points did come to my mind which I heard faintly brushed on, which I think were not fully surfaced. Because I'd like this archive to contain some additional information for those searching on it in the future, I'll offer two points: 1) Long Jumps: although I know several customers that make long jumps with the help of experienced z/OS staff, and they do go successfully, it still is not a "done deal" and should not be done as a matter of course. The risk for problems is non-zero, and you would be on a path that is not well-grooved. If any problems indeed did surface, the client should be fully prepared to take a "fix forward" posture, especially if a fallback is attempted (which is not something that we are prepared to try to re-create in IBM Service and then fix). What kind of problems could you see? Well, if you look at all the V2.2 coexistence PTFs for V2.4 that's a pretty good list of what you might see doing a V2.1 to V2.4 upgrade. I'd take that list and do individual research on each and every one of those APARs if you want to plan a Long Jump. It doesn't matter if that was a New Function APAR or a release FMID that introduced the function causing the incompatibility. In a V2.4 ServerPac, it doesn't matter how that function got there; it is there in the target libraries. If it needed coexistence (or "preconditioning"), it might affect your Long Jump and you need to understand what it does and try to avoid those behaviors before a fallback, if it is possible to do so. btw: I'm sure it's obvious, but I'd take the V2.1 -> V2.3 Workflow and add the steps for the V2.3 -> V2.4 Workflow to give me the full list of changes to expect. 2) Sysplex: I think it is clear in the z/OS Planning for Installation book, that coexistence, fallback, and migration are for both concurrently shared (sysplex) and not concurrently shared (single single time-sliced) environments: "Coexistence occurs when two or more systems at different software levels share resources. The resources could be shared at the same time by different systems in a multisystem configuration, or they could be shared over a period of time by the same system in a single-system configuration." To me, the appender's question about a sysplex told us about his environment, but it didn't make a difference. It still fell into the "coexistence, fallback, migration" support category and needed coexistence APARs (or minimally, research into coexistence APARs) to know what to plan for. -Marna WALLE z/OS System Install and Upgrade IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
I'd like to try to summarize "best practices" when it comes to software release upgrades. For perspective, most of the rest of the software world doesn't offer coexistence and fallback support, especially to the degree IBM does with its z/OS and z/OS-based products. It's quite fortunate and special that we have formal, tested, supported, dependable coexistence and fallback. So my first advice is to exploit that serious safety advantage to the fullest, i.e. to stay within IBM supported release combinations and to stay at least reasonably current in your deployed software releases insofar as possible. Moreover, there's no longer any Single Version Charge (SVC) constraints, so go right ahead and order the latest releases and get them into your "Development" environments promptly. In the hopefully rare cases when there's a deviation from the previous paragraph, you have two basic choices to move forward: 1. Plan and execute "back to back" (or even "back to back to back..."), stepwise release upgrades, staying within IBM's supported release combinations through each step. 2. Leap forward using fewer steps, as few as one "big" step. I have encountered a few cases when Path #1 simply wasn't feasible. Path #2 can be the best available choice, with all factors carefully weighed and considered. The farther back you are in release levels, the more likely Path #2 will be the best available path. If you choose Path #2, or if you at least need help determining the best path forward, then it's well worth enlisting some deep expertise -- talented people who specialize in "big jump" upgrades who know the likely risks and how to mitigate them. Thereafter, those same talented people likely could also help you stay at least reasonably current in your releases. You *can* move forward, and if you'd like some initial advice you can send me an e-mail if you'd like. As one story, I worked with a particular government agency that ran their mainframe for just over 18 years in productive, essential service with literally zero hardware, operating system, and middleware release upgrades -- not even a PTF installation. Yes, 18 years! Their operator console ran Windows 98, for example -- the original Windows 98, not Windows 98 Second Edition. :-) They recently upgraded to supported hardware and software, and the new environment works well and immediately delivered significant end user improvements. Everyone involved at least intends never to repeat that episode of extreme inertia, but even in that incredible case we found a reasonable way forward via Path #2. It turned out the single biggest technical challenge was to move data to the new mainframe reliably and quickly enough to fit within an "acceptable" (but still uncomfortable) planned outage window, but after a lot of research and effort that challenge was conquered. Please don't do what that agency did (er, didn't do), with the possible exception of a computer museum demonstration. Finally, if you don't have a Parallel Sysplex, please at least consider it. As a reminder, you can have (and it's quite common to have) a Parallel Sysplex on a single machine. You can decide how much or how little you want to exploit Parallel Sysplex, subsystem by subsystem. For example, if all you really urgently need is MQ shared queues so that you can keep receiving messages during a short interval when you're bouncing CICS, then start with that feature. If an IBM z/OS-based product supports Parallel Sysplex (most do), then that support is included already at no additional charge with your licenses. Parallel Sysplex is a wonderful, unique capability to manage and deliver upgrades without requiring service interruptions. It's another incredibly useful "safety net." Parallel Sysplex shouldn't be scary, but if it is for you at the moment, then reach out for help. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Until Jan 27 2020. https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/8/897/ENUS919-038/index.html=en_locale=en Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Dana Mitchell > Sent: 06 September, 2019 16:28 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Does anyone know for sure how long V2R3 will remain orderable? My guess > would be end of September 2019 when 2.4 goes GA? > > Sorry, my question was sort of buried underneath a previous reply. > > Dana > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Ahh, I see now. If you look closely a the toleration PTFs you will see that they are specific issues which do not apply to the vast majority of migrations and normally not to non-sysplex migrations at all, (excluding hardware toleration PTFs which didn't apply to the OP's question, but could indeed have caused problems depending on the hardware in use). You don't see too many software toleration ones for non-sysplex, if any at all. When you do, it's normally something that is changed in the FAR newer release which, in some intermediate release, may have had the option of disabling the change in format, but that at the "current" release no longer has that dual ability, so the solution (sometimes) was to add the capability to the older release, but when IBM decided to make life simple (for themselves) they simply decided that they would only need to support that backward toleration for a small number of releases (that's where the N+ stuff came from originally), but even that is not really well supported any more and you are risking a lot to rely on the N+ designation alone. I will grant you that you can very easily screw yourself by updating to a new release of something that changed the format of (for instance the MCDS in HSM), and then when you try to fall back, you find that you can no longer read that MCDS from the older HSM. The solution is normally not to update the MCDS at the new release, but "sometimes" it's not as straightforward as that and may even require a parameter which is no longer documented, or may no longer even be supported. That's not the case for the OP, and is actually beyond the scope of what can be covered in a forum like this, but in the case of the OP, since he is going from z/OS2.1 to z/OS 2.4, and is not even using a SYSPLEX, there is absolutely nothing for him to have to worry about. The complaint I had was when someone who appeared to have very little migration experience of the type needed to respond to the OP's question, responded anyway with some FUD that made it seem as if the poor OP (who is running a separate LPAR only (no sysplex)) would be playing with fire to attempt to "jump" to 2.4 from 2.1, (which was totally incorrect). Brian On Sun, 8 Sep 2019 20:04:11 +, Seymour J Metz wrote: >> I don't know what you are basing the historical accuracy of this on. I'm basing them on toleration PTFs that IBM has issued in the past and on IBM documentation of various migrations. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Saturday, September 7, 2019 10:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I don't know what you are basing the historical accuracy of this on. I perform these conversions literally all the time and I have not (even once) come across a fallback issue or a scenario that wasn't supported especially with respect to the OP's question. As I have stated many times, sysplex migrations are not the same as the OP is involved in, but would not necessarily be a drawback to a long jump at all. Obviously, no one is silly enough to try to add OS/390 and z/OS 2.4 to the same sysplex, there are LOTs of rules for sysplex levels and states. That's still not a problem with migrations, it's just a problem if you think you can migrate within that same sysplex. That doesn't keep you from having a second (new) sysplex that is being converted and then migrating the data from the old sysplex to the new one. It's a doable, although a slightly more complex migration that is not really any harder than a single system migration, but as you are dealing with multiple systems it will make the process a bit more complex and can take a little longer. In a scenario where sysplexes are concerned, and you want to stay within the sysplex at all times, you may indeed want or be tempted to install an interim system and migrate the individual systems within the sysplex to it, then to the final destination release. I have actually been exposed to sites that literally jumped 4 times and took 3 years and 6 to 8 people years just to stay within the sysplex, (and they still failed to get it right), and I have seen several that jumped a couple times and it worked fine (for them), but I would never have suggested that they HAD to do it that way (or "forced" them to do it my way for that matter). While you can certainly do the multi-jump, there are faster and easier ways to accomplish the jump, but as I have stated before, the OP didn't ask that question, so it's silly to discuss any details of process(es) that "might" be followed by some sites as opposed to ways that "other" sites might decide to go. I have absolutely zero issues with someone wanting to install the interim system and in essence m
Re: z/OS 2.1 to 2.4
I understand, I'll try to do better. I normally forget to click the little quote thing at the bottom until it's too late. Brian On Sun, 8 Sep 2019 17:34:00 +, Jesse 1 Robinson wrote: >Brian, you seem to have a habit of replying to notes with very specific >allusions but *no* quoted text at all. This is just one example. > >-- Who is 'you'? >-- What is 'this'? > >Not everyone is happy with everyone else's style of reply, but your posts >frequently leave me wondering what you're talking about. > >-Original Messa-e- >From: IBM Mainframe Discussion List On Behalf Of >Brian Westerman >Sent: Saturday, September 7, 2019 7:38 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: z/OS 2.1 to 2.4 [EXTERNAL] > >I don't know what you are basing the historical accuracy of this on... > > > > >-- >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: z/OS 2.1 to 2.4 [EXTERNAL]
> I don't know what you are basing the historical accuracy of this on. I'm basing them on toleration PTFs that IBM has issued in the past and on IBM documentation of various migrations. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Saturday, September 7, 2019 10:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I don't know what you are basing the historical accuracy of this on. I perform these conversions literally all the time and I have not (even once) come across a fallback issue or a scenario that wasn't supported especially with respect to the OP's question. As I have stated many times, sysplex migrations are not the same as the OP is involved in, but would not necessarily be a drawback to a long jump at all. Obviously, no one is silly enough to try to add OS/390 and z/OS 2.4 to the same sysplex, there are LOTs of rules for sysplex levels and states. That's still not a problem with migrations, it's just a problem if you think you can migrate within that same sysplex. That doesn't keep you from having a second (new) sysplex that is being converted and then migrating the data from the old sysplex to the new one. It's a doable, although a slightly more complex migration that is not really any harder than a single system migration, but as you are dealing with multiple systems it will make the process a bit more complex and can take a little longer. In a scenario where sysplexes are concerned, and you want to stay within the sysplex at all times, you may indeed want or be tempted to install an interim system and migrate the individual systems within the sysplex to it, then to the final destination release. I have actually been exposed to sites that literally jumped 4 times and took 3 years and 6 to 8 people years just to stay within the sysplex, (and they still failed to get it right), and I have seen several that jumped a couple times and it worked fine (for them), but I would never have suggested that they HAD to do it that way (or "forced" them to do it my way for that matter). While you can certainly do the multi-jump, there are faster and easier ways to accomplish the jump, but as I have stated before, the OP didn't ask that question, so it's silly to discuss any details of process(es) that "might" be followed by some sites as opposed to ways that "other" sites might decide to go. I have absolutely zero issues with someone wanting to install the interim system and in essence migrate twice, it's their life, they should use it up whatever way they want. My issues come when someone tells an OP that it absolutely MUST be done that way or scare them with the "or bad things could happen" type of warnings. Maybe you are confusing a migration with some sort of scenario where you think you will pick up your old OS/390 JES2 spool and checkpoint dataset(s) and try to use them under z/OS 2.4. Obviously that is not going to work and certainly would not work falling back to OS/390. The migration and fallback process for this is normally to offload the data and reload it when you go one way or the other, you can also (often) just NJE the data back and forth (assuming both systems are active), but the important thing is that you work this stuff out ahead of time, and installing another operating system level is rarely (if ever) going to be necessary or even provide you with a way to do it. In most cases, when you aren't in a sysplex, there is very little to be worried about (data sharing-wise). Just because you can't share something like the JES2 checkpoint or the spool itself is not a drawback or a failure in a migration, it's just something that you have to plan for and handle. Sometimes, (keeping with the JES scenario) if you are falling back far enough, there is no way to reload the data back to the spool. In a situation such as that, it's extremely easy to offload the data to some other medium other than the standard JES offload format (a writer for instance), or merely make sure whatever is in the spool when you leave is something that you no longer want or need to keep. Conversions (as opposed to migrations) have a similar set of issues. For instance, if you are using Adabas 7 and are running OS/390, you might want to install Adabas 8 when you install z/OS 2.4, and go through that conversion. Some people have that as an objective, some don't as they are happy to stay with Adabas 7 (for now). That's something that the individual will need to deal with when they build their plan. Is it "better" to convert to Adabas 8, sure it is, is it necessary, "no", is it a good idea, you bet, but it's an optional thing, not something that is necessarily forced on the site just because some guy on IBM-MAIN said that you MUST co
Re: z/OS 2.1 to 2.4
Brian, you seem to have a habit of replying to notes with very specific allusions but *no* quoted text at all. This is just one example. -- Who is 'you'? -- What is 'this'? Not everyone is happy with everyone else's style of reply, but your posts frequently leave me wondering what you're talking about. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Saturday, September 7, 2019 7:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: z/OS 2.1 to 2.4 [EXTERNAL] I don't know what you are basing the historical accuracy of this on... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
, but that doesn't mean that EVERYONE must never to a multi-jump, just because I said so. In this case, it's a fact that the OP doesn't "have" to do a multi-jump to support 100% of their systems and sub-systems. Period, slam-dunk, drop-the-mic, end of dispute and never should have been a question about the response to his question. The OP doesn't need to worry about ever ordering or even thinking about z/OS 2.3 to get to z/OS 2.4 from z/OS 2.1 in s disconnected LPAR environment. This is sort of like selling your car and trying to keep the seats. In some cases that might actually work, but it's not something you can guarantee or bet the farm on and in almost all cases it's not even necessary because you will likely get new seats with your new car. In this OP's case, the new seats will look and feel just like his old seats only without all of the holes and patched holes. (reading this again, car seats seems really dumb, but I can't think of a better analogy right now:) Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
You didn't quote the context, so I don't know what the OP's environment was, but there have, historically, been DASD fallback issues both within and between sysplexes. Has there been a JES level set in z/OS V2 that changed the checkpoint or SPOOL structure automatically rather than upon explicit request, e.g., $ACTIVATE, $T, $T CKPTDEF, $T SPOOLDEF? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Friday, September 6, 2019 6:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Not between 2.1 and 2.4. The incompatibilities are between JES level sets. Those kinds of problems (when things are actively shared through the sysplex) are where being a sysplex can make a difference, the solution in those cases is that you end up with two sysplexes for the duration of your conversion. The basic process still remains about the same for a long jump with a sysplex and one without, it's just a bit more complex because as you are populating the new sysplex, you are depopulating the old one. In this case though, the OP is in LPAR mode with (maybe or maybe not) shared resources (DASD, tapes, etc,) but not a sysplex. The issue came up when someone, who should have known better, stepped in and suggested that if they did not install an intermediate release (i.e. 2.2 or 2.3) that they could be asking for trouble. The suggestion was ludicrous. 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: z/OS 2.1 to 2.4 [EXTERNAL]
Not between 2.1 and 2.4. The incompatibilities are between JES level sets. Those kinds of problems (when things are actively shared through the sysplex) are where being a sysplex can make a difference, the solution in those cases is that you end up with two sysplexes for the duration of your conversion. The basic process still remains about the same for a long jump with a sysplex and one without, it's just a bit more complex because as you are populating the new sysplex, you are depopulating the old one. In this case though, the OP is in LPAR mode with (maybe or maybe not) shared resources (DASD, tapes, etc,) but not a sysplex. The issue came up when someone, who should have known better, stepped in and suggested that if they did not install an intermediate release (i.e. 2.2 or 2.3) that they could be asking for trouble. The suggestion was ludicrous. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
You are mixing a problem that can happen from adding a single APAR at any time. It's not really applicable to the length of the (long or short) JUMP. A stand alone LPAR (which this OP has) is not going to be incompatible in a way that makes installing an intermediate level make any sense. Even in your case, it was something that you accidentally added to the new system without first having that support on the old system. Unfortunately it can happen, but that's what the migration guide(s) and due diligence are for, and sometimes even that can get rained on by IBM. I didn't say that they guy should blindly jump into the newer release without making sure that he addressed all of the changes. In your case, it really didn't have anything to do with the length of the migration jump (i.e. N+anything), and it's unfortunate, but that kind of thing can happen just putting on next month's put tape or the next RSU. It's something that you have to be wary of, but installing a intermediate operating system between 2.1 and 2.4 would not have changed the outcome of your problem in any way. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
It's not recent, but there have been changes in, e.g., catalog, SPOOL, that had toleration issues. In some cases, e.g., SPOOL, the new formats were not used until the installation explicitly activated them. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Friday, September 6, 2019 3:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Well, you know what they say about assumptions. That definitely applies to your assumptions here. How did you get into ACM, did you buy a membership or something?:) I really don't mean to sound flippant or like I'm trying to degrade your abilities or anything, but you don't seriously believe all that stuff you wrote, do you? There hasn't been a totally incompatible dataset level change sent out for a good many years, and by that I actually mean so far this millennium), and IBM is not about to change that kind of thing in a simple release change. Something like that would result in a version change at the very least if not a complete OS name change. Remember that this op is converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible exception of ISAM and some old DL/1 structures that would have to be addressed ahead of time even that conversion is doable if you discard the processor change necessary and only count the data. Did you possibly forget that one of the things that sets the IBM mainframe apart from everything else is the VERY long pedigree of backwards compatibility? The whole idea of the way IBM manages z/OS is not going to be placed at jeopardy, just because they want to come out with a new dot.release. :) If it was meant to "scare" the OP into going through a completely unnecessary installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. Almost everything you said was (at best) unwarranted. It was almost like reading something in one of those "this is an example of fake news" sites. If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the dasd. I should know, I still do conversions for people from OS/390 to z/OS 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle the two systems at the same time, the dasd and the datasets do. Doing "long jump" migrations is almost always a hardware issue, not a software or dataset issue. If you want to perform unnecessary installations on your time at your site, that's completely up to you, but when someone asks a serious question and you come up with a bunch of FUD, it just serves to undermine what I thought was supposed to be the purpose of this site, which I had thought was to provide a forum for people to get help and exchange ideas, not to try to scare them with half baked assumptions and leading questions which seem to be written solely for no useful purpose. I am positive that I have likely performed more long jump conversions than you, and I would be willing to bet that I have performed in just the past two years more operating systems conversions period, than you have performed in your entire professional life as a systems programmer, if you even are one, which based on your response I'm not quite certain of. While doing a lot of migrations and conversions doesn't make me perfect, it does mean that I am (a lot) less likely to be wrong about this than you are. Again, I know it sounds harsh, but this is one of my hot buttons. When people try to talk about IBM's N+ "suggestion" as if it's anything other than that, "a suggestion". About 10% of the long jump migrations I have performed were done through IBM for their client sites, not for any of our existing clients. I have yet to have a failure to complete a migration on time and as promised. Again, I'm very sorry if I have insulted you in any way, that was not my intention, but I am really and truly surprised at the lack of restraint and knowledge about what is involved in a conversion or migration or even in simply sharing dasd and other resources shown in your response. So, please excuse my harsh response, but I didn't want the OP to think that you knew anything about what you were saying. While you did phrase everything as if you were merely trying to point out possibilities that I may have overlooked, you were just so far from correct that I could not allow it to go UN-commented upon. Sorry, 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: z/OS 2.1 to 2.4 [EXTERNAL]
https://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?q45=Z497063S01245B61~B227540X25949K69~Z966844T77753Y85 z/OS 2.2 Available Sep 30 2015, End of Marketing Jan 29 2018 End of Service Sep 30 2020. z/OS 2.1 was 2 years earlier. z/OS 2.3 was / should be 2 years later. z/OS 2.4 should be 4 years later. So z/OS 2.3 should be orderable for 2019 and most of Jan 2020. On Fri, Sep 6, 2019 at 2:39 PM Carmen Vitullo wrote: > > I believe this link is still valid > > > > > https://www.ibm.com/support/home/pages/lifecycle/?from=index_a > > > > > > > > Carmen Vitullo > > - Original Message - > > From: "Dana Mitchell" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Friday, September 6, 2019 9:27:55 AM > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Does anyone know for sure how long V2R3 will remain orderable? My guess would > be end of September 2019 when 2.4 goes GA? > > Sorry, my question was sort of buried underneath a previous reply. > > Dana > > -- > 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: z/OS 2.1 to 2.4 [EXTERNAL]
Carmen, It does not show an End of Marketing date for z/OS 2.3 nor an end of support. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, September 06, 2019 10:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I believe this link is still valid https://www.ibm.com/support/home/pages/lifecycle/?from=index_a Carmen Vitullo - Original Message - From: "Dana Mitchell" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, September 6, 2019 9:27:55 AM Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
I believe this link is still valid https://www.ibm.com/support/home/pages/lifecycle/?from=index_a Carmen Vitullo - Original Message - From: "Dana Mitchell" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, September 6, 2019 9:27:55 AM Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
I have not checked, but that is consistent with prior IBM practices. If you want z/OS 2.3 order immediately! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dana Mitchell Sent: Friday, September 6, 2019 9:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Probably somewhere around then. If you need it, just order it. Even if you never use it. _ Dave Jousma AVP | Manager, Systems 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 Dana Mitchell Sent: Friday, September 6, 2019 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Brian, So I get the fervor, but might be a little harsh? By "dataset", not sure he was talking about dataset structure, but maybe the contents of any dataset. For example, and this happened to me, and this all happened within the same z/OS release, but would just as easily occur on a z/OS long jump with no easy way to go back...A year ago, due to SNAFU with IBM hold data being incorrect for certain DFSMSHSM maintenance, a conditioning/toleration PTF was missed. The feature "enabling" PTF was IPL'd into one of systems in the sysplex that shares the HSM CDS's which happily started writing new format data into the CDS. Wasn’t noticed until the next day when data that was migrated on that updated system could not be recalled on a down leveled system, and HSM was taking errors/dumps. This is just one example In the long jump scenario, that if the need to fall back were to be utilized, HSM functions would be broken. And if HSM was the one doing the CDS backup's recovery of those might be a problem too. This is just one real life example, there could be many more. There is a *risk* of doing the long jump, mostly with regards to ability to fall back, and being honest, in all my years, we have had to fall back maybe one time.Best advice is don’t get into a position where you are out of support. _ Dave Jousma AVP | Manager, Systems 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 Brian Westerman Sent: Friday, September 6, 2019 3:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Well, you know what they say about assumptions. That definitely applies to your assumptions here. How did you get into ACM, did you buy a membership or something?:) I really don't mean to sound flippant or like I'm trying to degrade your abilities or anything, but you don't seriously believe all that stuff you wrote, do you? There hasn't been a totally incompatible dataset level change sent out for a good many years, and by that I actually mean so far this millennium), and IBM is not about to change that kind of thing in a simple release change. Something like that would result in a version change at the very least if not a complete OS name change. Remember that this op is converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible exception of ISAM and some old DL/1 structures that would have to be addressed ahead of time even that conversion is doable if you discard the processor change necessary and only count the data. Did you possibly forget that one of the things that sets the IBM mainframe apart from everything else is the VERY long pedigree of backwards compatibility? The whole idea of the way IBM manages z/OS is not going to be placed at jeopardy, just because they want to come out with a new dot.release. :) If it was meant to "scare" the OP into going through a completely unnecessary installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. Almost everything you said was (at best) unwarranted. It was almost like reading something in one of those "this is an example of fake news" sites. If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the dasd. I should know, I still do conversions for people from OS/390 to z/OS 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle the two systems at the same time, the dasd and the datasets do. Doing "long jump" migrations is almost always a hardware issue, not a software or dataset issue. If you want to perform unnecessary installations on your time at your site, that's completely up to you, but when someone asks a serious question and you come up with a bunch of FUD, it just serves to undermine what I thought was supposed to be the purpose of this site, which I had thought was to provide a forum for people to get help and exchange ideas, not to try to scare them with half baked assumptions and leading questions which seem to be written solely for no useful purpose. I am positive that I have likely performed more long jump conversions than you, and I would be willing to bet that I have performed in just the past two years more operating systems conversions period, than you have performed in your entire professional life as a systems programmer, if you even are one, which based on your response I'm not quite certain of. While doing a lot of migrations and conversions doesn't make me perfect, it does mean that I am (a
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Two DASD incompatibilities I know of from OS/390. Dropping ISAM and adding EAVs DSCBs to the VTOC. PDSE V2 I'm not sure of. Possibly the various extended attributes. Drop the ISAM first and don't use the new facilities until you are certain you don't need to go back. On Fri, Sep 6, 2019 at 7:41 AM Brian Westerman wrote: > > Well, you know what they say about assumptions. That definitely applies to > your assumptions here. How did you get into ACM, did you buy a membership or > something?:) > > I really don't mean to sound flippant or like I'm trying to degrade your > abilities or anything, but you don't seriously believe all that stuff you > wrote, do you? There hasn't been a totally incompatible dataset level change > sent out for a good many years, and by that I actually mean so far this > millennium), and IBM is not about to change that kind of thing in a simple > release change. Something like that would result in a version change at the > very least if not a complete OS name change. Remember that this op is > converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS > 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible > exception of ISAM and some old DL/1 structures that would have to be > addressed ahead of time even that conversion is doable if you discard the > processor change necessary and only count the data. Did you possibly forget > that one of the things that sets the IBM mainframe apart from everything else > is the VERY long pedigree of backwards compatibility? > > The whole idea of the way IBM manages z/OS is not going to be placed at > jeopardy, just because they want to come out with a new dot.release. :) > > If it was meant to "scare" the OP into going through a completely unnecessary > installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. > Almost everything you said was (at best) unwarranted. It was almost like > reading something in one of those "this is an example of fake news" sites. > > If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the > dasd. I should know, I still do conversions for people from OS/390 to z/OS > 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle > the two systems at the same time, the dasd and the datasets do. Doing "long > jump" migrations is almost always a hardware issue, not a software or dataset > issue. > > If you want to perform unnecessary installations on your time at your site, > that's completely up to you, but when someone asks a serious question and you > come up with a bunch of FUD, it just serves to undermine what I thought was > supposed to be the purpose of this site, which I had thought was to provide a > forum for people to get help and exchange ideas, not to try to scare them > with half baked assumptions and leading questions which seem to be written > solely for no useful purpose. > > I am positive that I have likely performed more long jump conversions than > you, and I would be willing to bet that I have performed in just the past two > years more operating systems conversions period, than you have performed in > your entire professional life as a systems programmer, if you even are one, > which based on your response I'm not quite certain of. While doing a lot of > migrations and conversions doesn't make me perfect, it does mean that I am (a > lot) less likely to be wrong about this than you are. > > Again, I know it sounds harsh, but this is one of my hot buttons. When > people try to talk about IBM's N+ "suggestion" as if it's anything other than > that, "a suggestion". About 10% of the long jump migrations I have performed > were done through IBM for their client sites, not for any of our existing > clients. I have yet to have a failure to complete a migration on time and as > promised. > > Again, I'm very sorry if I have insulted you in any way, that was not my > intention, but I am really and truly surprised at the lack of restraint and > knowledge about what is involved in a conversion or migration or even in > simply sharing dasd and other resources shown in your response. > > So, please excuse my harsh response, but I didn't want the OP to think that > you knew anything about what you were saying. While you did phrase > everything as if you were merely trying to point out possibilities that I may > have overlooked, you were just so far from correct that I could not allow it > to go UN-commented upon. > > Sorry, > > Brian > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists.
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Well, you know what they say about assumptions. That definitely applies to your assumptions here. How did you get into ACM, did you buy a membership or something?:) I really don't mean to sound flippant or like I'm trying to degrade your abilities or anything, but you don't seriously believe all that stuff you wrote, do you? There hasn't been a totally incompatible dataset level change sent out for a good many years, and by that I actually mean so far this millennium), and IBM is not about to change that kind of thing in a simple release change. Something like that would result in a version change at the very least if not a complete OS name change. Remember that this op is converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible exception of ISAM and some old DL/1 structures that would have to be addressed ahead of time even that conversion is doable if you discard the processor change necessary and only count the data. Did you possibly forget that one of the things that sets the IBM mainframe apart from everything else is the VERY long pedigree of backwards compatibility? The whole idea of the way IBM manages z/OS is not going to be placed at jeopardy, just because they want to come out with a new dot.release. :) If it was meant to "scare" the OP into going through a completely unnecessary installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. Almost everything you said was (at best) unwarranted. It was almost like reading something in one of those "this is an example of fake news" sites. If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the dasd. I should know, I still do conversions for people from OS/390 to z/OS 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle the two systems at the same time, the dasd and the datasets do. Doing "long jump" migrations is almost always a hardware issue, not a software or dataset issue. If you want to perform unnecessary installations on your time at your site, that's completely up to you, but when someone asks a serious question and you come up with a bunch of FUD, it just serves to undermine what I thought was supposed to be the purpose of this site, which I had thought was to provide a forum for people to get help and exchange ideas, not to try to scare them with half baked assumptions and leading questions which seem to be written solely for no useful purpose. I am positive that I have likely performed more long jump conversions than you, and I would be willing to bet that I have performed in just the past two years more operating systems conversions period, than you have performed in your entire professional life as a systems programmer, if you even are one, which based on your response I'm not quite certain of. While doing a lot of migrations and conversions doesn't make me perfect, it does mean that I am (a lot) less likely to be wrong about this than you are. Again, I know it sounds harsh, but this is one of my hot buttons. When people try to talk about IBM's N+ "suggestion" as if it's anything other than that, "a suggestion". About 10% of the long jump migrations I have performed were done through IBM for their client sites, not for any of our existing clients. I have yet to have a failure to complete a migration on time and as promised. Again, I'm very sorry if I have insulted you in any way, that was not my intention, but I am really and truly surprised at the lack of restraint and knowledge about what is involved in a conversion or migration or even in simply sharing dasd and other resources shown in your response. So, please excuse my harsh response, but I didn't want the OP to think that you knew anything about what you were saying. While you did phrase everything as if you were merely trying to point out possibilities that I may have overlooked, you were just so far from correct that I could not allow it to go UN-commented upon. Sorry, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Since no one else has said it, aren't you are forgetting your entire DASD farm with all its system control block structures embedded within VTOCs, VVDSs, Catalogs, JES datasets, and some other individual data sets? DASD "Sharing" doesn't just have to be within a sysplex, because sharing doesn't have to be concurrent. Does IBM now guarantee that any changes to these DASD-resident structures are down-level compatible with all prior releases of z/OS with no toleration PTFs even required, or does this only apply if you are within a supported upgrade jump? If toleration PTFs are required, what does this say about system versions no longer supported for maintenance? You IPL all your processors with back-level versions of z/OS after your DASD has been touched by a later version system, then you are sharing all those structures between those two versions of z/OS, even if not concurrently, whether you run a sysplex or not. Perhaps it takes a deliberate use of new features to force an incompatibility, perhaps not. Maybe some change or update could occur just by putting a volume online or opening a data set from the new system, maybe not. One would certainly hope such compatibility issues would be prominently discussed in the migration documentation for one of the later versions of z/OS, but just because these are rare occurrences doesn't mean it shouldn't be a concern and at least researched. My assumption was always if you go beyond a "supported" jump, IBM doesn't test those scenarios and you are on your own. Perhaps you are familiar enough with z/OS 2.1 through 2.4 to be confident there are DASD-resident control block issues with such a jump, but you seem to be implying that without a sysplex, arbitrary z/OS level jumps could have no compatibility concerns and compatibility research is irrelevant. That certainly has not been true in the past. Joel C. Ewing On 9/4/19 1:23 AM, Brian Westerman wrote: > why? He said that there is no sysplex involved, just what is it that he > would not be compatible with in a fall back scenario between 2.1 and 2.4? > You would be pretty hard pressed to find something that would cause them an > issue, so long as the hardware is compatible with 2.4 they are good to go. I > also believe in being prepared for anything, but there are some things that > are a waste of time. If he were running a sysplex, even then he would > "probably" still be okay, but it's not an issue for him to even have to think > about. > > Brian > > > -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
SMPE with current HOLDDATA received: REPORT MISSINGFIX ZONES() FIXCAT( IBM.Coexistence.z/OS.V2R2, IBM.Coexistence.z/OS.V2R3). Does anyone know for sure how long V2R3 is orderable? My guess would be end of September 2019 when 2.4 is GA? Dana On Fri, 30 Aug 2019 17:19:57 +, David Spiegel wrote: >Hi Paul, >The buzzword you are hinting at is called "Toleration Maintenance". > >Regards, >David > >On 2019-08-30 12:39, Feller, Paul wrote: >> Sorry if my wording was off a little. But yes the idea is to apply any z/OS >> 2.1 fixes needed related to support of z/OS 2.3. That would get you nearer >> to a system that might allow for fall back from z/OS 2.4. I'm sure IBM >> would suggest a two step approach. Install z/OS 2.3 as soon as possible and >> then go to z/OS 2.4 later. >> >> Thanks.. >> >> Paul Feller >> AGT Mainframe Technical Support >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
why? He said that there is no sysplex involved, just what is it that he would not be compatible with in a fall back scenario between 2.1 and 2.4? You would be pretty hard pressed to find something that would cause them an issue, so long as the hardware is compatible with 2.4 they are good to go. I also believe in being prepared for anything, but there are some things that are a waste of time. If he were running a sysplex, even then he would "probably" still be okay, but it's not an issue for him to even have to think about. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
N+anything is almost completely irrelevant in a non-sysplex environment. There really is very little to be incompatible that would make a difference to a fallback. The part that really matters in non-sysplex is that you actually leave yourself with something to "fall back" to. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
Fallback is hugely important if it becomes necessary. We once had to bring a back-level system up two levels to be current. There was documented fallback from N+1 to N and from N+2 to N+1, but explicitly no fallback from N+2 to N. So we did two full updates in one weekend: first from N to N+1; let it run for a while to be sure; then up to N+2. Nothing went wrong, but I always believed we did it the right way. Consider also coexistence in a sysplex environment. . . 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 Brian Westerman Sent: Friday, August 30, 2019 10:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: z/OS 2.1 to 2.4 [EXTERNAL] Yes, you need to have current maintenance on your old 2.1 system, but your ability to fall back based on what you have stated in your response makes it so that your fallback (if necessary) will not be an issue for you. Depending on your product mix, I think that SAG might have a simple work around for you for allowusekeycsa(yes), and so long as you are using the Version 8 SVC (which still supports version 7 Adabas products like cluster services and parallel services) you will be okay for all but a small number of products. There are some products that you will have to update but they are likely minor in your case (older EntireX Brokers), at least they should be because very little depends on the actual release of the broker. There are some special PPT entries you have to perform as well that depend on your products, but there is an SAG page that tell you all of them. The only problem you will hit is with Natural, which needs to be at 4.2.4 to not need the allowuserkeycsa(yes), this will require SAG's ASM to do this, but I think it's free. I have performed several upgrades to old levels of Adabas (back to version 7.1) for just the Natural component, and they are truly dead simple, and if done correctly won't require you to recatalog everything in the natural libraries either (at least not manually depending on how far back you are). Plus, again with proper planning, you have a fallback that you can implement within a few minutes. Remember if you upgrade Natural, you still have to install ASM. The suggested solution SAG is to install ASM Authorized Services Manager with all versions of Natural that use the older buffer pools and want to convert to allowuserkeycsa(no). Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: z/OS 2.1 to 2.4 [EXTERNAL]
ASM, in this context anyway, likely refers to the Natural Authorized Services Manager, which I believe (I've been out of SAG product support for many years now) is shipped in base mainframe Natural. Rather than starting yet more SAG address spaces though, I would convert the Natural Global BP to Local BPs. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Saturday, August 31, 2019 11:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: z/OS 2.1 to 2.4 [EXTERNAL] ASM is Adabas Parallel Services, I'm not sure why they didn't call it APS, but possibly they already had one by that name. ASM provides Compression, decompression, format buffer translation, sorting, retrieving, searching and updating operations all occur in parallel. So it gives better distribution of your workload across the available processors. You might already be running it and just don't know it, or just don't have the extra address space running that Natural will need. 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: z/OS 2.1 to 2.4 [EXTERNAL]
To the OP. I will concur with the earlier recommendation to (at least) order z/OS 2.3. Just in case. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 30, 2019 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
Still n-2 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Friday, August 30, 2019 5:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 As long as you don't have any USERKEYCSA or USERKEYCAD applications to remediate, you will probably be ok. As IBM has removed support for that in 2.4. What is the official IBM stance? N-2 or N-3? I don't recall. I'll be ordering 2.4 this fall as well. _ Dave Jousma AVP | Manager, Systems 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 Gibney, Dave Sent: Thursday, August 29, 2019 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I am considering what upgrade path (if any) I might take from my current z/OS 2.1 RSU 1903 system. I thought that I wouldn't go to 2.3 because I was using SMTP and not CSSMTP. The configuring and implementation of CSSMTP has proven remarkably uneventful. I am not aware of any other gotchas between 2.1 and 2.3 or above. I run four monoplex LPARs. I really don't "coexist" in the sysplex sense. I am considering getting s 2.4 Serverpac when available and making the jump. I do need to be concerned with fallback. I know it's mostly speculation at this point, but does anyone know of z/OS 2.4 fallback maintenance that won't be available for 2.1? Or gotchas I haven't noticed. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **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 ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Is there a mnemonic PGMNAME for that? Thanks, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Brian Westerman To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/09/2019 05:10 Subject:Re: z/OS 2.1 to 2.4 [EXTERNAL] Sent by:IBM Mainframe Discussion List ASM is Adabas Parallel Services, I'm not sure why they didn't call it APS, but possibly they already had one by that name. ASM provides Compression, decompression, format buffer translation, sorting, retrieving, searching and updating operations all occur in parallel. So it gives better distribution of your workload across the available processors. You might already be running it and just don't know it, or just don't have the extra address space running that Natural will need. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
ASM is Adabas Parallel Services, I'm not sure why they didn't call it APS, but possibly they already had one by that name. ASM provides Compression, decompression, format buffer translation, sorting, retrieving, searching and updating operations all occur in parallel. So it gives better distribution of your workload across the available processors. You might already be running it and just don't know it, or just don't have the extra address space running that Natural will need. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Thank you to Brian and others. I am OOO next week. We are actually pretty current on EntireX. I thought I knew all SAG products, but ASM isn't one I remember. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Friday, August 30, 2019 10:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Yes, you need to have current maintenance on your old 2.1 system, but your > ability to fall back based on what you have stated in your response makes it > so that your fallback (if necessary) will not be an issue for you. Depending > on > your product mix, I think that SAG might have a simple work around for you > for allowusekeycsa(yes), and so long as you are using the Version 8 SVC > (which still supports version 7 Adabas products like cluster services and > parallel services) you will be okay for all but a small number of products. > There are some products that you will have to update but they are likely > minor in your case (older EntireX Brokers), at least they should be because > very little depends on the actual release of the broker. There are some > special PPT entries you have to perform as well that depend on your > products, but there is an SAG page that tell you all of them. > > The only problem you will hit is with Natural, which needs to be at 4.2.4 to > not need the allowuserkeycsa(yes), this will require SAG's ASM to do this, > but I think it's free. > > I have performed several upgrades to old levels of Adabas (back to version > 7.1) for just the Natural component, and they are truly dead simple, and if > done correctly won't require you to recatalog everything in the natural > libraries either (at least not manually depending on how far back you are). > Plus, again with proper planning, you have a fallback that you can implement > within a few minutes. Remember if you upgrade Natural, you still have to > install ASM. The suggested solution SAG is to install ASM Authorized Services > Manager with all versions of Natural that use the older buffer pools and want > to convert to allowuserkeycsa(no). > > 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: z/OS 2.1 to 2.4 [EXTERNAL]
Yes, you need to have current maintenance on your old 2.1 system, but your ability to fall back based on what you have stated in your response makes it so that your fallback (if necessary) will not be an issue for you. Depending on your product mix, I think that SAG might have a simple work around for you for allowusekeycsa(yes), and so long as you are using the Version 8 SVC (which still supports version 7 Adabas products like cluster services and parallel services) you will be okay for all but a small number of products. There are some products that you will have to update but they are likely minor in your case (older EntireX Brokers), at least they should be because very little depends on the actual release of the broker. There are some special PPT entries you have to perform as well that depend on your products, but there is an SAG page that tell you all of them. The only problem you will hit is with Natural, which needs to be at 4.2.4 to not need the allowuserkeycsa(yes), this will require SAG's ASM to do this, but I think it's free. I have performed several upgrades to old levels of Adabas (back to version 7.1) for just the Natural component, and they are truly dead simple, and if done correctly won't require you to recatalog everything in the natural libraries either (at least not manually depending on how far back you are). Plus, again with proper planning, you have a fallback that you can implement within a few minutes. Remember if you upgrade Natural, you still have to install ASM. The suggested solution SAG is to install ASM Authorized Services Manager with all versions of Natural that use the older buffer pools and want to convert to allowuserkeycsa(no). Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
I will have all available (and RSU,IBM or Hiper) maintenance on. And, yes fallback is one of my larger concerns. One of my least favorite memories from the early 90s is standalone restore of catalog and SMS control dataset volumes between failed IPLs without proper fallback PTFs on. I think we were making a large jump to MVS/ESA 2.5, but I won't swear to that. Actual SLED and the 3090 took 40 minutes to IPL after and before each failure. It was quite the learning experience and I've tried to do things "right" ever since. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Pommier, Rex > Sent: Friday, August 30, 2019 8:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Tom, > > The idea is to apply 2.1 maintenance that would make 2.1 compatible with > 2.3. Since IBM won't release 2.4 compatibility maintenance for 2.1, if > there's > some that would make 2.1 co-exist with 2.3, that might make it easier for the > OP to make the jump from 2.1 to 2.4. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Marchant > Sent: Friday, August 30, 2019 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: > > Would it be a good thing to at least try to get any z/OS 2.3 compatibility > maintenance applied? > > What does that mean to someone who is running z/OS 2.1? > You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not > the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received > this communication in error, please notify us immediately by replying to this > message and destroy the material in its entirety, whether in electronic or > hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Hi Paul, The buzzword you are hinting at is called "Toleration Maintenance". Regards, David On 2019-08-30 12:39, Feller, Paul wrote: > Sorry if my wording was off a little. But yes the idea is to apply any z/OS > 2.1 fixes needed related to support of z/OS 2.3. That would get you nearer > to a system that might allow for fall back from z/OS 2.4. I'm sure IBM would > suggest a two step approach. Install z/OS 2.3 as soon as possible and then > go to z/OS 2.4 later. > > Thanks.. > > Paul Feller > AGT Mainframe Technical Support > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pommier, Rex > Sent: Friday, August 30, 2019 10:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Tom, > > The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3. > Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's > some that would make 2.1 co-exist with 2.3, that might make it easier for the > OP to make the jump from 2.1 to 2.4. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Tom Marchant > Sent: Friday, August 30, 2019 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: > > Would it be a good thing to at least try to get any z/OS 2.3 compatibility > maintenance applied? > > What does that mean to someone who is running z/OS 2.1? > You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Sorry if my wording was off a little. But yes the idea is to apply any z/OS 2.1 fixes needed related to support of z/OS 2.3. That would get you nearer to a system that might allow for fall back from z/OS 2.4. I'm sure IBM would suggest a two step approach. Install z/OS 2.3 as soon as possible and then go to z/OS 2.4 later. Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, August 30, 2019 10:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Tom, The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3. Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's some that would make 2.1 co-exist with 2.3, that might make it easier for the OP to make the jump from 2.1 to 2.4. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 30, 2019 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
The analogy is with iOS apps. The ones you'd ideally want to use are those where the vendor is beta'ing iOS 13 (actually 13.1.) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "Jousma, David" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Date: 30/08/2019 16:19 Subject: Re: z/OS 2.1 to 2.4 Sent by:IBM Mainframe Discussion List Yea That vendor until recently was still developing on z/OS 1.13 until this summer when they made the jump to 2.2 or maybe 2.3. We are already at V2.3, and really don’t want to skip a release or delay, although that is an option I guess. It's just a bit short sighted on the vendors part to think they can hold their customers hostage like this. _ Dave Jousma AVP | Manager, Systems 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 Mike Schwab Sent: Friday, August 30, 2019 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On Fri, Aug 30, 2019 at 6:49 AM Elardus Engelbrecht wrote: > > Jousma, David wrote: > > >Elardus, yea, I took quite a bit of vacation this summer > [deleted] > Good luck. (While I'm also waiting for z/OS v2.4 to be made > available... ;-D ) > > Groete / Greetings > Elardus Engelbrecht > Well, the quick fix is to Order now and Upgrade soon to z/OS 2.3, then upgrade to 2.4 or 2.5 later on. And advise the application company to suggest this to their other customers. -- 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 **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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Tom, The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3. Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's some that would make 2.1 co-exist with 2.3, that might make it easier for the OP to make the jump from 2.1 to 2.4. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 30, 2019 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
Yea That vendor until recently was still developing on z/OS 1.13 until this summer when they made the jump to 2.2 or maybe 2.3. We are already at V2.3, and really don’t want to skip a release or delay, although that is an option I guess. It's just a bit short sighted on the vendors part to think they can hold their customers hostage like this. _ Dave Jousma AVP | Manager, Systems 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 Mike Schwab Sent: Friday, August 30, 2019 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On Fri, Aug 30, 2019 at 6:49 AM Elardus Engelbrecht wrote: > > Jousma, David wrote: > > >Elardus, yea, I took quite a bit of vacation this summer > [deleted] > Good luck. (While I'm also waiting for z/OS v2.4 to be made > available... ;-D ) > > Groete / Greetings > Elardus Engelbrecht > Well, the quick fix is to Order now and Upgrade soon to z/OS 2.3, then upgrade to 2.4 or 2.5 later on. And advise the application company to suggest this to their other customers. -- 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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
On Fri, Aug 30, 2019 at 6:49 AM Elardus Engelbrecht wrote: > > Jousma, David wrote: > > >Elardus, yea, I took quite a bit of vacation this summer > [deleted] > Good luck. (While I'm also waiting for z/OS v2.4 to be made available... ;-D ) > > Groete / Greetings > Elardus Engelbrecht > Well, the quick fix is to Order now and Upgrade soon to z/OS 2.3, then upgrade to 2.4 or 2.5 later on. And advise the application company to suggest this to their other customers. -- 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: z/OS 2.1 to 2.4
Kees, I fully agree!!! I suspect there are quite a few banks that run this application. When I had a meeting with these folks, I got the impression that there was may the "one guy left" that could delve into the assembler code that supports this. We are escalating the vendor now through our application team that owns the relationship with the vendor. _ Dave Jousma AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM Sent: Friday, August 30, 2019 7:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Yes, then it is the end for this application. But from your description I understand that there must be more customers who will have the 2.4 problem. Is this still no reason for the company to start converting to the current standards? Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jousma, David > Sent: 30 August, 2019 13:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Well, my excitement was short-lived.In the text of OA56180 I read: > > Note: This APAR only applies to user key CSA storage. Both > user key (8-15) SCOPE=COMMON data spaces and the usage of > the CHANGKEY service to change the storage key of common > storage to a key of 8-15 are not affected by this APAR, > and will no longer be supported after z/OS V2R3. > > > Sadly, this application is creating UserKey Common data space and > using it as a high-perf "data base" within the application for their batch > jobs. > I've known about it since IBM enabled reporting via SMF30 records. > > __ > > ___ > Dave Jousma > AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM > Sent: Friday, August 30, 2019 7:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > It does, because 2.4 does not support userkeycsa(yes) anymore. It is > also discussed in the 2.4 migration guide. > > It seems to me the feature will stay, because IBM has fulfilled its > goal to block CSA from being used by unauthorized users with full > read/write access. Now you must selectively permit userkey csa to > users and it is now your responsibility. > > Kees. > > > -Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David > > Sent: 30 August, 2019 12:47 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Yea... Funny thing it is a pretty major/well known Financial > Application > > vendor. Every 4-6 months for the last two years I've been pinging them > > on their status. I just don’t think they understand the gravity of the > > situation they are creating here. > > > > Also, I did open a PMR on this PTF. It's not clear to me that the > > support it discusses continues into V2.4? > > > > > > __ > > > > ___ > > Dave Jousma > > AVP | Manager, Systems 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 Mike Schwab > > Sent: Friday, August 30, 2019 6:34 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > I would ask they cover your cost for this as part of their product, > > since they are the only product you use that needs it. > > > > On Fri,
Re: z/OS 2.1 to 2.4
Jousma, David wrote: >Elardus, yea, I took quite a bit of vacation this summer Grrr, I'm so jealous! ;-) But, I have been in a lot of projects and am now just lurking sniffing out the IBM-MAIN and other listserv posts on their websites... >I always suspend delivery of IBM-MAIL mail during that time, otherwise my >outlook email box would probably fill up. :) Due to quantity of daily posts of IBM-MAIN, I have turned of e-mails from IBM-MAIN. We at our work have a limit of 2GB on the Outlook Server to encourage people to properly manage their mails. (We once have years ago GroupWise (called 'GroupStupid' tongue in cheek) and later Zimbra (called 'Zebra')) Ok, back to this thread - I really hope you can sort out the problem with your vendor. If you have any good news, please be kind to share it. Good luck. (While I'm also waiting for z/OS v2.4 to be made available... ;-D ) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
Yes, then it is the end for this application. But from your description I understand that there must be more customers who will have the 2.4 problem. Is this still no reason for the company to start converting to the current standards? Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jousma, David > Sent: 30 August, 2019 13:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Well, my excitement was short-lived.In the text of OA56180 I read: > > Note: This APAR only applies to user key CSA storage. Both > user key (8-15) SCOPE=COMMON data spaces and the usage of > the CHANGKEY service to change the storage key of common > storage to a key of 8-15 are not affected by this APAR, > and will no longer be supported after z/OS V2R3. > > > Sadly, this application is creating UserKey Common data space and using it > as a high-perf "data base" within the application for their batch jobs. > I've known about it since IBM enabled reporting via SMF30 records. > > __ > ___ > Dave Jousma > AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM > Sent: Friday, August 30, 2019 7:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > It does, because 2.4 does not support userkeycsa(yes) anymore. It is also > discussed in the 2.4 migration guide. > > It seems to me the feature will stay, because IBM has fulfilled its goal > to block CSA from being used by unauthorized users with full read/write > access. Now you must selectively permit userkey csa to users and it is now > your responsibility. > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Jousma, David > > Sent: 30 August, 2019 12:47 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Yea... Funny thing it is a pretty major/well known Financial > Application > > vendor. Every 4-6 months for the last two years I've been pinging them > > on their status. I just don’t think they understand the gravity of the > > situation they are creating here. > > > > Also, I did open a PMR on this PTF. It's not clear to me that the > > support it discusses continues into V2.4? > > > > __ > > > > ___ > > Dave Jousma > > AVP | Manager, Systems 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 Mike Schwab > > Sent: Friday, August 30, 2019 6:34 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > I would ask they cover your cost for this as part of their product, > > since they are the only product you use that needs it. > > > > On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc- > > requ...@listserv.ua.edu> wrote: > > > > > > This is the first I have seen this! That is good news. We have one > > particular Financial Business application, written/distributed by > > outside vendor that I have been bugging now since I put V2.3 in almost 2 > years ago > > to remediate. They still have not yet remediated there code, and I was > > thinking this was going to hold up my implementation. > > > > > > ____________ > > > __ > > > ___ > > > Dave Jousma > > > AVP | Manager, Systems Engineering > > > > > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > > > Rapids, MI 49546 > > > 616.653.8429 | fax: 616.653.2717 > > > > > > > > > >
Re: z/OS 2.1 to 2.4
Well, my excitement was short-lived.In the text of OA56180 I read: Note: This APAR only applies to user key CSA storage. Both user key (8-15) SCOPE=COMMON data spaces and the usage of the CHANGKEY service to change the storage key of common storage to a key of 8-15 are not affected by this APAR, and will no longer be supported after z/OS V2R3. Sadly, this application is creating UserKey Common data space and using it as a high-perf "data base" within the application for their batch jobs. I've known about it since IBM enabled reporting via SMF30 records. _ Dave Jousma AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM Sent: Friday, August 30, 2019 7:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** It does, because 2.4 does not support userkeycsa(yes) anymore. It is also discussed in the 2.4 migration guide. It seems to me the feature will stay, because IBM has fulfilled its goal to block CSA from being used by unauthorized users with full read/write access. Now you must selectively permit userkey csa to users and it is now your responsibility. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jousma, David > Sent: 30 August, 2019 12:47 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Yea... Funny thing it is a pretty major/well known Financial Application > vendor. Every 4-6 months for the last two years I've been pinging them > on their status. I just don’t think they understand the gravity of the > situation they are creating here. > > Also, I did open a PMR on this PTF. It's not clear to me that the > support it discusses continues into V2.4? > > __ > > ___ > Dave Jousma > AVP | Manager, Systems 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 Mike Schwab > Sent: Friday, August 30, 2019 6:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > I would ask they cover your cost for this as part of their product, > since they are the only product you use that needs it. > > On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc- > requ...@listserv.ua.edu> wrote: > > > > This is the first I have seen this! That is good news. We have one > particular Financial Business application, written/distributed by > outside vendor that I have been bugging now since I put V2.3 in almost 2 > years ago > to remediate. They still have not yet remediated there code, and I was > thinking this was going to hold up my implementation. > > > > > > __ > > ___ > > Dave Jousma > > AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM > > Sent: Friday, August 30, 2019 4:20 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > IBM has a payed feature called Restricted Use CSA, that allows you > > to > keep your applics with userkeycsa running in 2.4. > > Check OA56180. > > > > Kees. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave > > > Sent: 30 August, 2019 10:06 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > Just monoplexes. Some limited sharing of
Re: z/OS 2.1 to 2.4
It does, because 2.4 does not support userkeycsa(yes) anymore. It is also discussed in the 2.4 migration guide. It seems to me the feature will stay, because IBM has fulfilled its goal to block CSA from being used by unauthorized users with full read/write access. Now you must selectively permit userkey csa to users and it is now your responsibility. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jousma, David > Sent: 30 August, 2019 12:47 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Yea... Funny thing it is a pretty major/well known Financial Application > vendor. Every 4-6 months for the last two years I've been pinging them > on their status. I just don’t think they understand the gravity of the > situation they are creating here. > > Also, I did open a PMR on this PTF. It's not clear to me that the > support it discusses continues into V2.4? > > __ > ___ > Dave Jousma > AVP | Manager, Systems 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 Mike Schwab > Sent: Friday, August 30, 2019 6:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > I would ask they cover your cost for this as part of their product, since > they are the only product you use that needs it. > > On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc- > requ...@listserv.ua.edu> wrote: > > > > This is the first I have seen this! That is good news. We have one > particular Financial Business application, written/distributed by outside > vendor that I have been bugging now since I put V2.3 in almost 2 years ago > to remediate. They still have not yet remediated there code, and I was > thinking this was going to hold up my implementation. > > > > __ > > ___ > > Dave Jousma > > AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM > > Sent: Friday, August 30, 2019 4:20 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > IBM has a payed feature called Restricted Use CSA, that allows you to > keep your applics with userkeycsa running in 2.4. > > Check OA56180. > > > > Kees. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave > > > Sent: 30 August, 2019 10:06 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > > > Our Natural Global Buffer Pool is one such use. > > > We are quite back level with both Natural and Adabas. > > > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List On > > > > Behalf Of Brian Westerman > > > > Sent: Thursday, August 29, 2019 11:53 PM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > > > IS your a Parallel sysplex or just LPAR environment? If not > > > > parallel > > > sysplex, > > > > then you have nothing to worry about, except for the fact that the > > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > > > > using > > > it > > > > now), everything else is fairly minor. If your running a sysplex, > > > > then > > > you > > > > probably are okay, but it will depend on a lot
Re: z/OS 2.1 to 2.4
Elardus, yea, I took quite a bit of vacation this summer I always suspend delivery of IBM-MAIL mail during that time, otherwise my outlook email box would probably fill up. :) _ Dave Jousma AVP | Manager, Systems 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 Elardus Engelbrecht Sent: Friday, August 30, 2019 6:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Jousma, David wrote: >This is the first I have seen this! That is good news. That is indeed good news. APAR OA53355 and APAR OA56180 were discussed several times on IBM-MAIN. Perhaps you have missed that? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Would there be any concerns with internal changes to system dataset structures? As an example like catalogs or things like HSM CDS datasets? Going from z/OS 2.1 to z/OS 2.4 is technically not support for fallback. Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? That might get you nearer to a level that could help if you had to fallback. From the z/OS Planning for Installation manual for z/OS 2.4 z/OS V2R4 is supported for coexistence, fallback, and upgrade with the following z/OS® releases: z/OS V2R4, V2R3, and V2R2. This means that: •Coexistence of a z/OS V2R4 system with a V2R3 and V2R2 system is supported. •Fallback from a z/OS V2R4 system to a V2R3 or V2R2 system is supported. •Upgrade to a z/OS V2R4 system from a V2R3 or V2R2 system is supported. Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Friday, August 30, 2019 5:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I would ask they cover your cost for this as part of their product, since they are the only product you use that needs it. On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > This is the first I have seen this! That is good news. We have one > particular Financial Business application, written/distributed by outside > vendor that I have been bugging now since I put V2.3 in almost 2 years ago to > remediate. They still have not yet remediated there code, and I was > thinking this was going to hold up my implementation. > > __ > ___ > Dave Jousma > AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM > Sent: Friday, August 30, 2019 4:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > IBM has a payed feature called Restricted Use CSA, that allows you to keep > your applics with userkeycsa running in 2.4. > Check OA56180. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave > > Sent: 30 August, 2019 10:06 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > > Our Natural Global Buffer Pool is one such use. > > We are quite back level with both Natural and Adabas. > > > > > > > -----Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Brian Westerman > > > Sent: Thursday, August 29, 2019 11:53 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > IS your a Parallel sysplex or just LPAR environment? If not > > > parallel > > sysplex, > > > then you have nothing to worry about, except for the fact that the > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > > > using > > it > > > now), everything else is fairly minor. If your running a sysplex, > > > then > > you > > > probably are okay, but it will depend on a lot of factors which I > > > don't > > have > > > enough information to tell you about. > > > > > > You can contact me offline if you want and we can discuss it, but > > > I > > suspect > > > that so long as you are not running some pretty old vendor > > > software or > > some > > > really crappy home grown code that you will have very few (if any) > > issues. > > > > > > 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.
Re: z/OS 2.1 to 2.4
Yea... Funny thing it is a pretty major/well known Financial Application vendor. Every 4-6 months for the last two years I've been pinging them on their status. I just don’t think they understand the gravity of the situation they are creating here. Also, I did open a PMR on this PTF. It's not clear to me that the support it discusses continues into V2.4? _ Dave Jousma AVP | Manager, Systems 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 Mike Schwab Sent: Friday, August 30, 2019 6:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I would ask they cover your cost for this as part of their product, since they are the only product you use that needs it. On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > This is the first I have seen this! That is good news. We have one > particular Financial Business application, written/distributed by outside > vendor that I have been bugging now since I put V2.3 in almost 2 years ago to > remediate. They still have not yet remediated there code, and I was > thinking this was going to hold up my implementation. > > __ > ___ > Dave Jousma > AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM > Sent: Friday, August 30, 2019 4:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > IBM has a payed feature called Restricted Use CSA, that allows you to keep > your applics with userkeycsa running in 2.4. > Check OA56180. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave > > Sent: 30 August, 2019 10:06 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > > Our Natural Global Buffer Pool is one such use. > > We are quite back level with both Natural and Adabas. > > > > > > > -----Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Brian Westerman > > > Sent: Thursday, August 29, 2019 11:53 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > IS your a Parallel sysplex or just LPAR environment? If not > > > parallel > > sysplex, > > > then you have nothing to worry about, except for the fact that the > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > > > using > > it > > > now), everything else is fairly minor. If your running a sysplex, > > > then > > you > > > probably are okay, but it will depend on a lot of factors which I > > > don't > > have > > > enough information to tell you about. > > > > > > You can contact me offline if you want and we can discuss it, but > > > I > > suspect > > > that so long as you are not running some pretty old vendor > > > software or > > some > > > really crappy home grown code that you will have very few (if any) > > issues. > > > > > > 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 > > For information, services and offers, pl
Re: z/OS 2.1 to 2.4
We discovered it in Cheryl's newsletter 2019 no.1. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jousma, David > Sent: 30 August, 2019 12:20 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > This is the first I have seen this! That is good news. We have one > particular Financial Business application, written/distributed by outside > vendor that I have been bugging now since I put V2.3 in almost 2 years ago > to remediate. They still have not yet remediated there code, and I was > thinking this was going to hold up my implementation. > > __ > ___ > Dave Jousma > AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM > Sent: Friday, August 30, 2019 4:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > IBM has a payed feature called Restricted Use CSA, that allows you to keep > your applics with userkeycsa running in 2.4. > Check OA56180. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Gibney, Dave > > Sent: 30 August, 2019 10:06 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > > Our Natural Global Buffer Pool is one such use. > > We are quite back level with both Natural and Adabas. > > > > > > > -----Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Brian Westerman > > > Sent: Thursday, August 29, 2019 11:53 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > IS your a Parallel sysplex or just LPAR environment? If not > > > parallel > > sysplex, > > > then you have nothing to worry about, except for the fact that the > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > > > using > > it > > > now), everything else is fairly minor. If your running a sysplex, > > > then > > you > > > probably are okay, but it will depend on a lot of factors which I > > > don't > > have > > > enough information to tell you about. > > > > > > You can contact me offline if you want and we can discuss it, but I > > suspect > > > that so long as you are not running some pretty old vendor software > > > or > > some > > > really crappy home grown code that you will have very few (if any) > > issues. > > > > > > 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 > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail or > any attachment may be disclosed, copied or distributed, and that any other > action related to this e-mail or attachment is strictly prohibited, and > may be unlawful. If you have received this e-mail by error, please notify > the sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission > of this e-mail or any attachments, nor responsible for any delay in > receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Nethe
Re: z/OS 2.1 to 2.4
I would ask they cover your cost for this as part of their product, since they are the only product you use that needs it. On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > This is the first I have seen this! That is good news. We have one > particular Financial Business application, written/distributed by outside > vendor that I have been bugging now since I put V2.3 in almost 2 years ago to > remediate. They still have not yet remediated there code, and I was > thinking this was going to hold up my implementation. > > _ > Dave Jousma > AVP | Manager, Systems 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 > Vernooij, Kees (ITOP NM) - KLM > Sent: Friday, August 30, 2019 4:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > IBM has a payed feature called Restricted Use CSA, that allows you to keep > your applics with userkeycsa running in 2.4. > Check OA56180. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Gibney, Dave > > Sent: 30 August, 2019 10:06 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > > Our Natural Global Buffer Pool is one such use. > > We are quite back level with both Natural and Adabas. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Brian Westerman > > > Sent: Thursday, August 29, 2019 11:53 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > IS your a Parallel sysplex or just LPAR environment? If not > > > parallel > > sysplex, > > > then you have nothing to worry about, except for the fact that the > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > > > using > > it > > > now), everything else is fairly minor. If your running a sysplex, > > > then > > you > > > probably are okay, but it will depend on a lot of factors which I > > > don't > > have > > > enough information to tell you about. > > > > > > You can contact me offline if you want and we can discuss it, but I > > suspect > > > that so long as you are not running some pretty old vendor software > > > or > > some > > > really crappy home grown code that you will have very few (if any) > > issues. > > > > > > 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 > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain confidential > and privileged material intended for the addressee only. If you are not the > addressee, you are notified that no part of the e-mail or any attachment may > be disclosed, copied or distributed, and that any other action related to > this e-mail or attachment is strictly prohibited, and may be unlawful. If you > have received this e-mail by error, please notify the sender immediately by > return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > **
Re: z/OS 2.1 to 2.4
Jousma, David wrote: >This is the first I have seen this! That is good news. That is indeed good news. APAR OA53355 and APAR OA56180 were discussed several times on IBM-MAIN. Perhaps you have missed that? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
This is the first I have seen this! That is good news. We have one particular Financial Business application, written/distributed by outside vendor that I have been bugging now since I put V2.3 in almost 2 years ago to remediate. They still have not yet remediated there code, and I was thinking this was going to hold up my implementation. _ Dave Jousma AVP | Manager, Systems 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 Vernooij, Kees (ITOP NM) - KLM Sent: Friday, August 30, 2019 4:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** IBM has a payed feature called Restricted Use CSA, that allows you to keep your applics with userkeycsa running in 2.4. Check OA56180. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: 30 August, 2019 10:06 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > Our Natural Global Buffer Pool is one such use. > We are quite back level with both Natural and Adabas. > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Brian Westerman > > Sent: Thursday, August 29, 2019 11:53 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > IS your a Parallel sysplex or just LPAR environment? If not > > parallel > sysplex, > > then you have nothing to worry about, except for the fact that the > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > > using > it > > now), everything else is fairly minor. If your running a sysplex, > > then > you > > probably are okay, but it will depend on a lot of factors which I > > don't > have > > enough information to tell you about. > > > > You can contact me offline if you want and we can discuss it, but I > suspect > > that so long as you are not running some pretty old vendor software > > or > some > > really crappy home grown code that you will have very few (if any) > issues. > > > > 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 For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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 o
Re: z/OS 2.1 to 2.4
As long as you don't have any USERKEYCSA or USERKEYCAD applications to remediate, you will probably be ok. As IBM has removed support for that in 2.4. What is the official IBM stance? N-2 or N-3? I don't recall. I'll be ordering 2.4 this fall as well. _ Dave Jousma AVP | Manager, Systems 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 Gibney, Dave Sent: Thursday, August 29, 2019 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 to 2.4 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I am considering what upgrade path (if any) I might take from my current z/OS 2.1 RSU 1903 system. I thought that I wouldn't go to 2.3 because I was using SMTP and not CSSMTP. The configuring and implementation of CSSMTP has proven remarkably uneventful. I am not aware of any other gotchas between 2.1 and 2.3 or above. I run four monoplex LPARs. I really don't "coexist" in the sysplex sense. I am considering getting s 2.4 Serverpac when available and making the jump. I do need to be concerned with fallback. I know it's mostly speculation at this point, but does anyone know of z/OS 2.4 fallback maintenance that won't be available for 2.1? Or gotchas I haven't noticed. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
RUCSA is available for z/OS 2.1, so you can implement on you current systems and move it out of the migration path. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Martin Packer > Sent: 30 August, 2019 10:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Note: With RUCSA there are still migration actions - because of the new > way of allowing an address space to use it. > > Cheers, Martin > > Martin Packer > > zChampion, Systems Investigator & Performance Troubleshooter, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or > > https://itunes.apple.com/gb/podcast/mainframe-performance- > topics/id1127943573?mt=2 > > > Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA > > > > From: "Vernooij, Kees (ITOP NM) - KLM" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 30/08/2019 09:21 > Subject:Re: z/OS 2.1 to 2.4 > Sent by:IBM Mainframe Discussion List > > > > IBM has a payed feature called Restricted Use CSA, that allows you to keep > your applics with userkeycsa running in 2.4. > Check OA56180. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Gibney, Dave > > Sent: 30 August, 2019 10:06 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > > Our Natural Global Buffer Pool is one such use. > > We are quite back level with both Natural and Adabas. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Brian Westerman > > > Sent: Thursday, August 29, 2019 11:53 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > IS your a Parallel sysplex or just LPAR environment? If not parallel > > sysplex, > > > then you have nothing to worry about, except for the fact that the > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > using > > it > > > now), everything else is fairly minor. If your running a sysplex, > then > > you > > > probably are okay, but it will depend on a lot of factors which I > don't > > have > > > enough information to tell you about. > > > > > > You can contact me offline if you want and we can discuss it, but I > > suspect > > > that so long as you are not running some pretty old vendor software or > > some > > > really crappy home grown code that you will have very few (if any) > > issues. > > > > > > 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 > > For information, services and offers, please visit our web site: > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.klm.com=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2- > WOWZjlZ0NwmcFSpQCLphNznBSDQ=gpOagelfUQirHhAYLM5OLW3X-fZoRpaYVr- > LlHpuVHg=SH5PyIj6HoznFA_qBtRu5lZhtUhNauWGIZeJ5AXpEjU= > . This e-mail and any attachment may contain confidential and privileged > material intended for the addressee only. If you are not the addressee, > you are notified that no part of the e-mail or any attachment may be > disclosed, copied or distributed, and that any other action related to > this e-mail or attachment is strictly prohibited, and may be unlawful. If > you have received this e-mail by error, please notify the sender > immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission > of this e-mail or any attachments, nor responsible for any delay in &
Re: z/OS 2.1 to 2.4
Note: With RUCSA there are still migration actions - because of the new way of allowing an address space to use it. Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "Vernooij, Kees (ITOP NM) - KLM" To: IBM-MAIN@LISTSERV.UA.EDU Date: 30/08/2019 09:21 Subject: Re: z/OS 2.1 to 2.4 Sent by:IBM Mainframe Discussion List IBM has a payed feature called Restricted Use CSA, that allows you to keep your applics with userkeycsa running in 2.4. Check OA56180. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: 30 August, 2019 10:06 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > Our Natural Global Buffer Pool is one such use. > We are quite back level with both Natural and Adabas. > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Brian Westerman > > Sent: Thursday, August 29, 2019 11:53 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > IS your a Parallel sysplex or just LPAR environment? If not parallel > sysplex, > > then you have nothing to worry about, except for the fact that the > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't using > it > > now), everything else is fairly minor. If your running a sysplex, then > you > > probably are okay, but it will depend on a lot of factors which I don't > have > > enough information to tell you about. > > > > You can contact me offline if you want and we can discuss it, but I > suspect > > that so long as you are not running some pretty old vendor software or > some > > really crappy home grown code that you will have very few (if any) > issues. > > > > 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 For information, services and offers, please visit our web site: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.klm.com=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=gpOagelfUQirHhAYLM5OLW3X-fZoRpaYVr-LlHpuVHg=SH5PyIj6HoznFA_qBtRu5lZhtUhNauWGIZeJ5AXpEjU= . This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
IBM has a payed feature called Restricted Use CSA, that allows you to keep your applics with userkeycsa running in 2.4. Check OA56180. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: 30 August, 2019 10:06 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > Our Natural Global Buffer Pool is one such use. > We are quite back level with both Natural and Adabas. > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Brian Westerman > > Sent: Thursday, August 29, 2019 11:53 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > IS your a Parallel sysplex or just LPAR environment? If not parallel > sysplex, > > then you have nothing to worry about, except for the fact that the > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't using > it > > now), everything else is fairly minor. If your running a sysplex, then > you > > probably are okay, but it will depend on a lot of factors which I don't > have > > enough information to tell you about. > > > > You can contact me offline if you want and we can discuss it, but I > suspect > > that so long as you are not running some pretty old vendor software or > some > > really crappy home grown code that you will have very few (if any) > issues. > > > > 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 For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4
Just monoplexes. Some limited sharing of DASD. Not even GRS. But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. Our Natural Global Buffer Pool is one such use. We are quite back level with both Natural and Adabas. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Thursday, August 29, 2019 11:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > IS your a Parallel sysplex or just LPAR environment? If not parallel sysplex, > then you have nothing to worry about, except for the fact that the > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't using it > now), everything else is fairly minor. If your running a sysplex, then you > probably are okay, but it will depend on a lot of factors which I don't have > enough information to tell you about. > > You can contact me offline if you want and we can discuss it, but I suspect > that so long as you are not running some pretty old vendor software or some > really crappy home grown code that you will have very few (if any) issues. > > 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: z/OS 2.1 to 2.4
IS your a Parallel sysplex or just LPAR environment? If not parallel sysplex, then you have nothing to worry about, except for the fact that the ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't using it now), everything else is fairly minor. If your running a sysplex, then you probably are okay, but it will depend on a lot of factors which I don't have enough information to tell you about. You can contact me offline if you want and we can discuss it, but I suspect that so long as you are not running some pretty old vendor software or some really crappy home grown code that you will have very few (if any) issues. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.1 to 2.4
I am considering what upgrade path (if any) I might take from my current z/OS 2.1 RSU 1903 system. I thought that I wouldn't go to 2.3 because I was using SMTP and not CSSMTP. The configuring and implementation of CSSMTP has proven remarkably uneventful. I am not aware of any other gotchas between 2.1 and 2.3 or above. I run four monoplex LPARs. I really don't "coexist" in the sysplex sense. I am considering getting s 2.4 Serverpac when available and making the jump. I do need to be concerned with fallback. I know it's mostly speculation at this point, but does anyone know of z/OS 2.4 fallback maintenance that won't be available for 2.1? Or gotchas I haven't noticed. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
