Re: Effective of SMT with high zIIP usage
My recommendation is to leave SMT turned off until you have a defined need for it. Then when/if you turn it on, evaluate both application responsiveness as well as the standard SMT measurement values. And then generally keep an eye on those values over time. With SMT enabled, understanding effective zIIP capacity becomes "problematic". zIIP CPU time measurements are "adjusted" to be MT1ET. I'd always prefer to buy more real zIIP capacity vs. enabling some additional variable and hard to understand amount of capacity via SMT. We've seen cases where SMT was useful and we've seen cases where SMT was problematic. The majority of the cases are somewhere in-between and may not be worth the measurement issues. I'd say we see more sites with it disabled than enabled. But... if you need more zIIP capacity and can't immediately acquire more real zIIP capacity, it can be a very useful stop-gap measure. That may be the case for you, I don't know. Are you getting much cross-over to the GPs? Do you have a large spikes of work units waiting for a zIIP? I have a presentation out there about SMT that explains the measurements and gives my recommendation for when you might want to try it. Go to https://www.pivotor.com and click on the "Free!" button then find and click through to our presentations. You probably can find it on a number of the conference web sites as I've presented it at the major conferences as well. Scott Chapman Enterprise Performance Strategies On Thu, 14 Mar 2019 15:08:36 +, Bill Bishop (TMNA) wrote: >Anyone have any real-world experience with SMT? > >We have very high zIIP usage, 70% to 80% across 3 zIIPs, right now and have >been asked to evaluate turning on SMT. > >One response was that with high zIIP usage, SMT might not be as effective as >could be, and the other response is that it will make more efficient use of >the zIIPS and allow them to drive higher. > >We are aware of the impact of zIIP overflow to CPs. > >Thanks > >Bill Bishop >Consultant, Mainframe Engineer >Mainframe and Scheduling | Infrastructure Technology Services >Toyota Motor North America > bill.bis...@toyota.com >Office: (469) 292-5149 >Cell: (502) 316-4386 > >-- >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: New look and linking for V2.3 product documentation PDFs
On Thu, 14 Mar 2019 21:40:18 -0400, Mike Shaw at QUICKREF wrote: >On 3/14/2019 7:07 PM, Paul Gilmartin wrote: >> On Mon, 4 Mar 2019 21:35:31 +, Seymour J Metz wrote: >> >>> ... (I want Bookie back!) >>> >> Interesting that the pdfinfo tells me: >> Antenna House PDF Output Library 6.5.1119 (Linux64) >> ... and: >> https://www.antennahouse.com/ >> ... suggests that they were converted from something else. Word? Bookie? >> ...? > >I think IBM keeps a lot of doc internally in DITA format: > > https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture > >and then uses tooling to export it from DITA markup to HTML or PDF. > (more: https://www.antennahouse.com/dita-editor/ ) QUICKREF, too? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New look and linking for V2.3 product documentation PDFs
On 3/14/2019 7:07 PM, Paul Gilmartin wrote: On Mon, 4 Mar 2019 21:35:31 +, Seymour J Metz wrote: ... (I want Bookie back!) Interesting that the pdfinfo tells me: Antenna House PDF Output Library 6.5.1119 (Linux64) ... and: https://www.antennahouse.com/ ... suggests that they were converted from something else. Word? Bookie? ...? -- gil I think IBM keeps a lot of doc internally in DITA format: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture and then uses tooling to export it from DITA markup to HTML or PDF. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New look and linking for V2.3 product documentation PDFs
On Mon, 4 Mar 2019 21:35:31 +, Seymour J Metz wrote: >... (I want Bookie back!) > Interesting that the pdfinfo tells me: Antenna House PDF Output Library 6.5.1119 (Linux64) ... and: https://www.antennahouse.com/ ... suggests that they were converted from something else. Word? Bookie? ...? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARST64 in addrr
There are better designs than allocating storage at the explicit address in most cases (fork being the primary exception). If it's the case that Kees mentioned of having a shared block that is allocated on first use (assuming you have good serialization), then use name tokens instead. A hard-coded address could fail if something changes in your system to make that address no longer accessible. If you're browsing a lot of storage to display or search for something, then certainly don't allocate it which just wastes system resources and tells you nothing useful. This would be especially true for 64-bit storage that allocating and browsing large areas would end up backing a lot of memory than you'd really need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM SFG - Your Opinion
This is relating to doing SFTP transfers with SFG. If you use SSP for reverse proxy for SFG, which is highly recommended, then you pretty much must use SEAS to look up passwords/keys with LDAP for SFTP clients. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Thursday, March 14, 2019 4:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM SFG - Your Opinion [External Email] IBM z/OS OpenSSH is included with z/OS, and it includes SFTP. Kirk Wolf Dovetailed Techologies http://dovetail.com PS> if you need z/OS data sets, spool files, etc, etc, you can also use Co:Z SFTP, which does SMF, console notification logging, exits, etc, etc. On Thu, Mar 14, 2019 at 2:32 PM Sasso, Len wrote: > We will be doing SFTP. IBM is installing and we will be working with > them to implement. We just got Connect:Direct about 1.5 years ago. We > are getting SFG/SI, SSP, SEAS and CC. Yes, there sure are "a lot of pieces." > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message 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: IBM SFG - Your Opinion
IBM z/OS OpenSSH is included with z/OS, and it includes SFTP. Kirk Wolf Dovetailed Techologies http://dovetail.com PS> if you need z/OS data sets, spool files, etc, etc, you can also use Co:Z SFTP, which does SMF, console notification logging, exits, etc, etc. On Thu, Mar 14, 2019 at 2:32 PM Sasso, Len wrote: > We will be doing SFTP. IBM is installing and we will be working with them > to implement. We just got Connect:Direct about 1.5 years ago. We are > getting SFG/SI, SSP, SEAS and CC. Yes, there sure are "a lot of pieces." > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM SFG - Your Opinion
We will be doing SFTP. IBM is installing and we will be working with them to implement. We just got Connect:Direct about 1.5 years ago. We are getting SFG/SI, SSP, SEAS and CC. Yes, there sure are "a lot of pieces." Thank You! Len Sasso System Administrator General Dynamics Information Technology 327 Columbia TPKE Rensselaer, NY 12144 Phone: (518) 257-4209 Cell: (518) 894-0879 Fax: (518) 257-4300 len.sa...@gdit.com URL: www.gdit.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Thursday, March 14, 2019 3:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM SFG - Your Opinion It's extremely powerful but oh so onerous to install, maintain, and administer. They will push implementation services, and you will wish you'd bought them before it's over if you go it on your own. What are you planning on doing with it? If it is just MFT, I would highly recommend taking a good hard look at MOVEit first (unless you have a bunch of Connect:Direct you have to deal with, since SI/SFG does come with CDSA; you may end up not having much choice). Keep in mind too that you won't need only SFG/SI. You will need SSP and SEAS (if you want to do SFTP; that's another joy) as well. And you probably will want CC. There are other pieces that have to be installed and configured on separate servers (SSPcm and Perimeter Server), but they are part of SSP. In short, there are a lot of pieces. One more thing, IBM just recently outsourced support and development (I think) of the suite to Syncsort, if that sways you either way. First Tennessee Bank Mainframe Technical Support [External Email] I welcome your comments, suggestions, etc. about the IBM SFG Product. FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM SFG - Your Opinion
It's extremely powerful but oh so onerous to install, maintain, and administer. They will push implementation services, and you will wish you'd bought them before it's over if you go it on your own. What are you planning on doing with it? If it is just MFT, I would highly recommend taking a good hard look at MOVEit first (unless you have a bunch of Connect:Direct you have to deal with, since SI/SFG does come with CDSA; you may end up not having much choice). Keep in mind too that you won't need only SFG/SI. You will need SSP and SEAS (if you want to do SFTP; that's another joy) as well. And you probably will want CC. There are other pieces that have to be installed and configured on separate servers (SSPcm and Perimeter Server), but they are part of SSP. In short, there are a lot of pieces. One more thing, IBM just recently outsourced support and development (I think) of the suite to Syncsort, if that sways you either way. First Tennessee Bank Mainframe Technical Support [External Email] I welcome your comments, suggestions, etc. about the IBM SFG Product. FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message 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: IBM SFG - Your Opinion
Sterling File Gateway (Managed File Transfer Product) Thank You! Len Sasso System Administrator General Dynamics Information Technology 327 Columbia TPKE Rensselaer, NY 12144 Phone: (518) 257-4209 Cell: (518) 894-0879 Fax: (518) 257-4300 len.sa...@gdit.com URL: www.gdit.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, March 14, 2019 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM SFG - Your Opinion SFG -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sasso, Len Sent: Thursday, March 14, 2019 1:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM SFG - Your Opinion Importance: High I welcome your comments, suggestions, etc. about the IBM SFG Product. Thank You! Len Sasso System Administrator General Dynamics Information Technology 327 Columbia TPKE Rensselaer, NY 12144 Phone: (518) 257-4209 Cell: (518) 894-0879 Fax: (518) 257-4300 len.sa...@gdit.com URL: https://apac01.safelinks.protection.outlook.com/?url=www.gdit.comdata=02%7C01%7Callan.staller%40HCL.COM%7C730557dbfeb54858076d08d6a8a752ef%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636881833969338361sdata=j1nOBCM5vSQqsa%2FgNm%2Bvspnd3MIOAfFNhvu6tDMjvNY%3Dreserved=0 This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM SFG - Your Opinion
SFG -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sasso, Len Sent: Thursday, March 14, 2019 1:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM SFG - Your Opinion Importance: High I welcome your comments, suggestions, etc. about the IBM SFG Product. Thank You! Len Sasso System Administrator General Dynamics Information Technology 327 Columbia TPKE Rensselaer, NY 12144 Phone: (518) 257-4209 Cell: (518) 894-0879 Fax: (518) 257-4300 len.sa...@gdit.com URL: https://apac01.safelinks.protection.outlook.com/?url=www.gdit.comdata=02%7C01%7Callan.staller%40HCL.COM%7C730557dbfeb54858076d08d6a8a752ef%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636881833969338361sdata=j1nOBCM5vSQqsa%2FgNm%2Bvspnd3MIOAfFNhvu6tDMjvNY%3Dreserved=0 This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- 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: Disturbing news in the z/OS 2.4 announcement letter
ObGungaDin It was clunky; it badly needed multi-line and block copy. But it was better than nothing. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Thursday, March 14, 2019 2:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Disturbing news in the z/OS 2.4 announcement letter I so mentally interpolated an "sh" in there :-). I always wanted to like WSA, but it seemed very clunky vs. my expectations. I never thought of it as a file transfer tool, merely as a way to edit locally. sas On Thu, Mar 14, 2019 at 1:59 PM Seymour J Metz wrote: > I never used WSA as a file transfer application, only to run parallel ISPF > sessions. If they open sourced that piece of it I'd be happy. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disturbing news in the z/OS 2.4 announcement letter
I so mentally interpolated an "sh" in there :-). I always wanted to like WSA, but it seemed very clunky vs. my expectations. I never thought of it as a file transfer tool, merely as a way to edit locally. sas On Thu, Mar 14, 2019 at 1:59 PM Seymour J Metz wrote: > I never used WSA as a file transfer application, only to run parallel ISPF > sessions. If they open sourced that piece of it I'd be happy. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS build clarification
W dniu 2019-03-14 o 18:53, Peter pisze:
Hello All
Right now I am running serverpac for zOS 2.3 from the driving system LPAR
LOPB on z14 hardware.
The target system name is also LOPB and I will be IPLING from z114.
This is for just test purpose I am doing as recently we moved from z114 to
z14.
Our storage box are still connected to both the hardware(z14 and z114) and
UCB are available on both the hardware. Which means the volume are
available for both z hardware.
Is the above approach works ?
Also under the serverpac I gave a different IODF for copying . Can I alter
in Serverpac again as I have already generated the installation Jobs.
Regards
Peter
What is the question?
Yes, you can have DASD box connected to two mainframes.
Both mainframes can be completely unaware one of each other - that means
you can have old z/OS on z114 and new z/OS on z14 . Both system can use
different IODFs even completely different device numbering (not
recommended, because of risk of human confusion), etc.
You can access existing ("old") volumes from new z/OS. Of course it is
not all.
You can import connect existing user catalogs (catalog sharing require
more attention) and see "old" datasets cataloged, especially VSAM files.
--
Radoslaw Skorupka
Lodz, Poland
==
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2018 r. wynosi 169.248.488 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169,248,488 as at 1 January 2018.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM SFG - Your Opinion
I welcome your comments, suggestions, etc. about the IBM SFG Product. Thank You! Len Sasso System Administrator General Dynamics Information Technology 327 Columbia TPKE Rensselaer, NY 12144 Phone: (518) 257-4209 Cell: (518) 894-0879 Fax: (518) 257-4300 len.sa...@gdit.com URL: www.gdit.com This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disturbing news in the z/OS 2.4 announcement letter
I never used WSA as a file transfer application, only to run parallel ISPF sessions. If they open sourced that piece of it I'd be happy. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Thursday, March 14, 2019 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Disturbing news in the z/OS 2.4 announcement letter On Wed, 13 Mar 2019 19:13:44 +, Styles, Andy (ITS zPlatform Services) wrote: > >Yes, I spotted this too. I've been too busy to spare time to think about it, >but I too use it for seamless file transfer to/from my laptop, and would miss >that functionality. I suspect IBM would be pushing other, more cumbersome >technologies like IDz. > I have been very satisfied with NFS. It provides file access that I consider more convenient than "file transfer". I'm puzzled that NFS is not more widely accepted. >I was also wondering whether IBM might be willing to open source the WSA :-) -- gil -- 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
z/OS build clarification
Hello All Right now I am running serverpac for zOS 2.3 from the driving system LPAR LOPB on z14 hardware. The target system name is also LOPB and I will be IPLING from z114. This is for just test purpose I am doing as recently we moved from z114 to z14. Our storage box are still connected to both the hardware(z14 and z114) and UCB are available on both the hardware. Which means the volume are available for both z hardware. Is the above approach works ? Also under the serverpac I gave a different IODF for copying . Can I alter in Serverpac again as I have already generated the installation Jobs. Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disturbing news in the z/OS 2.4 announcement letter
On Wed, 13 Mar 2019 19:13:44 +, Styles, Andy (ITS zPlatform Services) wrote: > >Yes, I spotted this too. I've been too busy to spare time to think about it, >but I too use it for seamless file transfer to/from my laptop, and would miss >that functionality. I suspect IBM would be pushing other, more cumbersome >technologies like IDz. > I have been very satisfied with NFS. It provides file access that I consider more convenient than "file transfer". I'm puzzled that NFS is not more widely accepted. >I was also wondering whether IBM might be willing to open source the WSA :-) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: hsm questions
Mike, Yes, you should be able to delete the logs outside of hsm. I don't think it keeps track of those. The log retention is usually governed ty the management class; so, look into that. To check the space on hsm cds files: HSEND Q CDS That command will give the the space allocation of the ocds, bcds, ocds and journal. Look at the usage for the DATA portion of your cds files. Once it hits 90%, you have to think reorg. -Original Message- From: IBM Mainframe Discussion List On Behalf Of MARTIN, MIKE Sent: Wednesday, March 13, 2019 4:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: hsm questions Hi all, I am fairly new to hsm (been around MVS for decades though). The person that previously managed hsm left the company and now I have that responsibility. I have a couple of basic questions about hsm... 1. Can I manually delete old ACTIVITY Logs outside of hsm? (in other words, does hsm keep track of them?) 2. For the MCDS, Omegamon shows two fields... Percent Free Space Data Component - 14% and Percent Available Space Data Component - 55.8% What is the difference? Which one should I care most about? Thanks for any help in advance. Mike Martin This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email. -- 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
Software volume category
I mean SMS-managed tapes, and possible entries in DEVSUPxx member, for example default MEDIA11 =000B (this is default for JC media, also called EATC) Question: where the category is recorded? AFAIR it is recorde in the ATL, that means Library Manager (PC inside the library). However is it recorded anywhere on z/OS side? Neither VOLCAT, nor RMM show this value. Q2: Is there any difference between ISMF.2. (Volume - Mountable tape) information and output from IDCAMS LISTCAT VOLENTRY(Vvolser) ? Of course I don't mean visual aspects, rather source of information. LISTCAT takes info from VOLCAT, what about ISMF panels? Is there any complementary information, i.e. recorded in SMS CDS? Q3: What is the purpose of volume categories? Is it specific for just z/OS (mainframe systems) or it is something widely used by ATLs? Is there any table describing default categories including media JD and JE or it does not make any sense, because this media is not supported in z/OS? (note: JE media is for TS1160 which is not supported in z/OS neither directly, nor as VTS backend) -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe "rollout" of maintenance
That's how I like to operate, with one variation: I prefer to rotate among sysres sets rather than cloning and deleting, and I don't dedicate a sysres set to one LPAR except when I'm in the process of promoting a testing a new level. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Thursday, March 14, 2019 4:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPe "rollout" of maintenance I have a target zone for each sysres set and a dlib zone for each dlib set. If I need to add maint (even just one ptf) to a res system, but don't want to change an already existing one, I clone the existing sysres set and target zone and zoneedit the pack names. My catalogs are always set up to use ** and IEASYMxx so that nothing gets messed up. I maintain lots of sites and literally hundreds of zones this way. When I no longer need one, I scratch the sysres set and the dlib set and delete the zones. It's a pretty solid way to handle things. If anything happens due to maintenance, I always have something to fall back to without having to change anything except the IPL volume and the load parms. Brian On Wed, 13 Mar 2019 18:55:02 +, Seymour J Metz wrote: >What happens when you are testing a new service level and you need to install >PTF on the production system? If you apply it to the test system and copy, >then you be running the new service level before you've finished testing it. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List on behalf of >Carmen Vitullo >Sent: Wednesday, March 13, 2019 2:24 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMPe "rollout" of maintenance > >It really depends, I've never been stuck in a situation when I needed to do >this, if so; > >I'll apply to SMP target, copy to TEST SYSRES, TEST, and move to PROD copied >to the alternate SYSRES. my small 3 LPAR PLEX shares the SYSRES, so migration >is copy to SYSRES(A), IPL test from that SYSRES, TEST, IPL PRODA from >SYSRES(A), IPL PRODB from SYSRES(A). if another ptf is required it will be >applied, and very rare occasions, that SYSRES will be IPL'd in test. then >copied to the OTHER SYSRES SYSRES(B). I've not, so far had a requirement that >I need to maintain a third SYSRES or multiple target zones for the OS > >I am prolly not making this sound easy and not posting this correctly, but I >have a documented process that I've been using for many years that works well, >even in a TEST PLEX / PROD PLEX 6 LPAR environment. >difference now is I have a smaller environment and this methodology lends >itself well to these maint process. >if needed I have a third SYRES available in my back pocket > > >Carmen Vitullo > >- Original Message - > >From: "Seymour J Metz" >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, March 13, 2019 1:09:01 PM >Subject: Re: SMPe "rollout" of maintenance > >That lets you install a PTF on the sysres that matches your target zone, but >what happens if you need the PTF on a different sysres? > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List on behalf of >Carmen Vitullo >Sent: Wednesday, March 13, 2019 2:03 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMPe "rollout" of maintenance > >I've seen so many different ways to do this, for me they easiest way; >I maintain one CSI for ZOS, and one target zone, I maintain different levels >of the base/maint on different SYSRES volumes, give me a way back if needed >and the ability to apply those one-off's and test and move to an alternate >SYSRES. >much more to it but I think you get the point. >everything I apply and copy is kept updated in an Excel spreadsheet > >Carmen Vitullo > >- Original Message - > >From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, March 13, 2019 12:53:16 PM >Subject: Re: SMPe "rollout" of maintenance > >On Wed, 13 Mar 2019 12:30:35 -0500, Bill Giannelli >wrote: > >>When I obtain maintenance for an RSU (e.i. for Db2 RSU1902). >>I receive and apply, then implement first in one of our 2 sand boxes, leaving >>our 2nd sand box at our prior maintenance level. >>My question is, before I have rolled out the new maintenance, what if I need >>a one off PTF for the prior maintenance? >>Should 2 CSIs be kept? One for new maintenance and a second one for a prior >>maintenance level. > >Others have different ideas about how to manage your target zones. > >My preference is to always clone a new Target and distribution zone before >applying maintenance. > >When a Target zone is no longer needed i.e. there is no system running that >level of the code and there is no need to go back, the old zones can be >deleted. > >-- >Tom Marchant >
Re: cloning target and dlib zones
I prefer to have each target/dlib pair is a separate CSI; that simplifies backup. Thee are arguments in favor of only having one dlib zone for a given srel; I don't find the case compelling, but others do. Wht is critical is that you have a target zone for every sysres set that you might need to update, and that you take into account your installations backup procedures nd policies. As always, a little planning up front saves a lot of panic down the road. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Bill Giannelli Sent: Thursday, March 14, 2019 7:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: cloning target and dlib zones to maintain 2 different maintenance levels I want to clone my target and dlib. would this require 2 separate CSIs? And would I have to 2 copies of most of the dddefs? thanks Bill -- 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: cloning target and dlib zones
If you want to be able to do maintenance on the target volumes then you need target zones. Whether to have a separate CSI for each pair of target/dlib depends on your backup strategy. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of william giannelli Sent: Thursday, March 14, 2019 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: cloning target and dlib zones so for each cloned target I need a separate CSI? On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson wrote: > I usually keep 4 different sets of target CSI and Just one DLIB(As we > accept the previous maintenance only when the previous maintenance has > baked for some time ) > > TG1,TG2,TG3,TG4. > > So on the cloning process one qualifier matching to CSI name .. > > > > On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, > wrote: > > > to maintain 2 different maintenance levels I want to clone my target and > > dlib. would this require 2 separate CSIs? And would I have to 2 copies of > > most of the dddefs? > > thanks > > Bill > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Effective of SMT with high zIIP usage
Probably the overwhelming consideration is thread speed sensitivity. DDF probably OK with it, DBM1 Client SRBs likewise. Java batch jobs possibly not OK. 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: Carmen Vitullo To: IBM-MAIN@LISTSERV.UA.EDU Date: 14/03/2019 15:24 Subject:Re: Effective of SMT with high zIIP usage Sent by:IBM Mainframe Discussion List we tested with a single zIIP and turned it off quickly. We were eventually able to convert one spare CP to a second zIIP, and turned it on again on our secondary prod LPAR which was mostly all DB2 DDF type processing, both PROD1 and PROD2 were almost alway on the CAP, we saw some minor improvement, and are still studying the effects with SMT and without to see of the second zIIP helped us or SMT helped. the reason why is a CP3000 study was performed for us and the recommendation was to turn SMT off Carmen Vitullo - Original Message - From: "Bill Bishop (TMNA)" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 14, 2019 10:08:36 AM Subject: Effective of SMT with high zIIP usage Anyone have any real-world experience with SMT? We have very high zIIP usage, 70% to 80% across 3 zIIPs, right now and have been asked to evaluate turning on SMT. One response was that with high zIIP usage, SMT might not be as effective as could be, and the other response is that it will make more efficient use of the zIIPS and allow them to drive higher. We are aware of the impact of zIIP overflow to CPs. Thanks Bill Bishop Consultant, Mainframe Engineer Mainframe and Scheduling | Infrastructure Technology Services Toyota Motor North America bill.bis...@toyota.com Office: (469) 292-5149 Cell: (502) 316-4386 -- 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 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: cloning target and dlib zones
On Thu, 14 Mar 2019 06:08:01 -0500, Bill Giannelli wrote: >to maintain 2 different maintenance levels I want to clone my target and dlib. >would this require 2 separate CSIs? And would I have to 2 copies of most of >the dddefs? Strictly speaking, you do not need a separate CSI for each zone. You could put all your target zones in a single CSI, or when you clone a target and distribution zone, you could create a new CSI for them both. I find it easier to define a CSI for each target zone, and a CSI for each distribution zone. In any case, each target needs all of its own data sets, including Unix filesystems, SMPLOG, SMPSTS, SMPSCDS, etc. and the DDDEFs in each zone need to accurately reflect those data sets. And don't forget that the target zone requires distribution zone data sets. Likewise, if the distribution zone has DDDEFs for SMPSCDS, SMPMTS, etc, they should be the correct data sets for the related target zone. And if you have more than one distribution zone, which I recommend, you should set your OPTIONS entry specify NOPURGE. Otherwise you will not be able to accept maintenance to more than one distribution zone. You will have to explicitly run REJECT PURGE when you want to clean up your global zone. And you should include NOREJECT, so that PTFs are not removed from the global zone when they are restored. Again, otherwise you may need to receive them again, for example, if a later PTF specifies it as a PRE, or if you decide that it is something that you actually want. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Effective of SMT with high zIIP usage
we tested with a single zIIP and turned it off quickly. We were eventually able to convert one spare CP to a second zIIP, and turned it on again on our secondary prod LPAR which was mostly all DB2 DDF type processing, both PROD1 and PROD2 were almost alway on the CAP, we saw some minor improvement, and are still studying the effects with SMT and without to see of the second zIIP helped us or SMT helped. the reason why is a CP3000 study was performed for us and the recommendation was to turn SMT off Carmen Vitullo - Original Message - From: "Bill Bishop (TMNA)" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 14, 2019 10:08:36 AM Subject: Effective of SMT with high zIIP usage Anyone have any real-world experience with SMT? We have very high zIIP usage, 70% to 80% across 3 zIIPs, right now and have been asked to evaluate turning on SMT. One response was that with high zIIP usage, SMT might not be as effective as could be, and the other response is that it will make more efficient use of the zIIPS and allow them to drive higher. We are aware of the impact of zIIP overflow to CPs. Thanks Bill Bishop Consultant, Mainframe Engineer Mainframe and Scheduling | Infrastructure Technology Services Toyota Motor North America bill.bis...@toyota.com Office: (469) 292-5149 Cell: (502) 316-4386 -- 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
Effective of SMT with high zIIP usage
Anyone have any real-world experience with SMT? We have very high zIIP usage, 70% to 80% across 3 zIIPs, right now and have been asked to evaluate turning on SMT. One response was that with high zIIP usage, SMT might not be as effective as could be, and the other response is that it will make more efficient use of the zIIPS and allow them to drive higher. We are aware of the impact of zIIP overflow to CPs. Thanks Bill Bishop Consultant, Mainframe Engineer Mainframe and Scheduling | Infrastructure Technology Services Toyota Motor North America bill.bis...@toyota.com Office: (469) 292-5149 Cell: (502) 316-4386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: hsm questions
If you issue F dfhsm-stc-name,Q CDS it will show storage allocations for the files. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Richard Marchant > Sent: Thursday, March 14, 2019 4:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: hsm questions > > Mike, > > My guess for the MCDS data component free percentages: > > In the listcat of the MCDS you will have something similar to; > > FREESPC517779456 > > HI-A-RBA---662077440 > HI-U-RBA---173260800 > > *Actual Free Space* > The lower percentage free space figure will be: (HI-A-RBA - HI-U-RBA) / HI- > A-RBA * 100 In the case above this will be (662077440 - 173260800) / > 662077440 * 100 = 73.8 % > > *Potential Free Space (if reorganised)* > The higher percentage free space figure will be: FREESPC / HI-A-RBA * 100 In > the case above this will be 517779456 / 662077440 * 100 = 78.2 % > > Richard Marchant > Johannesburg > > On Wed, Mar 13, 2019 at 10:08 PM MARTIN, MIKE > wrote: > > > Hi all, > > > > I am fairly new to hsm (been around MVS for decades though). The person > > that previously managed hsm left the company and now I have that > > responsibility. > > > > I have a couple of basic questions about hsm... > > > > > > 1. Can I manually delete old ACTIVITY Logs outside of hsm? (in > > other words, does hsm keep track of them?) > > 2. For the MCDS, Omegamon shows two fields... Percent Free Space Data > > Component - 14% and Percent Available Space Data Component - 55.8% > > What is the difference? Which one should I care most about? > > > > Thanks for any help in advance. > > > > Mike Martin > > > > This email may contain confidential and privileged material for the > > sole use of the intended recipient. If you are not the intended > > recipient, please contact the sender and delete all copies. Any review > > or distribution by others is strictly prohibited. Personal emails are > > restricted by policy of the State Employees' Credit Union (SECU). > > Therefore SECU specifically disclaims any responsibility or liability > > for any personal information or opinions of the author expressed in this > email. > > > > -- > > 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: Disturbing news in the z/OS 2.4 announcement letter
W dniu 2019-03-13 o 20:09, Don Leahy pisze: "Withdrawal of ISPF Workstation Agent (WSA) z/OS V2.4 is planned to be the last release to support the ISPF Workstation Agent (WSA), also known as the ISPF Client/Server Component. WSA is an application that runs on your local workstation and maintains a connection between the workstation and the ISPF host. It is primarily used to transfer files between the workstation and the host. IBM recommends using more current file transfer solutions such as those provided by the Zowe Dataset Explorer, z/OS FTP, and similar file transfer mechanisms. These solutions have more capabilities, including the ability to provide secure communications." I have a lot of tools in my box that rely on WSA. WSA is so easy to automate using ISPF services that I will hard pressed to find alternatives that are as seamless to use. On the other hand, I am only a few years away from retirement so I may not bother. :-) Well, While I like WSA, I see how moribound was it last 15-20 years. So, the future of WAS was rather clear for me. From the other hand - why to remove something? Is it part of closing alternatives to new shining tool, or just something in new system broken WSA and instead of fixing it decision was to remove WSA at all. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/os Access Windows SMB ?
W dniu 2019-03-13 o 17:17, Longnecker, Dennis pisze: I've seen the information on how to get z/os data available via SMB to a Windows machine, but haven't seen anything on how to get the z/os side to send a file to a windows SMB. Trying to get a bunch of mainframe files over to a Windows share, without setting up FTP servers on the windows side and doing it that way. Anyone doing this already and have some pointers? You want SMB client on z/OS, but it does not exist. Note, SMB server will disappear in z/OS 2.5 or 2.4, so don't go there. IMHO you can use NFS (AFAIK both client and server are available on z/OS) or ftp (yes, you mentioned it) or FTPS, or sftp, or any commercial product from "managed file transfer" family. BTW: Usually sending a file is not a business goal. For example I have to send file to a "reporting department (DR)". No, they want to read my file in order to prepare the report. It is not necessary to send the file, it is sufficient to make the file available to their application. Yes, it can be mapped network drive. Even on mainframe. Is it better? YMMV. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: cloning target and dlib zones
OK, but during the '80s, there were no system symbolics like With the advent of that, larger DASD volumes (i.e. 3390 MOD 9, 27 and 54) and larger Datasets, the SysProg no longer had to cram everything on 1 DASD Volume. On 2019-03-14 09:49, Carmen Vitullo wrote: > I think you get the just of what I was saying, that technique, or method of > keeping everything on the sysres (for some), trying not to put my foot in my > mouth again, moved forward with the advent of OpenMVS. > the sysprog I replaced had everything on the sysres, so cloning or maintain > gwas more difficult than needed to be IMO. > > > "not that there's anything wrong with that" :) > > > Carmen Vitullo > > - Original Message - > > From: "David Spiegel" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thursday, March 14, 2019 8:34:16 AM > Subject: Re: cloning target and dlib zones > > Hi Carmen, > You said: "... 1980's, that's what I came into all system catalogs were > on the sysres, all uss HFS and ZFS were on the sysres ..." > > OMVS was not available until the mid '90s. > > Regards, > David > > On 2019-03-14 09:00, Carmen Vitullo wrote: >> One Global, two Targets, one DLIB, that's what I've done in a previous shop, >> for products only,that was the standard, the target zone was named for the >> sysplex, and the DDDEF's reflected the Plex name in the target datasets in >> that zone, so my plex name was PLEX1 lets say, so my zone names were TPLEX1 >> and TPLEX2, for example, and the target dataset names were some >> hlq.vendor.product.TPLEX1 or 2. dsntype. >> like I said that was a standard at this shop, we maintained a PROGxx member >> for each system in the PLEX, if APF is required both PLEX1 and PLEX2 are >> listed, when applying maint in each system that systems PROG00 linklist or >> other places were updated to the currently applied target library. >> I would only apply to the second zone once 1) the maint made it around the >> PLEX, 2) no issues were found during testing/prod, so one receive, 2 >> applies, 1 accept. >> >> >> everyone has their favorite way of maintaining a system or product, some >> because that's how they learned, some because they developed a methodology >> that works well for them that will provide the ability to maintain the >> system or product, provide an easy backout if problems and an easy was to >> clone (if necessary). I've worked with and for Global Services the way we >> maintained a customer site was very much different than another outsourcer I >> worked for, and much different that the site I'm currently working at, right >> or wrong, it's the way that works for me, and I've documented the process >> from receiving a new order, to installing that order thru migration and >> maint process. >> think 1980's, that's what I came into all system catalogs were on the >> sysres, all uss HFS and ZFS were on the sysres, sys1.proclib, and >> sys1.ibm.proclib ,sys1.parmlib, and sys1.ibm.parmlib , no iplparm :( >> so each library was modified for each system so caution was required when >> merging the updates from the order libraries. >> >> >> >> Carmen Vitullo >> >> - Original Message - >> >> From: "william giannelli" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Thursday, March 14, 2019 7:25:44 AM >> Subject: Re: cloning target and dlib zones >> >> so for each cloned target I need a separate CSI? >> >> On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson >> wrote: >> >>> I usually keep 4 different sets of target CSI and Just one DLIB(As we >>> accept the previous maintenance only when the previous maintenance has >>> baked for some time ) >>> >>> TG1,TG2,TG3,TG4. >>> >>> So on the cloning process one qualifier matching to CSI name .. >>> >>> >>> >>> On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, >>> wrote: >>> to maintain 2 different maintenance levels I want to clone my target and dlib. would this require 2 separate CSIs? And would I have to 2 copies of most of the dddefs? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> . >> > > -- > For IBM-MAIN subscribe /
Re: cloning target and dlib zones
OK, but during the '80s, there were no System Symbols like With the advent of that, larger DASD volumes (i.e. 3390 MOD 9, 27 and 54) and larger Datasets, the SysProg no longer had to cram everything on 1 DASD Volume. On 2019-03-14 09:49, Carmen Vitullo wrote: > I think you get the just of what I was saying, that technique, or method of > keeping everything on the sysres (for some), trying not to put my foot in my > mouth again, moved forward with the advent of OpenMVS. > the sysprog I replaced had everything on the sysres, so cloning or maintain > gwas more difficult than needed to be IMO. > > > "not that there's anything wrong with that" :) > > > Carmen Vitullo > > - Original Message - > > From: "David Spiegel" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thursday, March 14, 2019 8:34:16 AM > Subject: Re: cloning target and dlib zones > > Hi Carmen, > You said: "... 1980's, that's what I came into all system catalogs were > on the sysres, all uss HFS and ZFS were on the sysres ..." > > OMVS was not available until the mid '90s. > > Regards, > David > > On 2019-03-14 09:00, Carmen Vitullo wrote: >> One Global, two Targets, one DLIB, that's what I've done in a previous shop, >> for products only,that was the standard, the target zone was named for the >> sysplex, and the DDDEF's reflected the Plex name in the target datasets in >> that zone, so my plex name was PLEX1 lets say, so my zone names were TPLEX1 >> and TPLEX2, for example, and the target dataset names were some >> hlq.vendor.product.TPLEX1 or 2. dsntype. >> like I said that was a standard at this shop, we maintained a PROGxx member >> for each system in the PLEX, if APF is required both PLEX1 and PLEX2 are >> listed, when applying maint in each system that systems PROG00 linklist or >> other places were updated to the currently applied target library. >> I would only apply to the second zone once 1) the maint made it around the >> PLEX, 2) no issues were found during testing/prod, so one receive, 2 >> applies, 1 accept. >> >> >> everyone has their favorite way of maintaining a system or product, some >> because that's how they learned, some because they developed a methodology >> that works well for them that will provide the ability to maintain the >> system or product, provide an easy backout if problems and an easy was to >> clone (if necessary). I've worked with and for Global Services the way we >> maintained a customer site was very much different than another outsourcer I >> worked for, and much different that the site I'm currently working at, right >> or wrong, it's the way that works for me, and I've documented the process >> from receiving a new order, to installing that order thru migration and >> maint process. >> think 1980's, that's what I came into all system catalogs were on the >> sysres, all uss HFS and ZFS were on the sysres, sys1.proclib, and >> sys1.ibm.proclib ,sys1.parmlib, and sys1.ibm.parmlib , no iplparm :( >> so each library was modified for each system so caution was required when >> merging the updates from the order libraries. >> >> >> >> Carmen Vitullo >> >> - Original Message - >> >> From: "william giannelli" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Thursday, March 14, 2019 7:25:44 AM >> Subject: Re: cloning target and dlib zones >> >> so for each cloned target I need a separate CSI? >> >> On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson >> wrote: >> >>> I usually keep 4 different sets of target CSI and Just one DLIB(As we >>> accept the previous maintenance only when the previous maintenance has >>> baked for some time ) >>> >>> TG1,TG2,TG3,TG4. >>> >>> So on the cloning process one qualifier matching to CSI name .. >>> >>> >>> >>> On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, >>> wrote: >>> to maintain 2 different maintenance levels I want to clone my target and dlib. would this require 2 separate CSIs? And would I have to 2 copies of most of the dddefs? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> . >> > > -- > For IBM-MAIN subscribe /
Re: cloning target and dlib zones
I think you get the just of what I was saying, that technique, or method of keeping everything on the sysres (for some), trying not to put my foot in my mouth again, moved forward with the advent of OpenMVS. the sysprog I replaced had everything on the sysres, so cloning or maintain gwas more difficult than needed to be IMO. "not that there's anything wrong with that" :) Carmen Vitullo - Original Message - From: "David Spiegel" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 14, 2019 8:34:16 AM Subject: Re: cloning target and dlib zones Hi Carmen, You said: "... 1980's, that's what I came into all system catalogs were on the sysres, all uss HFS and ZFS were on the sysres ..." OMVS was not available until the mid '90s. Regards, David On 2019-03-14 09:00, Carmen Vitullo wrote: > One Global, two Targets, one DLIB, that's what I've done in a previous shop, > for products only,that was the standard, the target zone was named for the > sysplex, and the DDDEF's reflected the Plex name in the target datasets in > that zone, so my plex name was PLEX1 lets say, so my zone names were TPLEX1 > and TPLEX2, for example, and the target dataset names were some > hlq.vendor.product.TPLEX1 or 2. dsntype. > like I said that was a standard at this shop, we maintained a PROGxx member > for each system in the PLEX, if APF is required both PLEX1 and PLEX2 are > listed, when applying maint in each system that systems PROG00 linklist or > other places were updated to the currently applied target library. > I would only apply to the second zone once 1) the maint made it around the > PLEX, 2) no issues were found during testing/prod, so one receive, 2 applies, > 1 accept. > > > everyone has their favorite way of maintaining a system or product, some > because that's how they learned, some because they developed a methodology > that works well for them that will provide the ability to maintain the system > or product, provide an easy backout if problems and an easy was to clone (if > necessary). I've worked with and for Global Services the way we maintained a > customer site was very much different than another outsourcer I worked for, > and much different that the site I'm currently working at, right or wrong, > it's the way that works for me, and I've documented the process from > receiving a new order, to installing that order thru migration and maint > process. > think 1980's, that's what I came into all system catalogs were on the sysres, > all uss HFS and ZFS were on the sysres, sys1.proclib, and sys1.ibm.proclib > ,sys1.parmlib, and sys1.ibm.parmlib , no iplparm :( > so each library was modified for each system so caution was required when > merging the updates from the order libraries. > > > > Carmen Vitullo > > - Original Message - > > From: "william giannelli" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thursday, March 14, 2019 7:25:44 AM > Subject: Re: cloning target and dlib zones > > so for each cloned target I need a separate CSI? > > On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson > wrote: > >> I usually keep 4 different sets of target CSI and Just one DLIB(As we >> accept the previous maintenance only when the previous maintenance has >> baked for some time ) >> >> TG1,TG2,TG3,TG4. >> >> So on the cloning process one qualifier matching to CSI name .. >> >> >> >> On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, >> wrote: >> >>> to maintain 2 different maintenance levels I want to clone my target and >>> dlib. would this require 2 separate CSIs? And would I have to 2 copies of >>> most of the dddefs? >>> thanks >>> Bill >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: cloning target and dlib zones
Hi Carmen, You said: "... 1980's, that's what I came into all system catalogs were on the sysres, all uss HFS and ZFS were on the sysres ..." OMVS was not available until the mid '90s. Regards, David On 2019-03-14 09:00, Carmen Vitullo wrote: > One Global, two Targets, one DLIB, that's what I've done in a previous shop, > for products only,that was the standard, the target zone was named for the > sysplex, and the DDDEF's reflected the Plex name in the target datasets in > that zone, so my plex name was PLEX1 lets say, so my zone names were TPLEX1 > and TPLEX2, for example, and the target dataset names were some > hlq.vendor.product.TPLEX1 or 2. dsntype. > like I said that was a standard at this shop, we maintained a PROGxx member > for each system in the PLEX, if APF is required both PLEX1 and PLEX2 are > listed, when applying maint in each system that systems PROG00 linklist or > other places were updated to the currently applied target library. > I would only apply to the second zone once 1) the maint made it around the > PLEX, 2) no issues were found during testing/prod, so one receive, 2 applies, > 1 accept. > > > everyone has their favorite way of maintaining a system or product, some > because that's how they learned, some because they developed a methodology > that works well for them that will provide the ability to maintain the system > or product, provide an easy backout if problems and an easy was to clone (if > necessary). I've worked with and for Global Services the way we maintained a > customer site was very much different than another outsourcer I worked for, > and much different that the site I'm currently working at, right or wrong, > it's the way that works for me, and I've documented the process from > receiving a new order, to installing that order thru migration and maint > process. > think 1980's, that's what I came into all system catalogs were on the sysres, > all uss HFS and ZFS were on the sysres, sys1.proclib, and sys1.ibm.proclib > ,sys1.parmlib, and sys1.ibm.parmlib , no iplparm :( > so each library was modified for each system so caution was required when > merging the updates from the order libraries. > > > > Carmen Vitullo > > - Original Message - > > From: "william giannelli" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thursday, March 14, 2019 7:25:44 AM > Subject: Re: cloning target and dlib zones > > so for each cloned target I need a separate CSI? > > On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson > wrote: > >> I usually keep 4 different sets of target CSI and Just one DLIB(As we >> accept the previous maintenance only when the previous maintenance has >> baked for some time ) >> >> TG1,TG2,TG3,TG4. >> >> So on the cloning process one qualifier matching to CSI name .. >> >> >> >> On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, >> wrote: >> >>> to maintain 2 different maintenance levels I want to clone my target and >>> dlib. would this require 2 separate CSIs? And would I have to 2 copies of >>> most of the dddefs? >>> thanks >>> Bill >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: cloning target and dlib zones
One Global, two Targets, one DLIB, that's what I've done in a previous shop, for products only,that was the standard, the target zone was named for the sysplex, and the DDDEF's reflected the Plex name in the target datasets in that zone, so my plex name was PLEX1 lets say, so my zone names were TPLEX1 and TPLEX2, for example, and the target dataset names were some hlq.vendor.product.TPLEX1 or 2. dsntype. like I said that was a standard at this shop, we maintained a PROGxx member for each system in the PLEX, if APF is required both PLEX1 and PLEX2 are listed, when applying maint in each system that systems PROG00 linklist or other places were updated to the currently applied target library. I would only apply to the second zone once 1) the maint made it around the PLEX, 2) no issues were found during testing/prod, so one receive, 2 applies, 1 accept. everyone has their favorite way of maintaining a system or product, some because that's how they learned, some because they developed a methodology that works well for them that will provide the ability to maintain the system or product, provide an easy backout if problems and an easy was to clone (if necessary). I've worked with and for Global Services the way we maintained a customer site was very much different than another outsourcer I worked for, and much different that the site I'm currently working at, right or wrong, it's the way that works for me, and I've documented the process from receiving a new order, to installing that order thru migration and maint process. think 1980's, that's what I came into all system catalogs were on the sysres, all uss HFS and ZFS were on the sysres, sys1.proclib, and sys1.ibm.proclib ,sys1.parmlib, and sys1.ibm.parmlib , no iplparm :( so each library was modified for each system so caution was required when merging the updates from the order libraries. Carmen Vitullo - Original Message - From: "william giannelli" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 14, 2019 7:25:44 AM Subject: Re: cloning target and dlib zones so for each cloned target I need a separate CSI? On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson wrote: > I usually keep 4 different sets of target CSI and Just one DLIB(As we > accept the previous maintenance only when the previous maintenance has > baked for some time ) > > TG1,TG2,TG3,TG4. > > So on the cloning process one qualifier matching to CSI name .. > > > > On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, > wrote: > > > to maintain 2 different maintenance levels I want to clone my target and > > dlib. would this require 2 separate CSIs? And would I have to 2 copies of > > most of the dddefs? > > thanks > > Bill > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: cloning target and dlib zones
Target 2 CSI Dlib -1 CSI On Thu, 14 Mar, 2019, 4:36 PM william giannelli, wrote: > so for each cloned target I need a separate CSI? > > On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson > wrote: > > > I usually keep 4 different sets of target CSI and Just one DLIB(As we > > accept the previous maintenance only when the previous maintenance has > > baked for some time ) > > > > TG1,TG2,TG3,TG4. > > > > So on the cloning process one qualifier matching to CSI name .. > > > > > > > > On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, > > wrote: > > > > > to maintain 2 different maintenance levels I want to clone my target > and > > > dlib. would this require 2 separate CSIs? And would I have to 2 copies > of > > > most of the dddefs? > > > thanks > > > Bill > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: cloning target and dlib zones
so for each cloned target I need a separate CSI? On Thu, Mar 14, 2019 at 8:20 AM Jake Anderson wrote: > I usually keep 4 different sets of target CSI and Just one DLIB(As we > accept the previous maintenance only when the previous maintenance has > baked for some time ) > > TG1,TG2,TG3,TG4. > > So on the cloning process one qualifier matching to CSI name .. > > > > On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, > wrote: > > > to maintain 2 different maintenance levels I want to clone my target and > > dlib. would this require 2 separate CSIs? And would I have to 2 copies of > > most of the dddefs? > > thanks > > Bill > > > > -- > > 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: cloning target and dlib zones
I usually keep 4 different sets of target CSI and Just one DLIB(As we accept the previous maintenance only when the previous maintenance has baked for some time ) TG1,TG2,TG3,TG4. So on the cloning process one qualifier matching to CSI name .. On Thu, 14 Mar, 2019, 3:08 PM Bill Giannelli, wrote: > to maintain 2 different maintenance levels I want to clone my target and > dlib. would this require 2 separate CSIs? And would I have to 2 copies of > most of the dddefs? > thanks > Bill > > -- > 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
cloning target and dlib zones
to maintain 2 different maintenance levels I want to clone my target and dlib. would this require 2 separate CSIs? And would I have to 2 copies of most of the dddefs? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: hsm questions
Mike, My guess for the MCDS data component free percentages: In the listcat of the MCDS you will have something similar to; FREESPC517779456 HI-A-RBA---662077440 HI-U-RBA---173260800 *Actual Free Space* The lower percentage free space figure will be: (HI-A-RBA - HI-U-RBA) / HI-A-RBA * 100 In the case above this will be (662077440 - 173260800) / 662077440 * 100 = 73.8 % *Potential Free Space (if reorganised)* The higher percentage free space figure will be: FREESPC / HI-A-RBA * 100 In the case above this will be 517779456 / 662077440 * 100 = 78.2 % Richard Marchant Johannesburg On Wed, Mar 13, 2019 at 10:08 PM MARTIN, MIKE wrote: > Hi all, > > I am fairly new to hsm (been around MVS for decades though). The person > that previously managed hsm left the company and now I have that > responsibility. > > I have a couple of basic questions about hsm... > > > 1. Can I manually delete old ACTIVITY Logs outside of hsm? (in other > words, does hsm keep track of them?) > 2. For the MCDS, Omegamon shows two fields... Percent Free Space Data > Component - 14% and Percent Available Space Data Component - 55.8% > What is the difference? Which one should I care most about? > > Thanks for any help in advance. > > Mike Martin > > This email may contain confidential and privileged material for the sole > use of the intended recipient. If you are not the intended recipient, > please contact the sender and delete all copies. Any review or distribution > by others is strictly prohibited. Personal emails are restricted by policy > of the State Employees' Credit Union (SECU). Therefore SECU specifically > disclaims any responsibility or liability for any personal information or > opinions of the author expressed in this email. > > -- > 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: SMPe "rollout" of maintenance
I should have mentioned that I also have a single global zone for everything at that particular site. The only time I change global zones is when I install a new OS release. It's not that I have to, I just do it that way so that I don't get things mixed up. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe "rollout" of maintenance
I have a target zone for each sysres set and a dlib zone for each dlib set. If I need to add maint (even just one ptf) to a res system, but don't want to change an already existing one, I clone the existing sysres set and target zone and zoneedit the pack names. My catalogs are always set up to use ** and IEASYMxx so that nothing gets messed up. I maintain lots of sites and literally hundreds of zones this way. When I no longer need one, I scratch the sysres set and the dlib set and delete the zones. It's a pretty solid way to handle things. If anything happens due to maintenance, I always have something to fall back to without having to change anything except the IPL volume and the load parms. Brian On Wed, 13 Mar 2019 18:55:02 +, Seymour J Metz wrote: >What happens when you are testing a new service level and you need to install >PTF on the production system? If you apply it to the test system and copy, >then you be running the new service level before you've finished testing it. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List on behalf of >Carmen Vitullo >Sent: Wednesday, March 13, 2019 2:24 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMPe "rollout" of maintenance > >It really depends, I've never been stuck in a situation when I needed to do >this, if so; > >I'll apply to SMP target, copy to TEST SYSRES, TEST, and move to PROD copied >to the alternate SYSRES. my small 3 LPAR PLEX shares the SYSRES, so migration >is copy to SYSRES(A), IPL test from that SYSRES, TEST, IPL PRODA from >SYSRES(A), IPL PRODB from SYSRES(A). if another ptf is required it will be >applied, and very rare occasions, that SYSRES will be IPL'd in test. then >copied to the OTHER SYSRES SYSRES(B). I've not, so far had a requirement that >I need to maintain a third SYSRES or multiple target zones for the OS > >I am prolly not making this sound easy and not posting this correctly, but I >have a documented process that I've been using for many years that works well, >even in a TEST PLEX / PROD PLEX 6 LPAR environment. >difference now is I have a smaller environment and this methodology lends >itself well to these maint process. >if needed I have a third SYRES available in my back pocket > > >Carmen Vitullo > >- Original Message - > >From: "Seymour J Metz" >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, March 13, 2019 1:09:01 PM >Subject: Re: SMPe "rollout" of maintenance > >That lets you install a PTF on the sysres that matches your target zone, but >what happens if you need the PTF on a different sysres? > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List on behalf of >Carmen Vitullo >Sent: Wednesday, March 13, 2019 2:03 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMPe "rollout" of maintenance > >I've seen so many different ways to do this, for me they easiest way; >I maintain one CSI for ZOS, and one target zone, I maintain different levels >of the base/maint on different SYSRES volumes, give me a way back if needed >and the ability to apply those one-off's and test and move to an alternate >SYSRES. >much more to it but I think you get the point. >everything I apply and copy is kept updated in an Excel spreadsheet > >Carmen Vitullo > >- Original Message - > >From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, March 13, 2019 12:53:16 PM >Subject: Re: SMPe "rollout" of maintenance > >On Wed, 13 Mar 2019 12:30:35 -0500, Bill Giannelli >wrote: > >>When I obtain maintenance for an RSU (e.i. for Db2 RSU1902). >>I receive and apply, then implement first in one of our 2 sand boxes, leaving >>our 2nd sand box at our prior maintenance level. >>My question is, before I have rolled out the new maintenance, what if I need >>a one off PTF for the prior maintenance? >>Should 2 CSIs be kept? One for new maintenance and a second one for a prior >>maintenance level. > >Others have different ideas about how to manage your target zones. > >My preference is to always clone a new Target and distribution zone before >applying maintenance. > >When a Target zone is no longer needed i.e. there is no system running that >level of the code and there is no need to go back, the old zones can be >deleted. > >-- >Tom Marchant > >-- >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
Re: Disturbing news in the z/OS 2.4 announcement letter
True. You can use emulators fir file transfer, but they allow control over menu items so you can block this option. There are also z/os side option to block / control use of ind$file. ITschak בתאריך יום ה׳, 14 במרץ 2019, 5:48, מאת Mike Schwab : > Several TN3270E emulators offer file transfer windows. Doesn't Rocket > Software offer something similar? > > On Wed, Mar 13, 2019 at 2:09 PM Don Leahy wrote: > > > > "Withdrawal of ISPF Workstation Agent (WSA) > > > > z/OS V2.4 is planned to be the last release to support the ISPF > Workstation > > Agent (WSA), also known as the ISPF Client/Server Component. WSA is an > > application that runs on your local workstation and maintains a > connection > > between the workstation and the ISPF host. It is primarily used to > transfer > > files between the workstation and the host. IBM recommends using more > > current file transfer solutions such as those provided by the Zowe > Dataset > > Explorer, z/OS FTP, and similar file transfer mechanisms. These solutions > > have more capabilities, including the ability to provide secure > > communications." > > > > > > I have a lot of tools in my box that rely on WSA. WSA is so easy to > > automate using ISPF services that I will hard pressed to find > alternatives > > that are as seamless to use. > > > > On the other hand, I am only a few years away from retirement so I may > not > > bother. :-) > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disturbing news in the z/OS 2.4 announcement letter
See Zowe > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Don Leahy > Sent: Wednesday, March 13, 2019 12:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Disturbing news in the z/OS 2.4 announcement letter > > "Withdrawal of ISPF Workstation Agent (WSA) > > z/OS V2.4 is planned to be the last release to support the ISPF Workstation > Agent (WSA), also known as the ISPF Client/Server Component. WSA is an > application that runs on your local workstation and maintains a connection > between the workstation and the ISPF host. It is primarily used to transfer > files between the workstation and the host. IBM recommends using more > current file transfer solutions such as those provided by the Zowe Dataset > Explorer, z/OS FTP, and similar file transfer mechanisms. These solutions > have more capabilities, including the ability to provide secure > communications." > > > I have a lot of tools in my box that rely on WSA. WSA is so easy to automate > using ISPF services that I will hard pressed to find alternatives that are as > seamless to use. > > On the other hand, I am only a few years away from retirement so I may not > bother. :-) > > -- > 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
