Simple VTAM-Question?
All, I've modified my VTAM Logon Screen and now want to activate it. Is this possible without an IPL? I guess I have to do a F LLA,REFRESH and then to restart the TN3270-Server. But what do I have to do for the real 3270-Terminals? Restart VTAM? How? Thank you - guess it is a simple question for VTAM-Guys but I'm pretty new in this area Bye, Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple VTAM-Question?
For your TN3270 server you don't need to cycle the server, just refresh the profile. Any new connections will pick up the new USS table. V TCPIP,TN3270,O,PROFILE.DATA.SET For VTAM, use the following F NET,TABLE,OPTION=LOAD,NEWTAB=TABNAME Earl Michael Knigge [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 10/15/2008 04:01 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Simple VTAM-Question? All, I've modified my VTAM Logon Screen and now want to activate it. Is this possible without an IPL? I guess I have to do a F LLA,REFRESH and then to restart the TN3270-Server. But what do I have to do for the real 3270-Terminals? Restart VTAM? How? Thank you - guess it is a simple question for VTAM-Guys but I'm pretty new in this area Bye, Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple VTAM-Question?
Look in the manual of operator commands under modify table (usstab). -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Michael Knigge Sent: Wednesday, October 15, 2008 4:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Simple VTAM-Question? All, I've modified my VTAM Logon Screen and now want to activate it. Is this possible without an IPL? I guess I have to do a F LLA,REFRESH and then to restart the TN3270-Server. But what do I have to do for the real 3270-Terminals? Restart VTAM? How? Thank you - guess it is a simple question for VTAM-Guys but I'm pretty new in this area Bye, Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple VTAM-Question?
Look up the MODIFY NET,TABLE command in the SNA Operation. I think it is something like: F NET,TABLE,NEWTAB=tablename,OLDTAB=tablename but it has been a long time since I had to use it. Michael Knigge wrote: All, I've modified my VTAM Logon Screen and now want to activate it. Is this possible without an IPL? I guess I have to do a F LLA,REFRESH and then to restart the TN3270-Server. But what do I have to do for the real 3270-Terminals? Restart VTAM? How? Thank you - guess it is a simple question for VTAM-Guys but I'm pretty new in this area Bye, Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple VTAM-Question?
Earl Buhrmester schrieb: For your TN3270 server you don't need to cycle the server, just refresh the profile. Any new connections will pick up the new USS table. V TCPIP,TN3270,O,PROFILE.DATA.SET For VTAM, use the following F NET,TABLE,OPTION=LOAD,NEWTAB=TABNAME Thank you Earl - that worked! Bye, Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple VTAM-Question?
Michael I think you need the MODIFY TABLE command. Something like F net,TABLE,OPTION=LOAD,NEWTAB=new_name I am assuming you have revised the table so that it has the same name as it did previously. Note that, as always for a MODIFY command, you need to use the name of the started task procedure, in this case the VTAM started task procedure which not all installations call NET. Here are a couple of extracts from the MODIFY TABLE command text in the SNA Operations manual: quote Load a table to replace an existing table (other than a filter table): MODIFY procname,TABLE,OPTION=LOAD,NEWTAB=new_table_name (,OLDTAB=old_table_name) /quote quote - F TABLE,OPT=LOAD Allows you to replace old_table_name, which is in use, with new_table_name, which is currently not in use, or to reload a table that is in use. All resources currently associated with the old table are re-associated with the new table. Note: If old_table_name is the current value of the DYNMODTB start option, the value of the DYNMODTB start option is changed to new_table_name. If OLDTAB is omitted, it is assumed to be the same as NEWTAB. /quote You need to refresh the library lookaside (LLA) address space for modules other than modules from partitioned data sets in the VTAMLIB concatenation. The MODIFY command to which I pointed you above suffices. As far as the Unformatted System Services (USS - used correctly, of course!) module used by the TN3270 address space is concerned, I'm afraid I can't find any particular description of how that can be replaced. I suspect that you need to issue a VARY TCPIP,tn3270proc,OBEYFILE command against the TN3270 PROFILE - at least the BEGINVTAM/ENDVTAM block - in order to have the TN3270 server refresh a load module referenced by the USSTCP parameter. I hope someone who knows for sure can confirm or correct this guess. Well, welcome to a path to becoming a VTAM specialist. There are fewer and fewer these days. Chris Mason On Wed, 15 Oct 2008 23:01:16 +0200, Michael Knigge [EMAIL PROTECTED] SOFTWARE.DE wrote: All, I've modified my VTAM Logon Screen and now want to activate it. Is this possible without an IPL? I guess I have to do a F LLA,REFRESH and then to restart the TN3270-Server. But what do I have to do for the real 3270-Terminals? Restart VTAM? How? Thank you - guess it is a simple question for VTAM-Guys but I'm pretty new in this area Bye, Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
Martin Well, this is progress. There is quite a big difference between a mode name identifying a mode table entry in the ISTINCLM table - as supplied - and a mode name identifying a mode table entry in a customized mode table - or even ISTINCLM if the same mode table entry is not rigourously defined in each and every VTAM which may encounter that mode name. Incidentally I quite glad you told us about your predecessor - I assume - having actually customized ISTINCLM. This is an unusual step - although not at all forbidden and indeed necessarily recommended for certain customers in the VTAM releases interval between VTAM supporting LEN with the dynamic flavour of the type 2.1 node CDRSC and the urgently required DYNMODTB start option. Much hair might have been torn out down the line trying to figure out what had happened if you hadn't confessed to having a modified ISTINCLM. Which actually gives me a chance to suggest if not a solution for your current problem a strongly recommended measure to set up in all your VTAMs. Since you have now confirmed that not all the mode names you use correspond to mode table entries in ISTINCLM, the following is recommended for VTAM APPN networks. 1. Make sure that you have only one local mode table which contains all the mode table entries you need for all your VTAM systems. For sanity I suggest that you even include mode table entries which may now reside in some VTAMs in ISTINCLM which are not those in ISTINCLM as supplied. 2. Copy that assembled and linkage edited mode table to the local VTAMLIB partitioned data set concatenated to SYS1.VTAMLIB as supplied. 3. Specify the name of that mode table in the DYNMODTB start option. This is what Pat is talking about in his paragraph headed Another point and this is one of the Been there, done that, got the tee shirt. of enabling APPN in VTAM, particularly step 1 which can involve a lot of consolidation work. When I came up with the following paragraph in one of my earlier posts quote Since you are having this experience of differences with different mode names - aka logmodes, also mode table entry names - it may be useful to know whether you use only the mode table entry names which appear in ISTINCLM or you have your own mode table - I suspect the latter. If this is so, do you have multiple mode tables? Do you perhaps see a difference when you use one of the ISTINCLM mode names rather than one of your own mode names? /quote I had in mind precisely the situation you finally described in answer to John Chase's post - OK, it's easier to answer simple questions simply stated without impedimenta! - which, had the response been that indeed you were using an ISTINCLM mode name in one case and a local mode name in the other case, I would have gone on to give you this recommendation. You'll notice, by the way, I had assumed an unmodified ISTINCLM. In principle for any mode name you use, you should have a corresponding mode table entry available in the VTAM supporting the *secondary* side of the eventual session and, where you are using APPN, in any VTAMs where you have a representation of the secondary LU supporting the intermediate session routing (ISR) session connector.[1] I say, in principle since APPN is developed on top of Low Entry Networking (LEN) and this point is very obvious with a purely LEN configuration. I'd have to do some checking to know whether this rule was relaxed at all with APPN but I rather think it can't be. As Pat points out, this point does apply to the point at which the subarea part of the session configuration passes to the APPN part and/or vice versa. Interestingly enough, this is not an issue with subarea nor APPN/HPR, in general. In subarea, the session stage is always end-to-end. In APPN/HPR, assuming a suitable capability in the two end nodes and all intermediate nodes, there is again only one session stage passing over a Rapid Transport Protocol (RTP) pipe. This is also neither an issue with any mode name identifying the VTAM- supplied mode table entries in ISTINCLM but can be both an issue, spawning problems, with locally invented mode names and their mode table entries. Incidentally, I do not wish to give the impression I disapprove of locally invented mode names and their associated mode table entries in a local mode table - just one - as long as they are handled correctly. I hope you can see how vital the session configuration is in all of this and why I have repeatedly asked that you sort out what your session configuration is and tell us all. - I am now taking into account following posts. We have, however, an anomaly and there's every possibility that, if the anomaly is removed, the problem will disappear. I was going to suggest that you fix up your mode tables in such a way that mode name ALTMOD45 is swept up into the local mode table I suggested you set up above. But it may be that you are perfectly happy using
Re: VTAM question: Where does TGN=21 come from?
Martin and Pat I expect Pat's more info means the session configuration as already requested. The word network may not be used in the strict SNA sense here. I think it may be intended to refer to the VTAMs within any one sysplex. The xSIRFMSG was an attempt to remind Martin that, in an earlier post, I had already suggested the full set of xSIRFMSG settings you described. So it's actually precisely the same step. This takes me back to my SNI hands-on classes and the instructor's cry clear the screens when a session setup failure needed to be examined. The screens were the consoles for the four or five VTAMs involved in the SNI configuration. Then the session setup was attempted again and all those lovely messages appeared explaining exactly what the students needed to learn. The How can that be? was usually Why can a session be established A to B when it doesn't work B to A?. Chris Mason On Mon, 8 Sep 2008 16:03:47 -0500, Patrick O'Keefe [EMAIL PROTECTED] wrote: On Mon, 8 Sep 2008 11:27:40 -0500, Chris Mason [EMAIL PROTECTED] wrote: I think this thread should probably be under a new subject unless ir somehow relates back to the TGN=21 issue (whch we have been told to forget :-) ). But in case it DOES relate to TGN=21 I haven't changed it. ... If I ignore everything you've already said, I would say that 087D0001 happens for the reasons given in the IP and SNA Codes manual under SNA sense code 087D with sense-code-specific information 0001, specifically under VTAM hints. ... I tried looking at the various 087D000n sense codes NOT received as a way of guessing the config, but that was too tedious. More info would help. I'd flesh out John's which logmode? with a What APPNCOS is specified in the logmode entry?. And what APPN COSTAB are you using? ... you are using SNI or APPN Border Node (BN) support. ... I'm assuming this, too, and am further assuming it is APPN rather than SNI. And I would tend to blame network-qualified names (or lack thereof) except that I don't see how this would change based on logmode name. ... It would be useful to know whether or not there were xSIRFMSG messages - assuming ALLSSCP is set - shown in any intermediate VTAMs as well as the source VTAM. I'll go a step farther than Chris. Set the following VTAMOPTs on all VTAMs that might be in the search path. ASIRFMSG=ALLSSCP ESIRFMSG=ALLSSCP LSIRFMSG=OLUNNS FSIRFMSG=OLUSSCP SIRFMSG=ALLSSCP After the failure, set them back to their original value (probably NONE) or you're likely to be flooded with messages. ... ... The point about this sort of example is that you wouldn't need to appeal to the list denizens to know what the problem was. I think I'll show a little more mercy than Chris. :-) Searching, particularly searching in a mixed Subarea and APPN network is not exactly straightforward. (You probably will see worse errors than this 087D0001 problem. This one will probably not be too hard to track down.) You would be wise to try to locate proceeding from some of Johnathan Harter's SHARE presentations such as Searching in Mixed APPN/Subarea Networks and APPN LOGMODEs and Class of Service. He's beein giving these (and other APPN-related sessions) for years. Pick the most recent ones for the most up to date info, but look at the older onse, too. He's had to eliminate some things to make room for new info. (Johnathan can fit twice as much in an hour than mere mortals can, but even he has limits.) And I think it is helpful to keep in mind a statement made by Jerzy Buczak (a cohort of both Johnathan and Chris) in a Share session APPN/HPR Problem Determination after describing a peculiar session setup failure. Now you go and listen to Mr Harter's presentation for the 6th time to work out why this route was taken. In other words, this is not necessarily trivial. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
Martin There is a value specified in the APPNCOS operand of all mode table entries defined in the supplied ISTINCLM module. As Pat mentioned, in the case of D4C32XX3 it is #CONNECT. Assuming your predecessor has not made unexpected changes to the COSAPPN member of SYS1.SAMPLIB copied to all VTAMLST partitioned data sets, there will be no problems using COS name #CONNECT since it is one of the names used for one of the tables in the COSAPPN member. The APPNCOS start option is provided for the following situation. When an other node, say as AS/400, attempts to initiate a session and the session request enters this VTAM, it may specify a COS name which is not one of the COS names known to this VTAM. In that case the COS name supplied by the start option is used. Incidentally, I expect you've noticed you're in big trouble if you decided that your substitute COS name should be NONE! The same applies should you want to use the name NONE as the name of your local mode table as referenced by the DYNMODTB start option or NONE as the default mode name as specified by the DYNDLGMD start option. The standard of design among the VTAM developers fell off a bit when those start options were conjured up. Another incidentally, you have managed to read far, far more into the start option description of APPNCOS than I can find! I don't know what happens if the unrecognised/unrecognisable COS name originates in the same VTAM. APPNCOS wasn't really designed for that. VTAM could be excused for not tolerating the unrecognised/unrecognisable COS name given that, in principle, the VTAM developers were entitled to expect that customer VTAM systems programmer should be using COS names which are consistent within the same system. However, any VTAM which is supporting APPN has a dual personality: there is a subarea side and an APPN side. As might be expected if you look at the issue from the point of view of the VTAM developer, all traditional VTAM activity such as supporting the API including managing the initial stage of session setup operates on the subarea side. Requests cross to the APPN side when they need to. That being so, a session setup using a foreign APPN COS name could be treated in the same way as a session setup arriving from a connection to an adjacent APPN node. I had actually forgotten that, if a subarea COS is defined, it becomes the default name for the APPN COS. It would seem that your predecessors as the VTAM systems programmers perhaps as far back as the early 1980s - which, being more that 20 years ago, could have been you yourself, I guess - had implemented what Dick Salerno, the great SNI educator, used to call COS structure into your subarea, perhaps SNI, network. Thus you have the subarea COS name INTERACT mapping minimally I expect to VR entries which specify transmission priority 1 - or the not really recommended 2 - rather than 0. I'd support your expectation that there would be a message if there was a problem with the APPN COS name. I just know there is probably a fully logical explanation that makes sense only when Johnathan Harter has explained it! I hope your paragraph defending your Subject line was a review of your thinking at the time you were composing your first post in this thread and that you now know from where that previously troublesome 21 comes, namely section 4.2.3 Transmission Groups in SG24-3669. Chris Mason On Mon, 8 Sep 2008 16:54:17 -0500, Martin Kline [EMAIL PROTECTED] wrote: I'd flesh out John's which logmode? with a What APPNCOS is specified in the logmode entry?. And what APPN COSTAB are you using? None. My predecessor (oh, yes, I told you to forget I inherited this mess) never coded APPNCOS. I also find no MAPSTO statements, and APPNCOS is not coded in the VTAM start parameters. However, since COS=INTERACT is coded in the ALTMOD45 logmode entry, that name should also used for the APPNCOS. Since APPNCOS is not coded on the start parameters, I have no idea what occurs if INTERACT not also defined as an APPNCOS. Now, in reading about APPNCOS, I see that (please forgive my crude interpretation) the connection I am trying to make may have both APPN and subarea COS components, crossing from sscp to sscp to ee to sscp to appl utilizing ens, bns, nns, tgns, vrs, ers, and more. Well, that's certainly straightforward! I wonder why I didn't see that in the first place. Still, why can't VTAM find the application when all I change is the logmode and logmode-specified COS? If the COS or logmode is invalid or incompatible, or whatever else could be wrong, I'd expect to see an appropriate message. Being ignorant of APPNCOS, my initial title was appropriate. I found TGN=21 when I displayed the inter-system connections, but found TGN=21 nowhere in my startup parameters nor documented in a standard IBM manual as a default. TGN=21 is not coded in any routes, so I didn't see how the connection ever worked. I think Chris was right when
Re: VTAM question: Where does TGN=21 come from?
Pat Apropos of what is used of the contents of a mode table entry found in an intermediate mode table, when there is a change of session stage, there is an opportunity to respond to the pacing values in a mode table entry.[1] I'd have to dig around to remind myself about this but I seem to recall something on these lines. Obviously the protocol fields in the BIND image don't change - except that, from sources other than the local mode table entry, the limited resources bit could be set on. As well as Johnathan Harter's presentation material which can be located on the web there is Chapter 10. Logmode and COS Resolution in a Mixed Network in Jerzy Buczak's SG24-4656-01. Chris Mason [1] I was going to include RU sizes on the basis that these are values in the TS Usage fields alongside the pacing values. However, this would imply rebuilding chains into the original units of data and then rechaining them and that doesn't happen. On Mon, 8 Sep 2008 17:14:59 -0500, Patrick O'Keefe [EMAIL PROTECTED] wrote: On Mon, 8 Sep 2008 15:06:06 -0500, Martin Kline [EMAIL PROTECTED] wrote: ... D4C32XX3, which is located in the default logmode table on both lpars. ... That is an IBM-supplied logmode. Unless it has been modified at you shop it specifies APPNCOS=#CONNECT. ... ALTMOD45, which is located in the LOGMOD01, the assigned modetab for the origin LU on the origin system, and in ISTINCLM on the destination system. What APPNCOS does it specify? If none, I think it will use whatever is specified in your APPNCOS parm in your ATCSTRxx. Another point. In the APPN world, a dynamically created CDRSC gets assigned the MODETAB specified in the VTAM parm DYNMODTB. IBM recommends that it contain every LOGMODE name in your network that is not in ISTINCLM. Only the COS and APPNCOS parms are used when the DYNMODTB table is referenced, but you can get failures if entries aren't found. The search flow (including which tables are used) depends on whether the primary LU or secondary LU initiates the session request. I've sat through Johnathan's LOGMODE and COS Table pitch only 5 times so am not capable of giving any further detail. Chris will have to take it from here (hopefully correcting my mistakes). Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
Thanks for all your input, Chris. I believe I have a basic understanding of the issue at hand, and a plan of attack. As I originally suspected, it does have something to do with COS and logmodes, but just not what I expected. Now, back to the original title. you now know from where that previously troublesome 21 comes, namely section 4.2.3 Transmission Groups in SG24-3669. I'm probably offending someone by saying this, but Redbooks are not, in my opinion, the best place to document default values. This book in particular is almost 10 years old. (At least 2 computer lifetimes). During my earlier testing of the connectivity issue, I did encounter a problem with this exact issue. I could not enable a backup link because I received a message indicating the TGN was already used. The TGN was 21. Hence, the question, why TGN=21 when I did not specify TGN? The standard IBM publications for our release of z/OS (1.7) never mention TGN=21 as a default. I don't believe they even mentioned that a second link between systems would have to specify a TGN. I'd submit a RFC, but z/OS 1.7 is about to go unsupported, the doc for the 1.9 version we are planning to install won't get changed, and 1.10 is also unlikely to have doc changes. On Tue, 9 Sep 2008 09:52:31 -0500, Chris Mason [EMAIL PROTECTED] wrote: Martin There is a value specified in the APPNCOS operand of all mode table entries defined in the supplied ISTINCLM module. As Pat mentioned, in the case of D4C32XX3 it is #CONNECT. Assuming your predecessor has not made unexpected changes to the COSAPPN member of SYS1.SAMPLIB copied to all VTAMLST partitioned data sets, there will be no problems using COS name #CONNECT since it is one of the names used for one of the tables in the COSAPPN member. The APPNCOS start option is provided for the following situation. When an other node, say as AS/400, attempts to initiate a session and the session request enters this VTAM, it may specify a COS name which is not one of the COS names known to this VTAM. In that case the COS name supplied by the start option is used. Incidentally, I expect you've noticed you're in big trouble if you decided that your substitute COS name should be NONE! The same applies should you want to use the name NONE as the name of your local mode table as referenced by the DYNMODTB start option or NONE as the default mode name as specified by the DYNDLGMD start option. The standard of design among the VTAM developers fell off a bit when those start options were conjured up. Another incidentally, you have managed to read far, far more into the start option description of APPNCOS than I can find! I don't know what happens if the unrecognised/unrecognisable COS name originates in the same VTAM. APPNCOS wasn't really designed for that. VTAM could be excused for not tolerating the unrecognised/unrecognisable COS name given that, in principle, the VTAM developers were entitled to expect that customer VTAM systems programmer should be using COS names which are consistent within the same system. However, any VTAM which is supporting APPN has a dual personality: there is a subarea side and an APPN side. As might be expected if you look at the issue from the point of view of the VTAM developer, all traditional VTAM activity such as supporting the API including managing the initial stage of session setup operates on the subarea side. Requests cross to the APPN side when they need to. That being so, a session setup using a foreign APPN COS name could be treated in the same way as a session setup arriving from a connection to an adjacent APPN node. I had actually forgotten that, if a subarea COS is defined, it becomes the default name for the APPN COS. It would seem that your predecessors as the VTAM systems programmers perhaps as far back as the early 1980s - which, being more that 20 years ago, could have been you yourself, I guess - had implemented what Dick Salerno, the great SNI educator, used to call COS structure into your subarea, perhaps SNI, network. Thus you have the subarea COS name INTERACT mapping minimally I expect to VR entries which specify transmission priority 1 - or the not really recommended 2 - rather than 0. I'd support your expectation that there would be a message if there was a problem with the APPN COS name. I just know there is probably a fully logical explanation that makes sense only when Johnathan Harter has explained it! I hope your paragraph defending your Subject line was a review of your thinking at the time you were composing your first post in this thread and that you now know from where that previously troublesome 21 comes, namely section 4.2.3 Transmission Groups in SG24-3669. Chris Mason On Mon, 8 Sep 2008 16:54:17 -0500, Martin Kline [EMAIL PROTECTED] wrote: I'd flesh out John's which logmode? with a What APPNCOS is specified in the logmode entry?. And what APPN COSTAB are you using? None. My predecessor (oh, yes, I told you to forget I
Re: VTAM question: Where does TGN=21 come from?
Martin Thanks for all your input, Chris. I believe I have a basic understanding of the issue at hand, and a plan of attack. As I originally suspected, it does have something to do with COS and logmodes, but just not what I expected. Please let us know how you resolve your problems with mode names, their associated mode table entries and the included APPN COS names. Of course, if there are still issues to discuss the list is here to help. Do be prepared to go into some detail over the logical configuration both from the subarea and APPN perspective and stand by with the sets of start options for the VTAM nodes involved. Now, back to the original title. you now know from where that previously troublesome 21 comes, namely section 4.2.3 Transmission Groups in SG24-3669. I'm probably offending someone by saying this, but Redbooks are not, in my opinion, the best place to document default values. This book in particular is almost 10 years old. (At least 2 computer lifetimes). In principle I agree that a redbook should not be regarded as the official document in which to find key matters definitively described. GG24-3669 is *not* your typical redbook. You will find plenty of instances in my comments in this list and other generic newsgroups where I describe redbooks as curates' eggs. They tend to be as good as the combined competence of the assignee in charge and the, typically plural, residents allows, perhaps leavened by the expertise of the listed reviewers if, at the time they are expected to perform the reviews, they happen to have some unplanned time on their hands. You might find a redbook provides sufficient samples sufficiently well explained to help you get started with some new activity - or you might not. This is the usual how to redbook and the two I offered, the Subarea to APPN Migration redbooks, are among the better examples of this type - not perfect and the guy in charge would accept that criticism since I provided him with an improved version, sadly never made available publicly. In any case GG24-3669 doesn't attempt to be a how to redbook. It is designed to be a digestible version of the official document describing APPN architecture and it succeeds in that role very well indeed. I know the principle authoress who created this redbook and she is an almost excessively both competent and conscientious lady. Sadly she has been lost to IBM networking following IBM's loss of nerve in the networking arena. GG24-3669 was originally entitled The APPN Tutorial, a title which fitted its purpose perfectly. Unfortunately some suit decided that the title wasn't snazzy enough and so it got renamed to the ridiculous Inside APPN and HPR - The Essential Guide to New SNA. It hasn't been reissued in the last so many years because it describes an architecture and one test of a good architecture is that it doesn't need to be changed too rapidly. There have been extensions to APPN since GG24-3669- 03 but they are all covered in separate documents similar to the document on which GG24-3669 was based - but thankfully a little bit more digestible. You will find all the documents at the APPN Implementers' Workshop documents page, http://www.networking.ibm.com/app/aiwdoc.htm GG24-3669 is a digest of Systems Network Architecture APPN Architecture Reference, SC30-3422-04, dated December 1996 and it is no coincidence that the last edition of GG24-3669 is dated June 1997. Although the more recent APPN extensions are available in four manuals in PDF form, the Architecture Reference (and other older documents) are available only in book format. I am fortunate that a recent thread in the IBM-MAIN list included a reference to where the Softcopy Reader could be found. At the time I simply downloaded it but, to be 100% sure I could provide you with the definitive reference which justified the default transmission group number 21, I installed the product, downloaded the book and isolated section 2.9.5.9.1 Partitioning the TG Number Space. Here you will find Table 9-9 which indicates that the first negotiated number - that means neither side *predefined* a number - is 21. It is no great surprise that Table 2 in GG24-3669-03 and Table 9-9 in SC30- 3422-04 have much in common. I think when you have read through both SC30-3422-04 and GG24-3669-03 you will agree that the redbook is the more preferable source. During my earlier testing of the connectivity issue, I did encounter a problem with this exact issue. I could not enable a backup link because I received a message indicating the TGN was already used. The TGN was 21. Hence, the question, why TGN=21 when I did not specify TGN? The standard IBM publications for our release of z/OS (1.7) never mention TGN=21 as a default. I don't believe they even mentioned that a second link between systems would have to specify a TGN. You may like to expand on what you are describing here since I do not recognise
Re: VTAM question: Where does TGN=21 come from?
Chris said: a whole lot of stuff Let's start over. Throw away everything you think you know about my network. When I use one logmode to connect from one SNA application to a second SNA application in another network, it works fine. When I use another logmode to connect from the same application to the same second application, I get 087D0001, indicating the target application cannot be found. What can cause this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Kline Chris said: a whole lot of stuff Let's start over. Throw away everything you think you know about my network. When I use one logmode to connect from one SNA application to a second SNA application in another network, it works fine. Which logmode is that? When I use another logmode to connect from the same application to the same second application, I get 087D0001, indicating the target application cannot be found. Which logmode is that? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
Martin If I ignore everything you've already said, I would say that 087D0001 happens for the reasons given in the IP and SNA Codes manual under SNA sense code 087D with sense-code-specific information 0001, specifically under VTAM hints. Note that, ignoring everything you've already said, I would be obliged to assume in the first instance that the use of the word network indicates that you are using SNI or APPN Border Node (BN) support. This is because you can communicate with session setup support - and generally one assumes that customers communicate between networks with session setup support - only using SNI protocols or APPN BNs. Now, ignoring your instructions, I recall that you have no NCPs so you cannot be using SNI. Also, I think it's fair to say, I detected that you would not be using APPN BNs - but I could be wrong. Quixotically, you could be attempting to connect networks, using Low Entry Networking (LEN) - but I don't want to waste time on what is very unlikely. I think it's important to know what you mean when you use the word network. What we need is something to fill the gap left by ignoring everything we have heard before. As John Chase implied, we need specifics. We need to know about the configuration between the two nodes supporting the applications. We need to know where the mode table entries (logmodes) are defined if they are not both taken from the mode table entries defined in ISTINCLM. It would be useful to know whether or not there were xSIRFMSG messages - assuming ALLSSCP is set - shown in any intermediate VTAMs as well as the source VTAM. Given the evidence presented so far, this looks like a two-pipe problem. I can't think I've come across a case where a change in mode name changed a session setup success to a session setup failure. I can see how it could be done but only with some prior effort. For example, if you deliberately specified that the route would insist on secure links end-to-end with a mode table entry specifying a COS table name which required all links to specify some level of security, you would force a failure if such a concatenation of secure links was not in place for selection. The point about this sort of example is that you wouldn't need to appeal to the list denizens to know what the problem was. Also, ignoring your appeal to forget everything learned so far and knowing that the TG number 21 is a sure sign of APPN-capable links being present, I have to say that the description of 087D0001 has not been well adjusted in order to take account of the presence of APPN as well as subarea in the capabilities of a particular VTAM. 087D0001 is a sense code which relates to processing a session search request through an adjacent SSCP table. When APPN is present, switching the search request into the APPN part of the network is handled very much like passing the search request to another SSCP (CDRM). This is not evident from the description of the sense code and is only vaguely evident under VTAM hints. Chris Mason On Mon, 8 Sep 2008 08:56:48 -0500, Martin Kline [EMAIL PROTECTED] wrote: Chris said: a whole lot of stuff Let's start over. Throw away everything you think you know about my network. When I use one logmode to connect from one SNA application to a second SNA application in another network, it works fine. When I use another logmode to connect from the same application to the same second application, I get 087D0001, indicating the target application cannot be found. What can cause this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
When I use one logmode to connect from one SNA application to a second SNA application in another network, it works fine. Which logmode is that? D4C32XX3, which is located in the default logmode table on both lpars. When I use another logmode to connect from the same application to the same second application, I get 087D0001, indicating the target application cannot be found. Which logmode is that? ALTMOD45, which is located in the LOGMOD01, the assigned modetab for the origin LU on the origin system, and in ISTINCLM on the destination system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
On Mon, 8 Sep 2008 11:27:40 -0500, Chris Mason [EMAIL PROTECTED] wrote: I think this thread should probably be under a new subject unless ir somehow relates back to the TGN=21 issue (whch we have been told to forget :-) ). But in case it DOES relate to TGN=21 I haven't changed it. ... If I ignore everything you've already said, I would say that 087D0001 happens for the reasons given in the IP and SNA Codes manual under SNA sense code 087D with sense-code-specific information 0001, specifically under VTAM hints. ... I tried looking at the various 087D000n sense codes NOT received as a way of guessing the config, but that was too tedious. More info would help. I'd flesh out John's which logmode? with a What APPNCOS is specified in the logmode entry?. And what APPN COSTAB are you using? ... you are using SNI or APPN Border Node (BN) support. ... I'm assuming this, too, and am further assuming it is APPN rather than SNI. And I would tend to blame network-qualified names (or lack thereof) except that I don't see how this would change based on logmode name. ... It would be useful to know whether or not there were xSIRFMSG messages - assuming ALLSSCP is set - shown in any intermediate VTAMs as well as the source VTAM. I'll go a step farther than Chris. Set the following VTAMOPTs on all VTAMs that might be in the search path. ASIRFMSG=ALLSSCP ESIRFMSG=ALLSSCP LSIRFMSG=OLUNNS FSIRFMSG=OLUSSCP SIRFMSG=ALLSSCP After the failure, set them back to their original value (probably NONE) or you're likely to be flooded with messages. ... ... The point about this sort of example is that you wouldn't need to appeal to the list denizens to know what the problem was. I think I'll show a little more mercy than Chris. :-) Searching, particularly searching in a mixed Subarea and APPN network is not exactly straightforward. (You probably will see worse errors than this 087D0001 problem. This one will probably not be too hard to track down.) You would be wise to try to locate proceeding from some of Johnathan Harter's SHARE presentations such as Searching in Mixed APPN/Subarea Networks and APPN LOGMODEs and Class of Service. He's beein giving these (and other APPN-related sessions) for years. Pick the most recent ones for the most up to date info, but look at the older onse, too. He's had to eliminate some things to make room for new info. (Johnathan can fit twice as much in an hour than mere mortals can, but even he has limits.) And I think it is helpful to keep in mind a statement made by Jerzy Buczak (a cohort of both Johnathan and Chris) in a Share session APPN/HPR Problem Determination after describing a peculiar session setup failure. Now you go and listen to Mr Harter's presentation for the 6th time to work out why this route was taken. In other words, this is not necessarily trivial. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
I'd flesh out John's which logmode? with a What APPNCOS is specified in the logmode entry?. And what APPN COSTAB are you using? None. My predecessor (oh, yes, I told you to forget I inherited this mess) never coded APPNCOS. I also find no MAPSTO statements, and APPNCOS is not coded in the VTAM start parameters. However, since COS=INTERACT is coded in the ALTMOD45 logmode entry, that name should also used for the APPNCOS. Since APPNCOS is not coded on the start parameters, I have no idea what occurs if INTERACT not also defined as an APPNCOS. Now, in reading about APPNCOS, I see that (please forgive my crude interpretation) the connection I am trying to make may have both APPN and subarea COS components, crossing from sscp to sscp to ee to sscp to appl utilizing ens, bns, nns, tgns, vrs, ers, and more. Well, that's certainly straightforward! I wonder why I didn't see that in the first place. Still, why can't VTAM find the application when all I change is the logmode and logmode-specified COS? If the COS or logmode is invalid or incompatible, or whatever else could be wrong, I'd expect to see an appropriate message. Being ignorant of APPNCOS, my initial title was appropriate. I found TGN=21 when I displayed the inter-system connections, but found TGN=21 nowhere in my startup parameters nor documented in a standard IBM manual as a default. TGN=21 is not coded in any routes, so I didn't see how the connection ever worked. I think Chris was right when he indicated that the person who set up the network originally just happened to get it to work eventually. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
On Mon, 8 Sep 2008 15:06:06 -0500, Martin Kline [EMAIL PROTECTED] wrote: ... D4C32XX3, which is located in the default logmode table on both lpars. ... That is an IBM-supplied logmode. Unless it has been modified at you shop it specifies APPNCOS=#CONNECT. ... ALTMOD45, which is located in the LOGMOD01, the assigned modetab for the origin LU on the origin system, and in ISTINCLM on the destination system. What APPNCOS does it specify? If none, I think it will use whatever is specified in your APPNCOS parm in your ATCSTRxx. Another point. In the APPN world, a dynamically created CDRSC gets assigned the MODETAB specified in the VTAM parm DYNMODTB. IBM recommends that it contain every LOGMODE name in your network that is not in ISTINCLM. Only the COS and APPNCOS parms are used when the DYNMODTB table is referenced, but you can get failures if entries aren't found. The search flow (including which tables are used) depends on whether the primary LU or secondary LU initiates the session request. I've sat through Johnathan's LOGMODE and COS Table pitch only 5 times so am not capable of giving any further detail. Chris will have to take it from here (hopefully correcting my mistakes). Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
Martin Further to my previous post, I'm very puzzled as to how you could have been setting up those links without appreciating that you were using APPN and that use of APPN links could be responsible for the unexplained transmission group numbers. In addition, since you have been establishing APPN links rather than subarea links and I would have thought that, in the process of setting up such links, you would have appreciated that these were not subarea links. I'm having to guess wildly - but, according to the principle Sir Arthur Conan- Doyle put into the mouth of Sherlock Holmes,[1] it goes as follows: - You are on z/OS V1R6 or earlier - You want to use XCF links in the Communications Server (CS) IP component (originally known as TCP/IP for MVS) - You are now obliged to specify XCFINIT=YES - You are told in a message during VTAM startup that XCF cannot be initialized - You discover that you need to specify NODETYPE=NN or EN - You do so and VTAM to VTAM XCF links are established between members of the sysplex with TG number 21 The above I can just about understand could happen with an established subarea network which has been running along smoothly for aeons. You would need to be at z/OS V1R6 or earlier since, from V1R7, XCFINIT=DEFINE is the default for a subarea network and this would allow XCF links for the CS IP component without forcing the creation of XCF links for the SNA component (VTAM) - and the subarea network could go slumbering on as if it was still the 1980s! Note that the XCF links are links between VTAM acting as a type 2.1 node as opposed to acting as a type 5 node, that is, APPN links (in the case of links between VTAMs) as opposed to subarea links. What I cannot explain is how/why you have converted your subarea CTC links (VBUILD TYPE=CA) to APPN CTC links (VBUILD TYPE=LOCAL) or have added some APPN CTC links in parallel to your subarea CTC links. Furthermore, if you had set these up in parallel with the XCF links you would have seen them defined with TG number 22. You didn't mention this[2] so I assume you set them up only in order to set up links between sysplexes - which tends to indicate you knew what you were doing - but you didn't ... One rather far-fetched explanation is that someone else who knew (approximately) what he/she was doing was in the process of setting all this up but was let go and is incommunicado! Another point in favour of the let go theory is that you have not touched VTAM for 20 years but you do not have any NCPs. Someone must have been in charge of converting the network in the last few years in order to deal with the removal of 3745s - surely? Incidentally - perhaps not incidentally for you - when you have digested the implications of using APPN links as well as subarea links and factored this consideration into what you now observe happening to your sessions, you might like to restate your problem concerning it not being possible to used some logmodes between networks. Talk of between networks sounds as if it relates to SNI but you don't have any NCPs so it can't! That's a shame in a way since, indeed, it is possible to have problems trying to use different mode names between networks and the technique for dealing with that problem was a challenge to try to teach - although different COS names was the more difficult challenge! You could have different networks without SNI (and NCPs) but then, before using APPN, you'd be relying on LEN links (links between nodes presenting a basic type 2.1 node appearance to each other). But, again, this would be too complex an environment of which not to be aware - and was introduced into VTAM in 1988 which puts it just at the limit of your 20 years. Furthermore, you should be aware that the subarea PATH does not extend over the LEN link. Still trying to work out what your perceived logmode might be, I worry that you may be violating the Jim Fletcher rule of APPN networking in VTAM. This rule is to avoid having an APPN route in parallel with a subarea route. This arrangement of routes sometimes works and sometimes does not. The at-the- time VTAM developer Jim Fletcher used to help out a lot in the VM-based fora of the mid-90s and had so many problems trying to sort out and then explain problems customers directly or though their SEs were reporting which had this arrangement of routes as a feature of their configuration, often as a migration step, that he finally just advised never to migrate your configuration in such a way that such an arrangement of routes was created. Chris Mason [1] ...when you have eliminated the impossible, whatever remains, however improbable, must be the truth. But then, making sure I got the words of the quotation above correct, I (re) discovered this other quotation: I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.
Re: VTAM question: Where does TGN=21 come from?
Hi Chris, snip Further to my previous post, I'm very puzzled as to how you could have been setting up those links without appreciating that you were using APPN and that use of APPN links could be responsible for the unexplained transmission group numbers. In addition, since you have been establishing APPN links rather than subarea links and I would have thought that, in the process of setting up such links, you would have appreciated that these were not subarea links. unsnip Actually, I wasn't setting up the links. They already exist. I managed to partially break them, and want to ensure I understand the underlying problem before moving forward. snip I'm having to guess wildly - but, according to the principle Sir Arthur Conan- Doyle put into the mouth of Sherlock Holmes,[1] it goes as follows: - You are on z/OS V1R6 or earlier - You want to use XCF links in the Communications Server (CS) IP component (originally known as TCP/IP for MVS) - You are now obliged to specify XCFINIT=YES - You are told in a message during VTAM startup that XCF cannot be initialized - You discover that you need to specify NODETYPE=NN or EN - You do so and VTAM to VTAM XCF links are established between members of the sysplex with TG number 21 The above I can just about understand could happen with an established subarea network which has been running along smoothly for aeons. You would need to be at z/OS V1R6 or earlier since, from V1R7, XCFINIT=DEFINE is the default for a subarea network and this would allow XCF links for the CS IP component without forcing the creation of XCF links for the SNA component (VTAM) - and the subarea network could go slumbering on as if it was still the 1980s! unsnip We're at z/OS 1.7. We use the default XCFINIT=DEFINE, but we have a mixed conglomeration of CTC, XCF, OSA and CIP links. We have two separate sysplexes. Both sysplexes have four LPARs. All of the LPARs are on a total of five machines. For background, the network team disolved after the primary SNA support person left the company, and his backup, for lack of a better name, refused to deal with SNA. Nothing had changed for some time until we added the fourth LPAR to one of the sysplexes, and I started monkeying around. snip Note that the XCF links are links between VTAM acting as a type 2.1 node as opposed to acting as a type 5 node, that is, APPN links (in the case of links between VTAMs) as opposed to subarea links. What I cannot explain is how/why you have converted your subarea CTC links (VBUILD TYPE=CA) to APPN CTC links (VBUILD TYPE=LOCAL) or have added some APPN CTC links in parallel to your subarea CTC links. Furthermore, if you had set these up in parallel with the XCF links you would have seen them defined with TG number 22. You didn't mention this[2] so I assume you set them up only in order to set up links between sysplexes - which tends to indicate you knew what you were doing - but you didn't ... One rather far-fetched explanation is that someone else who knew (approximately) what he/she was doing was in the process of setting all this up but was let go and is incommunicado! unsnip Bingo! snip Another point in favour of the let go theory is that you have not touched VTAM for 20 years but you do not have any NCPs. Someone must have been in charge of converting the network in the last few years in order to deal with the removal of 3745s - surely? unsnip To the best of my knowledge, we have not had an NCP here for at least eight years. How the conversion happened is unknown. As far as I can tell, we use CTCs between the two networks. snip Incidentally - perhaps not incidentally for you - when you have digested the implications of using APPN links as well as subarea links and factored this consideration into what you now observe happening to your sessions, you might like to restate your problem concerning it not being possible to used some logmodes between networks. Talk of between networks sounds as if it relates to SNI but you don't have any NCPs so it can't! That's a shame in a way since, indeed, it is possible to have problems trying to use different mode names between networks and the technique for dealing with that problem was a challenge to try to teach - although different COS names was the more difficult challenge! You could have different networks without SNI (and NCPs) but then, before using APPN, you'd be relying on LEN links (links between nodes presenting a basic type 2.1 node appearance to each other). But, again, this would be too complex an environment of which not to be aware - and was introduced into VTAM in 1988 which puts it just at the limit of your 20 years. Furthermore, you should be aware that the subarea PATH does not extend over the LEN link. Still trying to work out what your perceived logmode might be, I worry that you may be violating the Jim Fletcher rule of APPN networking in VTAM. This rule is to avoid having an APPN route in
Re: VTAM question: Where does TGN=21 come from?
Martin If you have XCFINIT=DEFINE, how do you have VTAM XCF links? Although you specify XCFINIT as a VTAM start option, this is purely in order to set up the possibility to have XCF links. The links can be used by either or both of the components of Communications Server (CS), IP (originally TCP/IP for MVS) and SNA (VTAM). If you have XCFINIT=DEFINE and NODETYPE=NN or EN, you are obliged to enter a VARY ACT command for the VTAM invented major node ISTLSXCF in order to convert, as it were, XCFINIT=DEFINE to XCFINIT=YES. Is it perhaps that your XCF links are only those set up for CS IP? This throws some doubt on whether your other links are SNA rather than IP before we even get to whether or not they are used with subarea SNA or APPN SNA. You should use the D NET,STATIONS command in each of your VTAMs in order to be sure which of your links are subarea links. This command will show the names of PU statements - which are in reality adjacent link stations to adjacent subarea nodes. Where the adjacent link station is ACTIV that will indicate you have a working subarea link. You seem to know about PATH statements, ERs, VRs, subarea COS and mode names so, limiting the links you consider just to those identified as active with the D NET,STATIONS command, you should be able to work out what connectivity for sessions you have which relies purely on the subarea part of the network. Now you should use the D NET,CLSTRS command in each of your VTAMs in order to be sure which of your links are APPN links. Again this command will show the names of PU statements - which, in this case, may double as real SNA PU entities but which are always also adjacent link stations to adjacent nodes, either type 2.1 nodes (we will assume always APPN for the moment) or type 2.0 nodes (subarea SNA peripheral nodes). (The type 2.1 nodes can incorporate the functions of a type 2.0 node.) Where the adjacent link station is ACTIV that will indicate you may have an APPN link. From what you know of your configuration you should be able to work out whether the adjacent node is a type 2.0 node or a type 2.1 node. If the adjacent node is a type 2.1 node, the link will be an APPN link. (I am assuming your predecessor has not left you any LEN links.) If the adjacent node is VTAM it will always be an APPN link. An important point of clarity from the last paragraph is that you should be clear - no help from IBM documentation and messages - over what 2, 2.1 and 2.0 mean when talking SNA. Only an SNA node entity can be 2.1 in spite of IBM stupidity in messages and documentation pretending it applies to the SNA PU entity. At least that stupidity can be ignored since 2.1 must mean node. Only an SNA node entity can be 2.0 in spite of similar IBM stupidity but now it cannot be ignored because, by 2.0, a node entity or a PU entity might be meant in spite of the fact that there is no point in qualifying 2 in reference to a PU entity. I am assuming that, from the names found in the D NET,STATIONS and D NET,CLSTRS commands, you will be able to find out more about the resources defined in the corresponding VTAMLST members. You should now be able to construct a diagram of the nodes which make up the subarea part of the network and a separate diagram for the APPN part of the network. You can verify that the subarea network definitions are working by using the D NET,CDRMS command in each of your VTAMs in order to see whether you have full mesh CDRM connectivity or whether part of the mesh is missing. In each case you will always see the home CDRM as ACTIV but you may not see each away CDRM as ACTIV. I'm sure you remember all this stuff. I expect that the VTAM in the new LPAR is the one which will be missing since I guess you have not gone to the extensive trouble of redesigning your PATH statements everywhere. It may be that other VTAMs in recently added LPARs are also missing since your predecessor has relied on APPN to achieve connectivity, possibly relying on the concatenation of a subarea route to an APPN route. He may have got away with this on a wing and a prayer in that all the sessions which were expected to be available happened to work. That's probably enough for now. Let me know how you get on with these tasks. Once we have a clear picture of where the subarea routes are and where the APPN routes are, we can try to analyse why you are having session setup failures. When tracking session setup problems you need to check what each VTAM visited by the session setup attempt says. This is done most crudely by setting all start options containing SIRFMSG to ALLSSCP (or ALLNNS for LSIRFMSG). These are ASIRFMSG, DSIRFMSG, ESIRFMSG, LSIRFMSG, RSIRFMSG and SIRFMSG itself. You can set these all using MODIFY VTAMOPTS or restart VTAM with the values specified. Your problem is not to do with TGNs because it is almost certainly one of these problems that wouldn't happen if what we used to call
Re: VTAM question: Where does TGN=21 come from?
http://www-01.ibm.com/support/docview.wss?uid=swg21220155 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Martin Kline Sent: Wednesday, September 03, 2008 10:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: VTAM question: Where does TGN=21 come from? I've been all over the manuals, and I don't find this anywhere. It appears that certain VTAM links, CTCs and others, between LPARs within and without of the same sysplex, get assigned a default TGN of 21. Why? Shouldn't this be documented? More importantly, how does this affect PATH definitions, which contain VRs, and ER/TGN combinations, plus the COS tables that point to VRs, and the logmodes that point to COS tables? Please excuse my ignorance on this. I haven't dealt with VTAM for over 20 years. Now, I've specified all the (apparently) valid TGNs we had defined (not including TGN 21), and I find some logmodes that can no longer be used between networks, while other logmodes still work. The logmodes are available on all systems, but it appears that there are no routes available for the logmode-selected COS entries. Maybe I'm making this more difficult than necessary. The logmode entries worked previously, and TGN 21 was never included in the path definitions. Is there some default that allows any and all TGNs to be used by a given COS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VTAM question: Where does TGN=21 come from?
I've been all over the manuals, and I don't find this anywhere. It appears that certain VTAM links, CTCs and others, between LPARs within and without of the same sysplex, get assigned a default TGN of 21. Why? Shouldn't this be documented? More importantly, how does this affect PATH definitions, which contain VRs, and ER/TGN combinations, plus the COS tables that point to VRs, and the logmodes that point to COS tables? Please excuse my ignorance on this. I haven't dealt with VTAM for over 20 years. Now, I've specified all the (apparently) valid TGNs we had defined (not including TGN 21), and I find some logmodes that can no longer be used between networks, while other logmodes still work. The logmodes are available on all systems, but it appears that there are no routes available for the logmode-selected COS entries. Maybe I'm making this more difficult than necessary. The logmode entries worked previously, and TGN 21 was never included in the path definitions. Is there some default that allows any and all TGNs to be used by a given COS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
Martin I've been all over the manuals, and I don't find this anywhere. The APPN Tutorial redbook, now called Inside APPN and HPR - The Essential Guide to New SNA, the first hit when selecting APPN as the search word on the redbooks page, is the manual you appear to have missed. http://www.redbooks.ibm.com/abstracts/sg243669.html It appears that certain VTAM links, CTCs and others, between LPARs within and without of the same sysplex, get assigned a default TGN of 21. 21 is the TG number proposed for assignment to an APPN adjacent link when it (a PU statement) is defined without a specifying a TG number (using the TGN operand) (necessarily with a value between 1 and 20) and no link connection has yet been established between the two involved nodes. If neither side has specified a TG number, 21 will be used. Note that a second link under otherwise the same circumstances will use TG number 22 and so on. Why? I direct you to section 4.2.3 Transmission Groups in the referenced redbook, specifically Table 2 and the associated explanation. Shouldn't this be documented? It is - and where it should be as indicated. More importantly, how does this affect PATH definitions, which contain VRs, and ER/TGN combinations, plus the COS tables that point to VRs, and the logmodes that point to COS tables? It does not affect those definitions one jot - except as a harbinger of getting rid of them altogether! This an APPN thing and nothing to do with subarea things such as - shudder - PATH tables. ... plus the COS tables that point to VRs, and the logmodes that point to COS tables? Also not at all for the same reason. However, logmodes and COS are involved but indirectly and not in any you'd better make sure it all matches or nothing will work way. APPN routes get selected based on a loose form of matching between the characteristics of the transmission group as best defined by use of the TGP operand of the PU statement defining the adjacent link station. The mode name names a mode table entry (logmode) which may also contain an APPNCOS operand naming an APPN-flavour COS table (automatically activated when your NODETYPE start option specifies NN or EN) which selects a route based on finding a best fit with all the transmission groups making up potential routes - massively more dynamic than rigid, not forgetting to shudder - PATH tables designed as they were for storage-constrained 3705s back in the late '70s. Please excuse my ignorance on this. I haven't dealt with VTAM for over 20 years. How come you are using APPN without having had APPN education? Let me guess that it's in preparation for Enterprise Extender which thoroughly inadequate guidance as to how to go about it. Now, I've specified all the (apparently) valid TGNs we had defined (not including TGN 21), and I find some logmodes that can no longer be used between networks, while other logmodes still work. The logmodes are available on all systems, but it appears that there are no routes available for the logmode-selected COS entries. I'm now shuddering to try to imagine what you have been trying to do!!! I guess the fundamental trap your lack of education has allowed you to tumble into is that a subarea TG and an APPN TG are animals belonging almost to different phyla. Maybe I'm making this more difficult than necessary. Education would help - but, given I based my APPN class on that redbook, you may as well simply read - and absorb - what the redbook says. Then you can read and absorb a couple more redbooks to which I now direct you: Subarea to APPN Migration: VTAM and APPN Implementation http://www.redbooks.ibm.com/abstracts/sg244656.html and Subarea to APPN Migration: HPR and DLUR Implementation http://www.redbooks.ibm.com/abstracts/sg245204.html Note that, if you are preparing for Enterprise Extender, you will also need to get your head around the HPR APPN extension. Then you can reinforce this by reading through the Network Implementation Guide for wherever APPN is mentioned. The logmode entries worked previously, and TGN 21 was never included in the path definitions. Is there some default that allows any and all TGNs to be used by a given COS? Education, education, education a favourite expression of Tony Blair - of whom we have not heard much lately. In order to anticipate your next question - or the next question to come to any idly reading this without having your urgent need to read through the redbooks - TG numbers 1 to 20 are reserved so that they can be defined with the TGN operand of PU statements defining APPN adjacent link stations. This permits an APPN transmission group to be defined without any actual contact having been made. This then allows for such a link to be established dynamically when a session is requested where the APPN COS mechanism sets up a route which includes that transmission group. And if the defined numbers are different? Well, that's where
Re: VTAM question: Where does TGN=21 come from?
That document seems to be inapplicable. The doc refers to defining TGNs for NCPs. We have no NCPs. Again, where does TGN=21 come from for intersystem links? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question: Where does TGN=21 come from?
Martin It is always most helpful when, if you are responding to a post, you quote the post to which you are responding in some way. It is always possible that you have more than one response - even when the topic is as unpopular as VTAM! In this case I detect you may have an excuse because there was something terribly wrong with the list processing at the time I submitted my response and I did not see any evidence of my contribution - even after having finished my dinner! I even worried that, in my urgency to get at my meal, I had made a mess of posting. Because of this delay, I'm assuming you are responding to David Cebell. Much as I hate to disparage those trying to offer answers to queries, I also found David's contribution rather puzzling. There's not a great deal of common ground between your query and his answer. However this rather odd Technote - clearly to cover other cases of missed education - gives me a chance to point out another trap you might otherwise fall into. Both subarea SNA and APPN SNA have the concept of a multiple link (multilink) transmission group (MLTG) - not to mention multipath channel (MPC) so I won't! Subarea MLTG, a feature purely of NCP support for subarea SNA, much beloved of subarea SNA aficionados is not at all the same as the APPN MLTG you can find defined in section 8.5.4 Multilink Transmission Groups of the APPN Tutorial redbook. Although this capability has an architecture, I am unaware of any implementations. Subarea MLTG was such a powerful facility that I was able to devise a backup technique when reasonably high speed public switched data networks, such as 64Kbps ISDN, became widely available that I could describe it - with not a small amount of tongue in my cheek - as Backup before Failure. Sadly so many babies have been thrown out with the NCP bathwater. Just in case you are referring to my answer, I can only say that, indeed, NCP is mentioned, generally in passing about exceptional matters in the APPN Tutorial redbook. It is covered in a bit more detail only when getting to Appendix B. Chris Mason On Wed, 3 Sep 2008 13:49:01 -0500, Martin Kline [EMAIL PROTECTED] wrote: That document seems to be inapplicable. The doc refers to defining TGNs for NCPs. We have no NCPs. Again, where does TGN=21 come from for intersystem links? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VTAM question on XCF.
This relates to my previous question about Parallel Sysplex. I'm trying to read the books quickly to get a Power Point presentation ready. IIRC, the VTAMs can talk to each other via XCF instead of/in addition to CTCs if they are all in the same sysplex. Correct? Second question: a Basic Sysplex connects with CTCs. Do I need CTCs in a Parallel Sysplex or does the CF entirely replace the CTCs? Many thanks from a very Sysplex ignorant person. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question on XCF.
1. Yes, VTAM will talk across the 'sysplex' CF structures in a parallel sysplex. We discovered this early on more or less by accident. You also have the option of 'VTAM generics' via a separate CF structure. 2. CTCs are not required in a parallel sysplex, but every discussion I've ever seen on the topic strongly recommends them as a backup mechanism. If CF communication fails or gets severely interrupted, the CTCs provide an alternate method of communication. You may be hosed anyway, but at least you'll go down with a few salient messages to ponder. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] McKown, John [EMAIL PROTECTED] THMARKETS.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU VTAM question on XCF. 12/03/2007 10:38 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU This relates to my previous question about Parallel Sysplex. I'm trying to read the books quickly to get a Power Point presentation ready. IIRC, the VTAMs can talk to each other via XCF instead of/in addition to CTCs if they are all in the same sysplex. Correct? Second question: a Basic Sysplex connects with CTCs. Do I need CTCs in a Parallel Sysplex or does the CF entirely replace the CTCs? Many thanks from a very Sysplex ignorant person. -- John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question on XCF.
the VTAMs can talk to each other via XCF instead of/in addition to CTCs if they are all in the same sysplex. Correct? IIRC, VTAM only uses CTC's and not XCF. Second question: a Basic Sysplex connects with CTCs. Do I need CTCs in a Parallel Sysplex or does the CF entirely replace the CTCs? You still need the CTCs. (Of course, I implemented Parallel SYSPLEX in 1994, and haven't really gone back to revisit, so I could be out of date.) - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question on XCF.
On Mon, 3 Dec 2007 19:07:07 +, Ted MacNEIL [EMAIL PROTECTED] wrote: ... IIRC, VTAM only uses CTC's and not XCF. ... VTAM dynamic XCF support went in about 2.7 or 2.8. (I could be thinking TCP/IP support. VTAM's support may have been earlier.) If you already had APPN support you automatically got APPN connectivity (whether you wanted it or not) as soon as you had 2 VTAMs at that level in the Sysplex. Second question: a Basic Sysplex connects with CTCs. Do I need CTCs in a Parallel Sysplex or does the CF entirely replace the CTCs? You still need the CTCs. ... If this is strictly a VTAM question, the answer is No (for APPN). In a Sysplex (even basic, not necessarily parallel) you automatically have dynamic XCF connectivity as long as you have XCF signalling amongst the MVS images. As Skip said earlier in this thread, you probably ought to have the CTCs for backup. And last I saw, IBM was still saying that VTAM CTCs outperform XCF. (And last I knew people understanding XCF signalling say that can't be true unless the VTAM overhead is terrible.) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Hello Debbie, Are your ISPF sessions that get the '***' prompt for screen mode changes being driven by ISPF dialogs? Are those dialogs REXX or CLIST? Are the dialogs being started by TSO EXEC processing or by ISPF start CMD processing? I seem to remember some changes in the way ISPF managed the screen depending on the call/start process. Regards Bruce Hewson apologies for the late replystill catching up on the digests. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Debbie The reason the supplied ISTINCLM may have been discarded and your own introduced *may* be due to an oversight by the VTAM developers when type 2.1 support was introduced - way back in the late '80s. It took VTAM development a while to introduce the DYNMODTB start option, the mid '90s I think, and so the only way to provide mode table entries for dynamically created type 2.1 node CDRSCs representing logical units performing the *secondary* role in subarea session stages was to rely on the supplied mode table ISTINCLM. Here's a snippet from my notes on Type 2.1 node support: quote A CDRSC for the secondary session partner *cannot* initially be created dynamically unless the Session Management exit is active with the Adjacent Link Station Selection function. In this case all the operands applying to secondary operation are relevant - and missing! The Session Management exit function can select one adjacent link station but all other operands must take the default values, which, most importantly, means that the VTAM default mode table, ISTINCLM, must be used. This is actually a severe deficiency of the Session Management exit Adjacent Link Station Selection function. /quote With the introduction of APPN, the CDRSC for the secondary session partner is created dynamically using APPN mechanisms and not the Session Management exit Adjacent Link Station Selection function. I'm sorry that was a bit technical; the merger of type 2.1 node SNA architecture (which includes APPN) and subarea SNA architecture has its messy aspects. - I expect the effect is consistent with its cause, it's just you haven't yet identified what the cause is and so it's apparently inconsistent. You can probably experiment on one PC's 3270 emulator product, say PCOMM, by modifying the rows and columns specifications. Thus assumes you are using a mode table entry which causes TSO to go and read the customised presentation space dimensions. A test with 24 by 80 and another with 43 by 80 may suffice. On the other hand, in these cases TSO may always use Erase Write for the default and Erase Write Alternate for the alternate and always use the three asterisks when the change occurs. If you can arrange to use a mode table entry which has X'02', rather than X'03', in the penultimate byte of the PSERVIC operand, that will force the use only of Erase Write and so there will be no need for a change and no need for the three asterisks. You should be able to observe the use of Erase Write , Erase Write Alternate and the three asterisks using NetView Session Monitor (NLDM) primary trace. You will also be able to check the presentation services field of the BIND - but you'll need to use the HEX option I think. Chris Mason - Original Message - From: Debbie Mitchell [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, May 21, 2007 7:19 PM Subject: Re: VTAM question (***) On Mon, 21 May 2007 17:11:41 +0200, Chris Mason [EMAIL PROTECTED] wrote: I can't say I'd ever performed this sort of research but isn't the need to regenerate - including reassembly - customized tables one of the sorts of issues covered by the documentation a systems programmer goes through when planning a new release? As it turns out, the version of ISTINCLM in use here is not IBM's default. It was customized long before my tenure here and not documented. I will need to do some checking with other people here to see what they remember about the reason it was customized as well as what changes were made. Since no one is really complaining (at least not very loudly) about it, it won't be a priority. And, since posting my original question, I have noticed that the behavior is not consistent -- which leads me to believe that it is, indeed, related to changing screen sizes. Thank you all for your help. Debbie Mitchell Utica National Insurance Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Ed It may depend on just exactly what damage Debbie's predecessor has done to ISTINCLM. If ISTINCLM has only been added to, of course all the original IBM-supplied entries will be available for use including, for example, D4C32XX3 - note a 3 at the end rather than a C. In fact, it may be safer to use the D4A32XX3 version of the SNA (non non-SNA) mode table entry with the penultimate byte specifying 03 since the emulator may be compatible with the old 3274 A (channel) models rather than the C (line) models. The A mode table entry has a maximum outbound RU size of 1536 while the C mode table entry has a maximum outbound RU size of 3840. Incidentally, it's LOGMODE with an E, not LOGMOD. Chris Mason - Original Message - From: Ed Finnell [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, May 21, 2007 7:38 PM Subject: Re: VTAM question (***) In a message dated 5/21/2007 12:20:03 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: be a priority. And, since posting my original question, I have noticed that the behavior is not consistent -- which leads me to believe that it is, indeed, related to changing screen sizes. If you want to play around with the LOGMODES can do LOGON APPLID(majnode) LOGMOD(D4C32XXC) or one that hasn't been modified. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Kevin The effect Debbie described is digital, you are implying that it is analogue. Debbie says that her user used *not* to have to deal with a panel with three asterisks in V1R4, corresponding to 0, but does in V1R7, corresponding to 1. More pronounced implies some sort of gradual change. Perhaps you have better describe the effect you are experiencing in more detail. Does the effect you are seeing apply only when using the ISPF Productivity Toll (IPT)? APAR OA20772 applies only to users of IPT? *If* there's something about Debbie's original problem I have not understood *and* you are both describing the same phenomenon, whatever change caused it would appear to have happened between V1R6 ands V1R7. Chris Mason - Original Message - From: Neubert, Kevin (DIS) [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, May 21, 2007 8:23 PM Subject: Re: VTAM question (***) Going from z/OS 1.6 to 1.8 I have noticed similar behavior. Is it more pronounced on terminals such as Mod 3 (32X80) versus Mod 5 (27X132)? If you use IPT I found some relief with OA20772. Otherwise I opened TSO and ISPF ETRs to no avail and still have a VTAM ETR outstanding. Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Debbie Mitchell Sent: Monday, May 21, 2007 10:20 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VTAM question (***) On Mon, 21 May 2007 17:11:41 +0200, Chris Mason [EMAIL PROTECTED] wrote: I can't say I'd ever performed this sort of research but isn't the need to regenerate - including reassembly - customized tables one of the sorts of issues covered by the documentation a systems programmer goes through when planning a new release? As it turns out, the version of ISTINCLM in use here is not IBM's default. It was customized long before my tenure here and not documented. I will need to do some checking with other people here to see what they remember about the reason it was customized as well as what changes were made. Since no one is really complaining (at least not very loudly) about it, it won't be a priority. And, since posting my original question, I have noticed that the behavior is not consistent -- which leads me to believe that it is, indeed, related to changing screen sizes. Thank you all for your help. Debbie Mitchell Utica National Insurance Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Steve You're cheating; it should be MOD-4-1/2 since you have taken only half the specification of the model 4 and half the specification of the model 5. g Why am I objecting? Well, long ago, I claimed M9 - added to M2, M3, M4 and M5 - as the mode table entry name for an entry to correspond with the 3290 full screen (62 x 160). What you have done in order to avoid the appearance of the three asterisks may correspond to the test I suggested to Debbie where I proposed avoiding any possibility of alternating between the use of Erase Write and Erase Write Alternate. Chris Mason - Original Message - From: Thompson, Steve [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, May 21, 2007 8:38 PM Subject: Re: VTAM question (***) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Debbie Mitchell Sent: Monday, May 21, 2007 12:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VTAM question (***) On Mon, 21 May 2007 17:11:41 +0200, Chris Mason [EMAIL PROTECTED] wrote: I can't say I'd ever performed this sort of research but isn't the need to regenerate - including reassembly - customized tables one of the sorts of issues covered by the documentation a systems programmer goes through when planning a new release? As it turns out, the version of ISTINCLM in use here is not IBM's default. SNIP You might check (if possible) to see if the userss PROFILEs were changed such that they no longer specify MAX for the terminal size (formerly done with =0 and the setting of the terminal types, models, etc.). I have changed my emulation to a customized emulation (MOD-9, uh, that's 132x43, or MOD4+5, your similarly described MOD9 might be 72lines by 160 chars), that is, non-standard 3270 sizes. I have also noticed the *** when MOD2 is forced (always done just before and right after ISPF termination). But I got rid of it happening here and there under ISPF by forcing MAX for all sessions that I have (multiple IDs and multiple LPARS). Regards, Steve Thompson -- STD. Disclaimer: Poster's posting may not be in line with poster's employer. YMMV. The Three Stooges did not approve of this posting. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
I don't mean to detract from Debbie's problem, but in case there is merit... Q: Does the effect you are seeing apply only when using the ISPF Productivity Toll (IPT)? A: No. No prior to OA20772 the problem could be duplicated with and without IPT. Q: APAR OA20772 applies only to users of IPT? A: Yes. IPT has its own enhanced TSO shell with an output line number option. OA20772 provided relief for the problem in the sense that it honors the specified output line number. Q: Perhaps you have better describe the effect you are experiencing in more detail. A: An example, with z/OS 1.8 as opposed to z/OS 1.6 TSO command output begins with the available space on the screen where the command was issued instead of a fresh screen. Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: Wednesday, May 23, 2007 1:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VTAM question (***) Kevin The effect Debbie described is digital, you are implying that it is analogue. Debbie says that her user used *not* to have to deal with a panel with three asterisks in V1R4, corresponding to 0, but does in V1R7, corresponding to 1. More pronounced implies some sort of gradual change. Perhaps you have better describe the effect you are experiencing in more detail. Does the effect you are seeing apply only when using the ISPF Productivity Toll (IPT)? APAR OA20772 applies only to users of IPT? *If* there's something about Debbie's original problem I have not understood *and* you are both describing the same phenomenon, whatever change caused it would appear to have happened between V1R6 ands V1R7. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
I just thought if he needed more detailed help on how to you ISPVCALL or ISPF TEST, it might clutter the list a bit too much. I am more than happy to keep the list updated on discussions. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: Sunday, May 20, 2007 11:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VTAM question (***) Lizette Please remember that archives are kept for the list and that the list works best when all discussion is in the open. Chris Mason - Original Message - From: Lizette Koehler [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Sunday, May 20, 2007 3:40 PM Subject: Re: VTAM question (***) ... If you need more information, contact me offline. Lizette Koehler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
In a message dated 5/21/2007 7:02:03 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: just thought if he needed more detailed help on how to you ISPVCALL or ISPF TEST, it might clutter the list a bit too much. I am more than happy to keep the list updated on discussions. That's the spirit. Guess what I'd do is reassemble the LOGMODEs and USSTABs or copy them to new names. Check with the emulator vendor if there are fixes for z/OS level, then if were still occurring I'd go with the traces and breakpoints. ** See what's free at http://www.aol.com. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Ed I'd be amazed - quite utterly astounded - at this stage in its existence if VTAM was causing problems with changes in mode table (LOGMODE) internal format. I very, very much doubt that could be in any way anything to do with the reported effect. In any case, Debbie may be using the IBM-supplied mode table ISTINCLM - even if the MODETAB operand is present but the selected mode table entry comes from ISTINCLM. Since we are talking about an effect happening deep within the SNA session and the Unformatted System Services table (USSTAB) is customization applied to the session between the secondary LU and the SSCP (VTAM), I just cannot see any sense whatsoever in paying any attention to that table even if there was a possibility of a change in internal format - which I also thoroughly doubt. I'm going to have to enrol you into the grape-shot school of problem resolution. g I can't say I'd ever performed this sort of research but isn't the need to regenerate - including reassembly - customized tables one of the sorts of issues covered by the documentation a systems programmer goes through when planning a new release? In fact the traces it might be useful to collect - if it's still possible - are the NetView Session Monitor (NLDM) complete PIU (CPIU) primary traces over the period in the session which demonstrates the change - both at the V1R4 and V1R7 levels. That would be a clear starting point from which to consider further tracing within the TSO component - perhaps such as you are suggesting. Actually I'm having a bit of a problem working out about what spirit you may be talking. Chris Mason - Original Message - From: Ed Finnell [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, May 21, 2007 4:24 PM Subject: Re: VTAM question (***) In a message dated 5/21/2007 7:02:03 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: just thought if he needed more detailed help on how to you ISPVCALL or ISPF TEST, it might clutter the list a bit too much. I am more than happy to keep the list updated on discussions. That's the spirit. Guess what I'd do is reassemble the LOGMODEs and USSTABs or copy them to new names. Check with the emulator vendor if there are fixes for z/OS level, then if were still occurring I'd go with the traces and breakpoints. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
On Mon, 21 May 2007 17:11:41 +0200, Chris Mason [EMAIL PROTECTED] wrote: I can't say I'd ever performed this sort of research but isn't the need to regenerate - including reassembly - customized tables one of the sorts of issues covered by the documentation a systems programmer goes through when planning a new release? As it turns out, the version of ISTINCLM in use here is not IBM's default. It was customized long before my tenure here and not documented. I will need to do some checking with other people here to see what they remember about the reason it was customized as well as what changes were made. Since no one is really complaining (at least not very loudly) about it, it won't be a priority. And, since posting my original question, I have noticed that the behavior is not consistent -- which leads me to believe that it is, indeed, related to changing screen sizes. Thank you all for your help. Debbie Mitchell Utica National Insurance Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
In a message dated 5/21/2007 12:20:03 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: be a priority. And, since posting my original question, I have noticed that the behavior is not consistent -- which leads me to believe that it is, indeed, related to changing screen sizes. If you want to play around with the LOGMODES can do LOGON APPLID(majnode) LOGMOD(D4C32XXC) or one that hasn't been modified. ** See what's free at http://www.aol.com. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Going from z/OS 1.6 to 1.8 I have noticed similar behavior. Is it more pronounced on terminals such as Mod 3 (32X80) versus Mod 5 (27X132)? If you use IPT I found some relief with OA20772. Otherwise I opened TSO and ISPF ETRs to no avail and still have a VTAM ETR outstanding. Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Debbie Mitchell Sent: Monday, May 21, 2007 10:20 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VTAM question (***) On Mon, 21 May 2007 17:11:41 +0200, Chris Mason [EMAIL PROTECTED] wrote: I can't say I'd ever performed this sort of research but isn't the need to regenerate - including reassembly - customized tables one of the sorts of issues covered by the documentation a systems programmer goes through when planning a new release? As it turns out, the version of ISTINCLM in use here is not IBM's default. It was customized long before my tenure here and not documented. I will need to do some checking with other people here to see what they remember about the reason it was customized as well as what changes were made. Since no one is really complaining (at least not very loudly) about it, it won't be a priority. And, since posting my original question, I have noticed that the behavior is not consistent -- which leads me to believe that it is, indeed, related to changing screen sizes. Thank you all for your help. Debbie Mitchell Utica National Insurance Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
In [EMAIL PROTECTED], on 05/19/2007 at 05:25 PM, Debbie Mitchell [EMAIL PROTECTED] said: Subject: VTAM question (***) Why do you believe that it is a VTAM issue? We have just upgraded from z/OS 1.4 to z/OS 1.7. There is a slight behaviour difference in ISPF, however, when navigating ISPF panels. I'm 99% sure the change I need to make is in VTAM somewhere, Why? When going from certain panels to other (homegrown) panels, the user is presented with *** at the bottom of the screen and must hit enter. Prior to the implementation of 1.7, however, the *** was not presented and the new panel was displayed without having to hit enter. That sounds like an application problem, having to do with the relation between line mode and full screen I/O. I'd suggest either doing the ISPF traces that others have suggested or a TPUT trace and seeing what changed in the trace between 1.4 and 1.7. Can someone point me to where I need to look? Terminal I/O in your applications, especially ISPF. ISPF profile changes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
There are a couple of things you can do. 1) Issue the TSO Command ISPVCALL then execute the panel or function that gives the ***. After you get the *** then issue the command again. It will produce a trace of the ISPF Function. It is very detailed but may show you a REXX or CLIST name you recognize. 2) Go into ISPF TEST. Make sure your LOG data set in ISPF is setup to collect information first. a) Go to OPTION 7 (BREAKPOINTS) and use DISPLAY as the function and YES for all traces b) Go to Option 8 (TRACES) and under both sections put a YES where there is a NO. c) Go to Option 1 and execute either your primary panel or the ISPF Function that has the error. Reply G to all requests until you get the ***. Then use C (Cancel) d) Go to the ISPF log data set (Option 5) and start looking to see what was running at the time. The ISPVCALL traces all ISPF Functions so be prepared for a lot of information in it. The ISPF TRACE only traces the ISPF functions and will be less detail. If you need more information, contact me offline. Lizette Koehler [EMAIL PROTECTED] will work fine. Have not experienced that myself. Sounds like you have a clist or rexx exec in between, doing a write or say with no data. So TSO/E gives you the asterisks before continuing. Can't see how VTAM is going to change that. On Sat, 19 May 2007 17:25:52 -0500, Debbie Mitchell [EMAIL PROTECTED] wrote: We have just upgraded from z/OS 1.4 to z/OS 1.7. There is a slight behaviour difference in ISPF, however, when navigating ISPF panels. I'm 99% sure the change I need to make is in VTAM somewhere, but I can't for the life of me remember where. When going from certain panels to other (homegrown) panels, the user is presented with *** at the bottom of the screen and must hit enter. Prior to the implementation of 1.7, however, the *** was not presented and the new panel was displayed without having to hit enter. Can someone point me to where I need to look? Many thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Or type: panelid on The upper left corner shows the panel member name. split your screen and type: tso isrddn then replace the panelname in the line below with the member name : m panelname ispplib ISPF will search for the member and position the screen on the dataset with the panel. Browse it and find what the panel selection invokes. end browse and replace cmdname with the command from the panel in the line below: m cmdname sysproc to search for a clist m cmdname sysexec to search for a rexx program m cmdname to just give up and search everything. Lizette Koehler wrote: There are a couple of things you can do. 1) Issue the TSO Command ISPVCALL then execute the panel or function that gives the ***. After you get the *** then issue the command again. It will produce a trace of the ISPF Function. It is very detailed but may show you a REXX or CLIST name you recognize. 2) Go into ISPF TEST. Make sure your LOG data set in ISPF is setup to collect information first. snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Debbie Well, at least you got my attention by putting VTAM in the title. I tend to doubt - like Kenneth - that VTAM has got anything to do with your problem - except that TSO and VTAM share development effort to some extent. This is a TSO issue - not really to be described as a problem judging by your description. It may be that you recall that TSO provides the three asterisks warning when switching from the default - some say primary - to the alternate presentation space dimensions. Maybe your favourite alternate dimensions are 43 rows and 80 columns and your homegrown panels use traditional 24 rows and 80 columns. This requires a resetting of the logical display hardware and - I believe, since I don't have the facilities at hand to demonstrate it to myself - TSO warns the user that such a change will take place by means of the three asterisks. Where VTAM comes into this somewhat indirectly is that the specification of the default and alternate presentation space dimensions is contained in the presentation services field of the BIND request unit which sets up the SNA session between TSO as the primary logical unit (LU) and whatever, typically a 3270 emulator these days - or maybe an LU managed by a TN3270 server, represents the secondary LU. This field is defined by the PSERVIC operand of the MODEENT macro which created the mode table entry specified for the session. This mode table entry is contained within the mode table specified on the VTAM definition statement which represents the secondary LU using the MODETAB operand . Alternatively, if there is no MODETAB operand specified, the VTAM-supplied table ISTINCLM is used. These VTAM resources are where VTAM comes into the picture. In fact it may not be quite so straightforward as this. It may be that the specification in the selected mode table entry PSERVIC field corresponds to the code which indicates that the application, in this case TSO, should determine the default and alternate presentation space dimensions from the customization of the implementation of the 3270 secondary LU itself rather than the customization having to be coordinated with the numbers in the selected mode table entry PSERVIC field. This is almost certainly possible with the implementation of the 3270 secondary LU used today but not every VTAM systems programmer has introduced the revision to definitions required to exploit this enhancement - of very many years ago. Having said all this it is something of a puzzle that a change of behaviour within TSO has appeared between z/OS Communications Server SNA V1R4 and V1R7. I'm guessing that any such change would be in response to an enhancement relating to presentation space dimensions and may have appeared in an APAR between V1R4 and V1R7. Thus a hunt in the description of APARs involving TSO for V1R4, V1R5, V1R6 and, possibly, if maintenance has been incorporated into the V1R7 you are using, V1R7 might throw up the cause of the change to behaviour I assume some finickety TSO user has brought to your attention. Incidentally, as I indicated above, the requirement to press Enter following the appearance of the three asterisks when the presentation space dimensions change is probably the *correct* behaviour and it may be that what happened before was the *incorrect* behaviour. If you need more help understanding what I have been talking about - or just more help, please post again and provide more details, giving, for example, the presentation space dimensions in use before and after the appearance of the three asterisks. Chris Mason - Original Message - From: Debbie Mitchell [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Sunday, May 20, 2007 12:25 AM Subject: VTAM question (***) We have just upgraded from z/OS 1.4 to z/OS 1.7. There is a slight behaviour difference in ISPF, however, when navigating ISPF panels. I'm 99% sure the change I need to make is in VTAM somewhere, but I can't for the life of me remember where. When going from certain panels to other (homegrown) panels, the user is presented with *** at the bottom of the screen and must hit enter. Prior to the implementation of 1.7, however, the *** was not presented and the new panel was displayed without having to hit enter. Can someone point me to where I need to look? Many thanks in advance. Debbie Mitchell Utica National Insurance Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Lizette Please remember that archives are kept for the list and that the list works best when all discussion is in the open. Chris Mason - Original Message - From: Lizette Koehler [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Sunday, May 20, 2007 3:40 PM Subject: Re: VTAM question (***) ... If you need more information, contact me offline. Lizette Koehler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VTAM question (***)
We have just upgraded from z/OS 1.4 to z/OS 1.7. There is a slight behaviour difference in ISPF, however, when navigating ISPF panels. I'm 99% sure the change I need to make is in VTAM somewhere, but I can't for the life of me remember where. When going from certain panels to other (homegrown) panels, the user is presented with *** at the bottom of the screen and must hit enter. Prior to the implementation of 1.7, however, the *** was not presented and the new panel was displayed without having to hit enter. Can someone point me to where I need to look? Many thanks in advance. Debbie Mitchell Utica National Insurance Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM question (***)
Have not experienced that myself. Sounds like you have a clist or rexx exec in between, doing a write or say with no data. So TSO/E gives you the asterisks before continuing. Can't see how VTAM is going to change that. On Sat, 19 May 2007 17:25:52 -0500, Debbie Mitchell [EMAIL PROTECTED] wrote: We have just upgraded from z/OS 1.4 to z/OS 1.7. There is a slight behaviour difference in ISPF, however, when navigating ISPF panels. I'm 99% sure the change I need to make is in VTAM somewhere, but I can't for the life of me remember where. When going from certain panels to other (homegrown) panels, the user is presented with *** at the bottom of the screen and must hit enter. Prior to the implementation of 1.7, however, the *** was not presented and the new panel was displayed without having to hit enter. Can someone point me to where I need to look? Many thanks in advance. Debbie Mitchell Utica National Insurance Group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vtam question
I've never heard of Inter Enterprise License. We use SNI (SNA Network Interconnection), which includes the gateway functions of VTAM and NCP. The Cross-Domain feature will not get you all that you want. It is used mostly for linking VTAM together which reside on other MVS systems. The SNI is used for linking SNA networks together, then Cross-Domain comes into play to find the applications. On Fri, 9 Jun 2006 19:30:29 -0300, Bodra - Pessoal [EMAIL PROTECTED] wrote: What is the difference between VTAM Cross-Domain and Interentreprise license? It´s possible to get communication between vtam at my host to another vtam in a different host with different network id´s using Cross-Domain feature? Or Cross-Domain is used just for Single gateway, not back-to-back connections? Thanks Carlos -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vtam question
like to use this configuration but do not want the uncertainties of having untested APPN functions present in the rest of the networks associated with the two VTAMs. This can easily be done by preventing any CP to CP sessions or by allowing CP to CP sessions to be established only over selected links. If both VTAMs need to be APPN Network Nodes, then you will need to use the APPN border node function. VTAM implements the Extended Border Node (EBN) function and you can implement this with just one side being defined as an EBN or both sides defined as an EBN with no limitations on your session setup. Assuming your VTAMs have had all the adjustments necessary for supporting APPN, merely defining one or both of the adjacent VTAMs as EBNs will probably be sufficient. That is, the defaults for EBN operation will allow any session setups you need. There may be mode name and COS name problems but, if so, please post again - assuming this is your solution. Having got all that explained I see your final sentence is discussing gateways and back-to-back by which I assume you are referring to SNI - and again there is some confusion over the presence or otherwise of a question. Anyhow, if you want to have a change of NetID and you wish to retain a purely subarea configuration, you need SNI. I'm still assuming that when you say cross-domain you mean subarea cross-domain and - if I understand what you are asking - SNI will be required whatever sort of gateway configuration you may wish to construct, the single NCP gateway, with one or two gateway SSCPs (VTAMs), or the minimally two gateway NCPs and two gateway SSCPs back-to-back configuration. Chris Mason - Original Message - From: Bodra - Pessoal [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Saturday, 10 June, 2006 12:30 AM Subject: Vtam question What is the difference between VTAM Cross-Domain and Interentreprise license? It´s possible to get communication between vtam at my host to another vtam in a different host with different network id´s using Cross-Domain feature? Or Cross-Domain is used just for Single gateway, not back-to-back connections? Thanks Carlos -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vtam question
Bodra - Pessoal wrote: What is the difference between VTAM Cross-Domain and Interentreprise license? http://www.ibm.com/software/network/vtam/features/ gives a brief overview. A detailed description of what's included in each of the three different VTAM offerings (Client/Server, MultiDomain, and InterEnterprise) can be found in Announcement Letter 295-001. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vtam question
Edward, Thanks for the heads-up. I'm afraid I hadn't considered that the question might concern VM and/or VSE and consequently direct my research in that direction. I have certainly learned something from this and I'll have to look out for it in any future fuzzy posts. Perhaps there won't be too many since this is all well over 10 years old now. More detail is given in the VTAM V4R2 for VM/ESA Release Guide, C31-8089-00, and a whole manual, VTAM V4R2 for VM/ESA and VSE/ESA Overview, GC31-8114-00, is dedicated to explaining the various packaging options. With this fresh information I can align the options I outlined in my previous post to these three packaging options, Client/Server, MultiDomain and InterEnterprise, in ascending level of function and, certainly, price. I expect Carlos meant MultiDomain when he said Cross-Domain and packaging option when he said feature - but, since this concerns marketing and it's possible the marketing documents have been translated, there may be a lost in translation effect here. Carlos, With the Client/Server packaging option, you can connect your two VTAM systems with the different NetIDs using LEN, APPN End Node to APPN Network Node or APPN End Node to APPN End Node but using LEN protocols. (Note that the Release Guide text seems to suggest that only integrated communication adapters are supported. This is not true according to the Overview manual.) With the MultiDomain packaging option, you can do the same as you can with the Client/Server packaging option and, in addition, you can connect using an NCP since you can have a subarea link to an NCP from one of the VTAMs, activate the NCP over this subarea link and then have a type 2.1 link to the NCP from the other VTAM which can be using the Client/Server packaging option. (Note I didn't mention this configuration in my last post as one of the type 2.1 node appearances.) With the InterEnterprise packaging option, you can connect your two VTAM systems with the different NetIDs using SNI, any gateway configuration, or with APPN EBN. Armed with this clarification from Edward I can now answer the original questions precisely - now expressed as questions with the correct terminology: What is the difference between the VTAM MultiDomain and InterEnterprise packaging options? See VTAM V4R2 for VM/ESA and VSE/ESA Overview, GC31-8114-00, http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=USFNC=SRXPBL=GC31-8114-00 Essentially, they imagine they are providing single NetID only support - but they are wrong; they forgot about the possibility to change NetID over a link with LEN and an APPN End Node to another APPN node. Here's a sentence from the Release Guide: MultiDomain gives you what you need for multinode networks with one network ID.[1] Is it possible to get communication between VTAM at my host to another VTAM in a different host with different network ID´s using the MultiDomain packaging option? Yes, using LEN or APPN (type 2.1 node appearances) as I described in my previous post and that's even possible with the Client/Server packaging option. Or is MultiDomain used just for a single SNI gateway configuration, not a back-to-back SNI gateway configuration? It is possible to use the MultiDomain packaging option - or even the Client/Server packaging option - for a single gateway SNI configuration but only on one side, the non-gateway SSCP side. In other words, one side of the single gateway SNI configuration, the gateway SSCP side, must be at the level of the InterEnterprise packaging option, if VM or VSE, or it must be z/OS Communications Server SNA. Both sides of a back-to-back SNI gateway configuration must be at the level of the InterEnterprise packaging option. I hope that's clear. Please post again if it is not. Chris Mason [1] Thanks, Carlos, it makes a technician's day when he can put one over on the smart marketeers. :-) Alternatively :-( if they haven't been tumbled before and they've been smiling all the way to the bank with their ill-gotten gains for the past 11 years. - Original Message - From: Edward Jaffe [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, 14 June, 2006 12:31 AM Subject: Re: Vtam question Bodra - Pessoal wrote: What is the difference between VTAM Cross-Domain and Interentreprise license? http://www.ibm.com/software/network/vtam/features/ gives a brief overview. A detailed description of what's included in each of the three different VTAM offerings (Client/Server, MultiDomain, and InterEnterprise) can be found in Announcement Letter 295-001. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email
Vtam question
What is the difference between VTAM Cross-Domain and Interentreprise license? It´s possible to get communication between vtam at my host to another vtam in a different host with different network id´s using Cross-Domain feature? Or Cross-Domain is used just for Single gateway, not back-to-back connections? Thanks Carlos -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
