Q1- Should one define/use LOCALMSG in COUPLE00 ? I've seen some sites do, some don't.
Ans: That's because it depends. If you are experiencing "no buffer" conditions for local messages, you might need to increase the amount of buffer space. Q2- From Share presentation by Mark Brooks: > People spend way too much time fiddling with Transport Classes. .... > Put at least two paths in each class for each target system. Q21- Is this for CTC only, 1 PI 1 PO from/to each system, so each system can send/get MSG to/from other systems? or, for STR as well? Ans: Any combination of path types can be used. Two or more pathout CTCs, two or more pathout structures, or one or more pathouts of each type. If for STR, is this because 1 path is used for each CF, so 2 CF needs 2 paths? (what if CF-duplex is OFF, or only 1 CF is used?) Ans: Duplexing is irrelevant. Indeed, there is no need to duplex a signal structure. If for STR, what should PI/PO look like for 4 systems & 3 CLASS(small(956), default, big)? Ans: To satisfy the suggestion of two paths per class, you would have a total of 6 signal structures, two for each class. Each system in the sysplex would define each of the 6 structures as PATHOUT and PATHIN. > Make sure the PATHIN MAXMSG values are reasonable for the chosen transport > class length. Q22- What is reasonable? use same MAXMSG for PI that is used for PO? use %50 of PO-maxmsg for PI? ...? Ans: If you run the z/OS Health Checker, it will make sure that the MAXMSG values seem reasonable. The key consideration is making sure the MAXMSG value provides enough buffers to have a reasonable chance of maintaining flow. My rule of thumb developed over the years ( and which is built into health checker), is that there needs to be at least 30 buffers. You may need more. It depends on they dynamics. Large bursts or elongated "dwell" time can be motivation for larger values. Q3- As I understand it, for CTC PATHOUT, class of DEFAULT is used by default. Does this mean that the same DEFAULT buffer pool that is used by STR is also used for CTC? What happens if MSG is bigger than the DEFAULT size? Q31- What if class of DEFAULT is not defined ? Q32- When STR & CTC are being used with 2/3 CLASS sizes(956, med , big), which one should be used for DEFAULT class? For DEFAULT they used: big, if 2 size/class med, if 3 size/class A few sites I've seen, didn't use 956 for DEFAULT. Ans: The DEFAULT class always exists. It is implicitly defined by XCF. Customers can modify the default DEFAULT class definition, and as you have observed, many do. If you do not explicitly assign an outbound path to a class, then it will implicitly be defined to the DEFAULT class. That is true regardless of type of path. In general, signals will be transported via a path assigned to the class from which the buffer was obtained. But any signal is capable of being transported via any operational path. And if at the time of the send, there is no operational path connected to the target system in the desired transport class, any path is fair game. If the signal is larger than the size currently negotiated for the path, XCF will dynamically adjust the size to allow the signal to be sent. These days with recent machines and links, signal structures tend to outperform CTC paths for all signal sizes. Historically, there was a time when CTCs tended to outperform structures for small messages, but that is no longer generally true. You can configure any combination of path types across any range of signal sizes. Functionally it's all the same to XCF. You might have other factors to consider: cost, performance, hassle, ... As signal rates increase, it becomes more important to make good choices. Though there may be exceptions, I generally don't worry much about the choices until the signal rate gets up to about 1000 signals/sec. And certainly by the time it gets up to 5 or 6 thousand signals/sec (or more), I'd be paying attention. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
