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.
----- Original Message -----
From: "Tom Duerbusch" <[EMAIL PROTECTED]>
To: <IBMVM@LISTSERV.UARK.EDU>
Sent: Wednesday, March 29, 2006 6:17 PM
Subject: Re: [IBMVM] again a problem GCS/VTAM but now related to TUBES/VTAM
Just be sure you have the right saved segment.
Stupid story..
Testing on our z/890 with z/VM 5.1 went fine.
Conversion weekend.
SPXTAPE DUMP all (from z/VM 4.2)
SPXTAPE LOAD all (to z/VM 5.1)
Hours later we IPL'ed VM, all hell broke loose.
Turned out I dump/loaded all the saved segments. At IPL, the oldest ones
(z/VM 4.2) were picked up.
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 3/29/2006 9:04 AM >>>
The level of VM should not have much to do with VTAM as GCS is very stable.
There might be a PTF or two in the last few years. Are you running VM/VTAM
4.2.0?
I see no reason to change the size or location of the VTAM segment from
600-6FF:
q nss name vtama map
FILE FILENAME FILETYPE MINSIZE BEGPAG ENDPAG TYPE CL #USERS PARMREGS
VMGROUP
1370 VTAMA DCSS N/A 00600 006FF SR A 00016 N/A N/A
Ready; T=0.01/0.01 09:54:08
With your new gcs like:
q nss name gcsc map
FILE FILENAME FILETYPE MINSIZE BEGPAG ENDPAG TYPE CL #USERS PARMREGS
VMGROUP
1417 GCSC NSS 0000256K 00000 0000C EW R 00000 OMITTED YES
00700 0074E SR
0074F 0074F SW
00750 009FF SN
01000 0101A SR
0101B 04FFF SN
I am not familiar with VTUBES. If the vendor says that it will not use
storage above 16M, I do not know what to say. I would suggest bring the
machine up to at least 80M to ensure all of GCS is inside the machine (as I
stated we run ALL machines in the GCS group at 106M). It does sound as if
VTUBES is I/O bound under 16M. Have you added a bunch of new devices to it?
Jim
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Pohlen (Mailinglist)
Sent: Wednesday, March 29, 2006 9:52 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: again a problem GCS/VTAM but now related to TUBES/VTAM
Hi listers,
last week I asked for help on a CSA storage problem with pool 231. I got
help by Marcy Cortes and Jim Stracka. Their suggestion for increasing the
GCS shared segment worked. Now the customer has a storage problem with
TUBES-VTAM. The Macro4 support says it cannot GETMAIN more than 5MB of
storage. The virtual machine size is 64MB and MACHINE ESA. The support
personnel of Macro4 does not have a clue what might cause that VTUBES does
apperantly not use storage above 16MB. They told the customer to call IBM
for help. But firstly it is VM/ESA 2.2 and secondly the customer has no
contract on support (even if he had one it would not be useful because
VM/ESA 2.2 is out of service for more than 5 years). Therefore I try it
again with the list hoping someone has - as often before - a good idea, what
might be the reason. I append the GCS segment definition currently in use
for documentation. The 0148 was the old segment and the 0151 is the new
definition.
0148 GCS NSS 0000256K 00000 0000C EW R 00000 OMITTED YES
00400 0044E SR
0044F 0044F SW
00450 005FF SN
01000 0101A SR
0101B 011FF SN
0151 GCS NSS 0000256K 00000 0000C EW S 00000 OMITTED YES
00700 0074E SR
0074F 0074F SW
00750 009FF SN
01000 0101A SR
0101B 04FFF SN
HCPNSS440I Named Saved System (NSS) GCS was successfully saved in fileid
0151.
After installing VTAM-PTFs I had to increase the VTAM segment from 600-6FF
to 600-7FF. There were only a few K which did not fit into the old 600-6FF.
Can it be a solution to reduce the size of the VTAM segment to the
effectively needed capacity? Because of the overlay with the new GCS segment
I have relocated it to 400-5FF. Can this be wrong and I should put it at a
higher location?
Any suggestions are welcome.
Thanks in advance.
Mit freundlichen Grüßen / best regards
Franz Josef Pohlen
--------------------------------------------------------
If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it. Click here for important additional terms relating to
this e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------
