I can't help with the specific question posted, but on this list we often try to help with OP's driving problem. Which in this case seems to be: how to manage a complex CTC configuration? We've managed a complex CTC config since the mid-90s without ever consulting diagrams. The secret sauce is having a comprehensive layout with predictable addresses. Some background.
Before we introduced sysplex circa 1995, we had half a dozen LPARs on three boxes in two data centers. Only a handful of CTCs with random addresses. Too few to be troublesome. We implemented sysplex not by combining systems but by splitting existing systems into multiple plexes and members. Almost overnight we proliferated to over a dozen LPARs. At the same time we converted SNA VTAM connections to (at the time) ESCON CTCs, now FICON. We also created CTCs for XCF PATHIN/PATHOUT. We succeeded in interconnecting every LPAR with *every other* LPAR on every CEC in both data centers. That's a lot of connections. Our IBM consulting CE told us that many shops were finding it increasingly difficult to manage CTC configurations without some sort of 'scheme'. Here's the scheme he suggested. 1. Every CTC address is a 4-digit value in a defined range. We chose 4xyz and 5xyz. Those ranges cannot be used for any other device type. 2. Each digit in an address is assigned a meaning: x = CEC#, y = LPAR#, z = device#. The assignment is arbitrary but must be consistent across the entire enterprise. 3. To satisfy the XCF requirement for separate inbound and outbound CTCs, we (arbitrarily) assign to PATHIN a 4zxy address and to PATHOUT the corresponding 5zxz address. For VTAM it makes no difference. Note that XCF imposes this requirement to avoid the overhead of changing direction in a single CTC, technically very doable but at a cost in performance. 4. When referring to a target CTC, everyone in the enterprise uses the same address coming from any CEC on any LPAR to that CTC. The result is that our 'map' of CTCs is just a table or chart of CECs and LPARs as described. This scheme has remained remarkably stable over the decades. CECs have come and gone; LPARs have been created or (occasionally) decommissioned; the scheme always defines all the CTCs with minimal fuss. We use system symbols to minimize editing changes. I've looked at HCM diagrams. They make my eyes swim. I will concede one drawback to this scheme: it chews up an awful lot of addresses, all the 4's and all the 5's. When we started in the mid-90s, that was not such a problem. We live with it. I presented this scheme at SHARE many years ago, and I believe there's a Red Book with a similar message. For your consideration. . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Sankaranarayanan, Vignesh Sent: Monday, February 18, 2019 9:57 AM To: [email protected] Subject: (External):Re: [EXTERNAL] Re: CTC Exactly why I want to draw/visualise it. I’m dealing with a dozen or more nodes to interconnect. If it’s 16 nodes, that’s 16C2 (combinatorics)... gets mental pretty fast. – Vignesh Mainframe Infrastructure On 18-Feb-2019, at 23:24, Rob Schramm <[email protected]> wrote: Depending on the number of lpars and cecs, A simple drawing can do it. The more connections.. the more complicated the drawing. Personally, drawing it is always how i have really understood it YMMV Rob Schramm On Mon, Feb 18, 2019, 12:13 PM Jerry Whitteridge <[email protected] wrote: > To be able to make sense of CTC definitions I use HCM downloaded to the PC. > Its the only graphical way to review the connections. I also use HCM > to define new CTC connections. For all other HCD definitions I prefer > using HCD and ISPF. > > Jerry Whitteridge > Delivery Manager / Mainframe Architect GTS - Safeway Account > 602 527 4871 Mobile > [email protected] > > IBM Services > > IBM Mainframe Discussion List <[email protected]> wrote on > 02/18/2019 06:09:21 AM: > >> From: ITschak Mugzach <[email protected]> >> To: [email protected] >> Date: 02/18/2019 06:09 AM >> Subject: Re: CTC >> Sent by: IBM Mainframe Discussion List <[email protected]> >> >> I don't have a specific rexx for the problem, but I can give some >> tips > form >> daily experience. I do parsing every day, many times a day, for our >> IronSphere product. IOCP is using a macro language. so: >> >> 1. make every macro a single string. continuation is at column 72, the >> last line in a multi line doesn;t have a comma and a continuation >> char > at >> col 762. >> 2. tokenize the string by replacing every equal sign to blank. >> 3. wordpos the keyword you are looking for. of position is not >> zero, > the >> value is the next word. >> 4. result may be enclosed in parentheses, separated with commas. know >> what you are looking for for second level parsing. >> 5. I use a stem to store the single line macro calls at step 1. >> >> >> best, >> ITschak >> >> On Mon, Feb 18, 2019 at 2:32 PM Sankaranarayanan, Vignesh < >> [email protected]> wrote: >> >>> Hello All, >>> >>> I know this is a long shot but does anyone have any REXX that parses > IOCP >>> and "makes sense" of the CTC definitions? >>> I'm losing my mind trying to learn what I'm seeing.. >>> >>> - Vignesh >>> Mainframe Infrastructure ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
