Re: CTC conventions
I agree with Radoslaw that an elaborate CTC naming convention might be overkill for many shops. OTOH when we introduced sysplex in the mid-90s, we went from a handful of single-purpose LPARs across four CECs to multisystem plexes. We started with no CTCs to speak of, but XCF wants CTCs as backup for CF structures. Hence the number of CTCs ballooned in a short period. Our IBM Top Gun CE suggested a naming scheme because there were circulating stories of confusion and mishandling of CTCs, especially in error situations where an operator calls a sysprog at oh-dark-thirty to report a problem. Imposing some sanity on the chaos seemed like a good idea. A few other comments. -- We run 14 LPARs in 'production', that is day-in day-out for public use. We also run an additional 7 LPARs during non-disruptive DR testing for a total of 21 LPARs spread across (now) three CECs in two data centers. Every LPAR has CTC connections to every other LPAR on every CEC in both data centers. -- We have never needed to configure more than 8 LPARs on a single CEC. Hence our naming scheme provides for both a primary and a backup range of addresses for each LPAR connection. The primary range goes through one FICON director, the secondary range goes through a different director. This doubles the number of connections while providing maximum redundancy. -- Using 'three digit addresses' really means using four digit addresses all beginning with '0'. I believe that's what we started with before sysplexing. That may well be adequate for many shops. Some naming scheme can be helpful for more complex configurations. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, October 18, 2018 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions IMHO as every convention, this one is limited. You cannot put any number of CPCs or LPARs in it. And you don't need it. From the other hand any fixed-lingth field means some lost, overhead, i.e. One hex for CPC? That's to much for two CPCs in a shop and can be completely omitted for single CPC. The same for LPARs - do you really need more than 16 in CTC? Much more? How many bits? Of course it's also possible to define CTC with no reasonable convention at all. The only things which are really checked are CUADD number and UA for device. However all the devices can be numbered consecutively, as well as CU numbers. It would be nightmare to manage ...or not when using special table (and no changes). The advantage is absolutely no lost numbers. BTW: I always use 3-digit device numbers and CU numbers for CTC. YMMV. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
When we adopted the 4*/5* naming convention in the mid-90s, I was a bit queasy about reserving so many addresses (2*4096) for CTCs, but we could afford it at the time. Since then, the number of DASD and tape devices has increased a lot. -- At the time, we managed two data centers with two independent IODFs, so duplicate addresses were possible and in fact existed. We later merged the data centers into a single IODF, which was a very good thing but increased the number of device addresses in use as duplicates were no longer tolerable. -- We implemented DR with a strategy that requires three copies per DASD volume: primary (production), secondary (XRC copy), and tertiary (flash copy of secondary for DR images). Again, a very good thing but a gobbler of device addresses. -- Incremental increase in DASD usage over the years. Probably the smallest contributor to the increase, but as noted above, adding one volume to production is actually a three-fold increase in addresses. The advantage of any CTC naming scheme over just assigning random addresses is that a CTC can be fully identified by address alone: CEC, LPAR, and usage such as XCF vs. VTAM. The stories we heard about sysprog/operator confusion pretty much never materialized as the number of CTCs increased dramatically. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Wednesday, October 17, 2018 9:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions On 10/17/2018 6:44 PM, Jesse 1 Robinson wrote: > In hindsight I rue the decision to set aside both 4xxx and 5xxx addresses. In > practice, the low order digit is severely underused. In the beginning I > thought that we would need several different 'devices' for each LPAR. Never > actually found a need for more than four, 0 - 3. I like Rob Jackson's idea of > assigning even/odd numbers for gazinta and gazouta, or ranges like 0 - 7 and > 8 - F. Eliminating 5xxx, for example, would free up 4096 addresses for DASD. It wasn't your fault. It was IBM's recommendation. The fact is that all but one bit of position 'w' is wasted and position 'x' is nearly always underutilized in the scheme below. However, it's not uncommon at all to have more than 16 LPARs per processor making position 'y' too small in today's world. It works great for small configurations, but should be reworked for larger environments -- perhaps by combining 'w' and 'x' to a single nybble and expanding 'y' to two nybbles. CTC 4-DIGIT NAMING SCHEME: wxyz w - one nibble to distinguish gazinta from gazouta x - one nibble that uniquely represents a processor; assigned by you arbitrarily y - one nibble that represents an LPAR on processor w, such as LPAR id from HCD z - one nibble to complete device address, assigned from 0 up to F -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
IMHO as every convention, this one is limited. You cannot put any number of CPCs or LPARs in it. And you don't need it. From the other hand any fixed-lingth field means some lost, overhead, i.e. One hex for CPC? That's to much for two CPCs in a shop and can be completely omitted for single CPC. The same for LPARs - do you really need more than 16 in CTC? Much more? How many bits? Of course it's also possible to define CTC with no reasonable convention at all. The only things which are really checked are CUADD number and UA for device. However all the devices can be numbered consecutively, as well as CU numbers. It would be nightmare to manage ...or not when using special table (and no changes). The advantage is absolutely no lost numbers. BTW: I always use 3-digit device numbers and CU numbers for CTC. 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: CTC conventions
On 10/17/2018 6:44 PM, Jesse 1 Robinson wrote: In hindsight I rue the decision to set aside both 4xxx and 5xxx addresses. In practice, the low order digit is severely underused. In the beginning I thought that we would need several different 'devices' for each LPAR. Never actually found a need for more than four, 0 - 3. I like Rob Jackson's idea of assigning even/odd numbers for gazinta and gazouta, or ranges like 0 - 7 and 8 - F. Eliminating 5xxx, for example, would free up 4096 addresses for DASD. It wasn't your fault. It was IBM's recommendation. The fact is that all but one bit of position 'w' is wasted and position 'x' is nearly always underutilized in the scheme below. However, it's not uncommon at all to have more than 16 LPARs per processor making position 'y' too small in today's world. It works great for small configurations, but should be reworked for larger environments -- perhaps by combining 'w' and 'x' to a single nybble and expanding 'y' to two nybbles. CTC 4-DIGIT NAMING SCHEME: wxyz w - one nibble to distinguish gazinta from gazouta x - one nibble that uniquely represents a processor; assigned by you arbitrarily y - one nibble that represents an LPAR on processor w, such as LPAR id from HCD z - one nibble to complete device address, assigned from 0 up to F -- 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: CTC conventions
In hindsight I rue the decision to set aside both 4xxx and 5xxx addresses. In practice, the low order digit is severely underused. In the beginning I thought that we would need several different 'devices' for each LPAR. Never actually found a need for more than four, 0 - 3. I like Rob Jackson's idea of assigning even/odd numbers for gazinta and gazouta, or ranges like 0 - 7 and 8 - F. Eliminating 5xxx, for example, would free up 4096 addresses for DASD. OTOH we've never run out of CTC addresses or agonized over which address to use for which device on any LPAR on any CEC. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Wednesday, October 17, 2018 6:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions On 10/17/2018 4:23 PM, Jesse 1 Robinson wrote: > Just to be clear, a CTC naming convention is not tied uniquely to ESCON or > FICON architecture. We implemented a scheme in the mid-90s under ESCON well > before the advent of FICON. It's still in effect. > > The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction > (in or out for XCF) to construct a four-digit unit number. It has served us > well for decades. The only 'cost' is that lots of addresses are reserved for > CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme > could be utilized, but we connect every LPAR in every CEC to every other LPAR > via CTC, so lots of addresses are utilized. We copied your numbering scheme -- you've posted it here before using the "gazinta" and "gazouta" terminology -- and it works well. If we had more total devices, it might have made sense to fold the scheme down into a single 4xxx address range... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
On 10/17/2018 4:23 PM, Jesse 1 Robinson wrote: Just to be clear, a CTC naming convention is not tied uniquely to ESCON or FICON architecture. We implemented a scheme in the mid-90s under ESCON well before the advent of FICON. It's still in effect. The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction (in or out for XCF) to construct a four-digit unit number. It has served us well for decades. The only 'cost' is that lots of addresses are reserved for CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme could be utilized, but we connect every LPAR in every CEC to every other LPAR via CTC, so lots of addresses are utilized. We copied your numbering scheme -- you've posted it here before using the "gazinta" and "gazouta" terminology -- and it works well. If we had more total devices, it might have made sense to fold the scheme down into a single 4xxx address range... -- 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: CTC conventions
Indeed. And I didn't follow their guidelines either, though I certainly borrowed from them. I was loathe to eat into two address ranges. Instead, I have always picked one range, added the even-odd nibble for direction, then a nibble for the LPAR number, and then the device number. Never had enough LPARs or independent CECs to worry about it further. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Wednesday, October 17, 2018 7:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions [External Email] Just to be clear, a CTC naming convention is not tied uniquely to ESCON or FICON architecture. We implemented a scheme in the mid-90s under ESCON well before the advent of FICON. It's still in effect. The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction (in or out for XCF) to construct a four-digit unit number. It has served us well for decades. The only 'cost' is that lots of addresses are reserved for CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme could be utilized, but we connect every LPAR in every CEC to every other LPAR via CTC, so lots of addresses are utilized. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions Thanks Rob, I found that book, but went right past the "ESCON CTC Device Numbering Scheme" on page 5. A virtual beer to you! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Wednesday, October 17, 2018 1:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, -- 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: CTC conventions
Just to be clear, a CTC naming convention is not tied uniquely to ESCON or FICON architecture. We implemented a scheme in the mid-90s under ESCON well before the advent of FICON. It's still in effect. The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction (in or out for XCF) to construct a four-digit unit number. It has served us well for decades. The only 'cost' is that lots of addresses are reserved for CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme could be utilized, but we connect every LPAR in every CEC to every other LPAR via CTC, so lots of addresses are utilized. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions Thanks Rob, I found that book, but went right past the "ESCON CTC Device Numbering Scheme" on page 5. A virtual beer to you! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Wednesday, October 17, 2018 1:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
Thanks Daniel. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Blake, Daniel J [CTR] Sent: Wednesday, October 17, 2018 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Not sure if this is it, https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsearch%3Fq%3DSG24-5666%26lnk%3Dmhsrch%26v%3D18%26en%3Dutf%26lang%3Den%26cc%3Dus&data=02%7C01%7Callan.staller%40HCL.COM%7C1ac56e4f29e5410f0b4308d6345a9c14%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636753961142412784&sdata=xWbEa%2BwMhWUdXFcGzJpBnUskqAioyM1vDTO6%2Fvio8AI%3D&reserved=0 ;-D an -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
Thanks Rob, I found that book, but went right past the "ESCON CTC Device Numbering Scheme" on page 5. A virtual beer to you! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Wednesday, October 17, 2018 1:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
Not sure if this is it, https://www.ibm.com/search?q=SG24-5666&lnk=mhsrch&v=18&en=utf&lang=en&cc=us ;-D an -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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: CTC conventions
Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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 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
CTC conventions
Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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
