Thomas and Desi,
Here's the commentary on your sample switched major nodes. I'll deal with
Thomas's first and add any extra comments on Desi's at the end.
VBUILD
TYPE=SWNET - fine
MAXGRP - obsolete since VTAM V4R4[1]
MAXNO - obsolete since VTAM V4R4[1]
PU
ADDR - fine and it's quite correct that it's not used[2]
CPNAME - fine
DISCNT=NO - fine, why should you think about changing it?[3]
ISTATUS=ACTIVE - fine
MAXOUT=1 - this is awful and the comment is nonsense[4]
MAXPATH - obsolete since VTAM V4R4[1]
PUTYPE=2 - fine but the comment is nonsense[5]
PATH
GRPNM - fine
DIALNO - should be converted to DLCADDR so that the parts are separated[6]
REDIAL=7 - [7]
USE=YES - fine
LU LOCADDR=0 - should be converted to a CDRSC[8]
LU LOCADDR=>0
DLOGMOD - fine
MODETAB - fine[9]
SSCPFM=USSSCS - fine
USSTAB - fine - but why only some of the LUs?
VPACING=0 - fine for 3270 since it is self-pacing but why not also PACING=0?
[1] Unfortunately in all this time, about 9 years, nobody has bothered to
tell the author of the VTAM/CS-SNA Resource Definition Reference manual.
Removal of the need for all these massively irritating "MAX" operands has
been well expressed in the relevant redbook, "VTAM V4R4 for MVS/ESA
Implementation Guide", SG24-2100-00, written by my old friend, ex-colleague
and fellow alumnus Jerzy Buczak. A flavour of his inimitable style can be
seen in the description of this change in 11.4.1, "Switched Major Nodes",
"The parameters MAXPATH, MAXNO, MAXGRP and MAXDLUR are no longer necessary
on the PU and VBUILD statements. VTAM is perfectly capable of counting the
numbers of statements you have coded." I could even add in my own bitter
style "and always has been!"
Incidentally, this redbook goes on to cover the use of the GROUP statement
in Switched major nodes. If you are revisiting a large number of these
AS/400 definitions, you may find a benefit in exploiting the possibility to
"group" your - improved - operands.
[2] A VTAM developer promised me long ago he was going to look into getting
rid of this requirement. Unfortunately nothing happened.
[3] These are token ring connections, maybe as much apparent (DLSw) as real.
In either case, if you think there is a benefit in disconnecting when there
is no traffic, SSCP-independent LUs, or no LU-LU sessions, SSCP-dependent
LUs, you can specify DISCNT=YES or DISCNT=(DELAY,,n). In the case of
SSCP-independent LUs, you may* need also to specify LIMRES=YES on the
switched PU statement. This causes all LU 6.2 session BINDs to be marked
with a bit that ensures that the "contention-winner" end of the session
terminates the session whenever there are no conversations running over it
after a delay provided by the LIMQSINT operand of the APPL statement, where
VTAM support of LU 6.2 is used, or its equivalent in a product such as CICS,
where VTAM support of LU 6.2 is not used, or its equivalent in the
communicating partner, in this case, the AS/400.
* I have seen a post in one of the IBM newsgroups where an eminent developer
claims that LIMRES=YES is assumed whenever DISCNT=YES or DELAY is specified.
This is a very sensible assumption but there is no mention of this in any of
the CS SNA manuals.
You may like to use the possibility to try a connection from the VTAM/NCP
side immediately the switched PU is activated rather than wait for an
outgoing session to be initiated. This is DWACT=YES.
[4] Have you been running these AS/400 connections over token ring with a
transmit window of 1 for the last 10 years? It's a feature of the token ring
connection-oriented 802.2 link level protocol that a transmit window up to
127 may be used. My experience of true token ring networks with 4 or 5
segments, that is, with 3 or 4 bridges, is that a window size of about 20
allows acknowledgements to arrive in time for the sending station not to
have to wait. I was able to discover this using the excellent NetView
NTuneMon tool. The ideal number for you may be higher if you have a DLSw
segment in your logical token ring network. On the other hand, there may be
storage constraints in your router/bridges. You may think why not just
specify 127. Here I tend to be cautious since setting an upper limit ensures
that there will never be a need to store more than the specified number of
frames pending acknowledgement, whatever disasters befall the network.
You may also like to ensure that this and other 802.2 parameters are set
sensibly both in the NCP and in AS/400 customization. For example, you may
like to ensure that sending acknowledgements is delayed thereby allowing
traffic in the reverse direction to carry acknowledgements rather than
always sending "receive ready" (RR) frames. This is where typically
non-default values for the T2 timer and N3 count need to be specified. In
order to have students experiment with this I have suggested 2 seconds, the
maximum allowed by NCP, for the T2 timer, one value for a one-segment
connection and one value for a multisegment connection, and 15 for the N3
value. If you use the possibility to specify the T2TIMER operand on the
switched PU statement, you can experiment easily in order to see whether
such high - and efficient in terms of traffic - values work well for
interactive sessions. T2TIMER applies to sending from the VTAM/NCP side.
Similar customization will apply on the AS/400 side for sending from the
AS/400 side.
I wonder what the MAXOUT operand comment "SHOULD MATCH MODE QPCSUPP" is
supposed to mean. All the discussion above was for operation of the link
level protocols. The mode table is concerned with session-level protocols.
It's true that acknowledgement traffic at the two levels can have an
influence on one another. For example, if there are frequent
application-level acknowledgements, this can avoid the need for
session-level acknowledgements, that is, pacing request units, hence the
suggestion to use PACING=0 and VPACING=0, and, with suitable T2 and N3
values, RR acknowledgements as the link level can generally be avoided when
traffic is in both directions. However this can be two batch streams in
opposite directions rather than one conversational session. Taking a look at
the QPCSUPP mode table as specified in the CS SNA Resource Definition
Reference manual, the only vaguely interesting feature is the specification
of 7 for all the pacing values.
[5] A PU is always type 2. There is no qualification possible for the "2".
There are masses of misleading instances of the horrible term PU 2.1 - it
hurts my fingers to type it - out there, some of it shamefully at the hands
of VTAM developers who know they know better - just try asking one. The only
trivial excuse is that "PU' takes up less space than "node". In other words,
it's "node" that can be qualified as type 2.0 or type 2.1, not "PU". There
is a touch of sense in the comment in that, before XIDs are exchanged, the
nodes about to make contact do not know whether they are node type 2.0 or
node type 2.1. If an XID type 3 is returned by the adjacent node it is a
type 2.1 node.
[6] You have DIALNO=0008400012923743 and you have to explain, after a
fashion, that
X'00' is the TIC port number
X'08' is the destination SAP number*
X'400012923743' is the locally administered MAC address
* Is there a reason it isn't the usual X'04'?
How much better to be able to define these values in the following way:
DLCADDR=(1,C,TR), <=========== TOKEN RING FORMAT
DLCADDR=(2,D,0), <============ PORT NUMBER
DLCADDR=(3,X,08), <=========== DESTINATION SAP
DLCADDR=(4,X,400012923743), <= DESTINATION MAC
if only to be able to put a comment on each line!
[7] I thought that REDIAL didn't apply to token ring but I can't find any
conclusive evidence of that. It's an operand originally provided for to the
not very reliable telephone connections of yesteryear where redialing might
routinely be required. The PATH operand provides the first suboperand of the
NCP REDIAL operand where a quite complex redialing sequence can be defined.
Only SDLC, BSC and start-stop communication protocols, all used over
switched telephone circuits, are mentioned in the NCP description of the
REDIAL operand. Perhaps it was that that gave me the idea it didn't apply to
token ring. I notice you have specified a non-default value so perhaps
whoever set up your definitions knows better.
Incidentally, in case you haven't specified REDIAL in your NCP definitions,
the defaults values are all "0" meaning you will just get 7 immediate
retries - if indeed the REDIAL operand has any effect.
[8] LOCADDR=0 is an aberration - as any VTAM developer will tell you if
he/she is honest. Each LOCADDR=0 statement has to be converted by VTAM into
a CDRSC. How much better if the true definition is clearly stated in the
VTAM major and minor nodes rather than found to be missing where it was
specified and turning up somewhere it wasn't specified (the ISTPDILU major
node).
Taking your example, it is converted into a CDRSC as follows:
CDRSC ALSLIST=P29C881,
DLOGMOD=QPCSUPP,
MODETAB=AMODS400,
RESSCB=2,[10]
VPACING=0
The PU statement name is specified by the ALSLIST operand, where "ALSLIST"
stands for "adjacent link station list" - and, if I started talking about
the fact that the PU statement really represents an SNA adjacent link
station entity rather than an SNA PU entity, we'd be here all night. <g>
[9] ISTINCLM is the supplied IBM mode table and it isn't even a default. It
is always used if a mode table entry cannot be found in the mode table
specified by the MODETAB operand. Thus specifying MODETAB=ISTINCLM is
strictly redundant.
[10] What this implies is that you are making sure, when you start sessions
between SSCP-independent LU 6.2 LUs that there is a guarantee that, having
started sessions, a total of three sessions can be started without needing
to scrap with other LU 6.2 session sets for additional control blocks. You
will need two sessions for "change number of sessions" (CNOS) purposes, the
SNASVCMG sessions, and so there will be 1 additional control block reserved
for a "business", QPCSUPP, session.
A much better approach than worrying about how many additional session
control blocks to try to reserve is to use the "dynamic pool" capabilities
in NCP, associated with the BUILD statement DYNPOOL operand. This way you
can expand LU 6.2 session control block requirements into the general,
probably unconstrained, buffer pool.
-
I notice you have only one SSCP-independent LU. It may be useful to know
that you can use the CP as an application LU. The CP function, operating
through the LU logic in the node, distinguishes itself by use of the CPSVCMG
mode name. There is no reason at all why the "business" sessions shouldn't
use the same LU name as the CP. This would avoid defining the
SSCP-independent LU on the AS/400. Of course, I expect this appears to be
such a trivial matter as not to be worth considering as excessive work when
dozens of SSCP-dependent LUs have to be defined.
Note that only some mainframe applications need static definitions of the
LUs which will be used to establish sessions with the application LU(s).
CICS used to be such a mainframe application but, thankfully, the
"autoinstall" function was provided. NetView in the form of NOSP used to
many decades ago. TSO never has and HCF, which I see mentioned, never has
either.
---
Desi,
Now the comments, additional to the above, where relevant, on your
definitions.
Do you match the connecting AS/400 with the switched PU definition based on
CPNAME or the IDBLK and IDNUM combination? I can't tell from your
definitions since it depends on the SWNORDER start option. The default is
SWNORDER=(CPNAME,FIRST) meaning that the first attempt at matching is on the
CP name and only afterwards on the node identification field (IDBLK/IDNUM).
It may be you really don't need the IDNUM and IDBLK operands.
BATCH became obsolete in NCP V4R3 which takes us back to the days before the
3745 became the workhorse of SNA.
It is a mystery why PASSLIM was ever a switched PU operand. It is all about
SDLC multipoint operation: how many SDLC frames to send to one secondary
station on the multipoint line before starting to send frames to another. A
switched line only ever has one station so the operand cannot possibly ever
apply. (The same goes for IRETRY.) Unfortunately I wasn't paying close
attention when switched support was introduced to VTAM and NCP sometime in
the late 1970s. It may be that it was introduced together with the closely
related "dynamic reconfiguration" function. The same control vector (CV),
the famous X'43', Extended SDLC station", is used for both and it may be
that the VTAM developer saw that PASSLIM and IRETRY had fields in the CV and
so provided operands for them in the switched PU statement. Pure
speculation.
The appearance of GID and PID are rather odd. I rather doubt you intend to
use the VARY PATH command to enable and disable your token ring switched
path definitions - but what do I know of your installation.
I see you have only the one SSCP-independent LU definition. This is
definitely a situation where using the CP LU, as I described above, might be
found less work.
I think the RESSCB=1 does not more than make sure you can start the two
SNASVCMG, CNOS, sessions which may not be what you intended.
Since you have only this one SSCP-independent LU definition, the
SSCPFM=USSSCS specification isn't doing anything for you.
Chris Mason
----- Original Message -----
From: "Thomas Lawrence" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Saturday, 22 April, 2006 1:20 AM
Subject: Re: Need Help defining an AS400 with an IP address to the mainframe
> So many responses, so little I know. I believe the project (as my boss is
> wont to call it) to connect the 'new' as400 to the mainframe, is probably
> (but I'm not completely sure of this) going to be running the same
programs
> the older one did. They did mostly inhouse apps of a database nature, and
> some ftp. That probably will not change. The reason they need to connect
to
> the mainframe is that their 'terminals' (read pc's) do double duty, i.e.,
> they are mainframe terminals (CICS mainly) and also AS400 terminals when
the
> need arises. So, in effect, the AS400 is one menu selection off a USSTAB
> provided by VTAM. In addition, there are AS400 terminals which access
> applications on the mainframe. The following is the SWNET definition
> currently in effect:
> <br>
> *
> H29C881 VBUILD TYPE=SWNET,MAXGRP=2,MAXNO=4
> *
> P29C881 PU ADDR=13, REQ'D, BUT NOT USED X
> CPNAME=S1023743, AS400 NETA CPNAME X
> PUTYPE=2, BECOMES T2.1 AFTER XID3 X
> MAXPATH=4, X
> MAXOUT=1, SHOULD MATCH MODE QPCSUPP X
> DISCNT=NO, MAY NEED TO CHANGE X
> ISTATUS=ACTIVE, X
> SSCPFM=USSSCS, USSSCS RECOMMENDED X
> MODETAB=ISTINCLM, X
> DLOGMOD=SNX32702, DEFAULT FOR EM5250 DEVS X
> VPACING=0
> *
> *
> D29C881 PATH GRPNM=TRNLG1, X
> DIALNO=0008400012923743, TIC/DSAP/AS400 LCLTRADDR X
> REDIAL=7, THE DEFAULT IS 3 X
> USE=YES
> *
> AS400C LU LOCADDR=0, AS400 APPN LCLLOCNAME X
> MODETAB=AMODS400, WHERE QPCSUPP IS DEFINED X
> DLOGMOD=QPCSUPP, QPCSUPP IS REQUIRED X
> RESSCB=2 # OF SCB RESERVED IN NCP
> *
> *
> * FOLLOWING LU'S GIVE AS/400 TERMS ACCESS TO MAINFRAME
> * THE AS/400 IS RESPONSIBLE FOR 3270 EMULATION. THESE
> * ARE 'REAL' DEVICES. THEY NEED TO BE DEFINED TO THE
> * MAINFRAME APPLICATIONS WHICH THEY WILL ACCESS.
> *
> T29C8812 LU LOCADDR=2 JB M00-0463
> T29C8813 LU LOCADDR=3 JB M00-0463
> T29C8814 LU LOCADDR=4 JB M00-0463
> T29C8815 LU LOCADDR=5 JB M00-0463
> T29C8816 LU LOCADDR=6,USSTAB=USS03S11
> T29C8817 LU LOCADDR=7,USSTAB=USS03S11
> T29C8818 LU LOCADDR=8,USSTAB=USS03S11
> T29C8819 LU LOCADDR=9,USSTAB=USS03S08
> T29C881A LU LOCADDR=10 *HCF/DHCF TERMINAL
> T29C881B LU LOCADDR=11,USSTAB=USS03S11
> T29C881C LU LOCADDR=12,USSTAB=USS03S11
> T29C881D LU LOCADDR=13,USSTAB=USS03S11
> T29C881E LU LOCADDR=14,USSTAB=USS03S11 PO 10/24/94 M940394 E239 T
> T29C881F LU LOCADDR=15,USSTAB=USS03S27
> T29C881G LU LOCADDR=16,USSTAB=USS03S27
> .
> .
> .
> <br>
> I'm not going to quote the whole thing, but you get this idea. This AS400
is
> connected off a TIC on the 3745, TRNLG1 is a LINE GROUP, H29C881 is a SW
SNA
> MAJ NODE.
>
> Does this help?
>
> And thanks for all the suggestions so far.
> TL
----------------------------------------------------------------------
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
