On Wednesday, 03/29/2006 at 07:00 ZE2, "Pohlen (Mailinglist)" <[EMAIL PROTECTED]> wrote: > VTAM itself works well and there is only one segment each for both GCS and > VTAM. VTUBES does not complain when the old original sized GCS segment is in > effect, therefore VTAM complains about insufficient CSA storage. It is > always a mess if customers do nothing to keep their system rather actual and > when they change the hardware, in this case replacing a Multiprise with > 3745-Tokenring-SNA-Connection by a t-server with XCA-Ethernet. On the old > Multiprise everything has worked because the Tokenring adapters were handled > by the 3745 and the Ethernet adapters on the t-server are handled by VTAM > itself. The customer has connected more than 600 XID-PUs and then VTAM got > the storage shortage in CSA. The increase of the GCS segment helped with the > CSA shortage. Now VTUBES complains. Perhaps the increase of VTUBES to 128MB > like Jim suggested helps. Otherwise I have advised the customer to change > the terminal-PUs to a Communication Server which saves a lot of the PUs and > XCA lines.
I haven't been following this too closely, but if the GCS segment is located within boundaries of the VTUBES virtual machine and you make common storage larger, then it proportionally reduces the private storage available to VTUBES. You can also use models and ISTEXCCS or ISTEXCSD (can't remember which) to create PUs dynamically, reducing the storage requirements in VTAM. I used to that in a former life. Alan Altmark z/VM Development IBM Endicott
