VTAM USSTAB QUESTION
Howard Rifkind
P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
USSPARM PARM=APPLID,DEFAULT=TMONMVS
When I key in P39TMMVS we are really getting TMONMVS as the executable.
What I don't understand is what path is followed to execute TMONMVS?
Any help will be appreciated.
T.Y.
_____________
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Pommier, Rex R.
keyed-in P39TMMVF with a LOGON APPLID(TMONMVS) which is what VTAM
actually uses to log you on. For further information, check the SNA
resource definition reference manual. There is a section on USSTAB that
(kinda) explains the parameters. :-)
Rex
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Howard Rifkind
Sent: Monday, February 09, 2009 1:48 PM
To: IBM-...@bama.ua.edu
Subject: VTAM USSTAB QUESTION
I have the following entry in my USSTAB:
P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
USSPARM PARM=APPLID,DEFAULT=TMONMVS
When I key in P39TMMVS we are really getting TMONMVS as the executable.
What I don't understand is what path is followed to execute TMONMVS?
Any help will be appreciated.
T.Y.
----------------------------------------------------------------------
Jim Wangler
Jim Wangler
214-502-6445
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Howard Rifkind
Sent: Monday, February 09, 2009 1:48 PM
To: IBM-...@bama.ua.edu
Subject: VTAM USSTAB QUESTION
Lizette Koehler
I do not know if this will help, but in our USS tab we code TMON this way
TMONMVS USSCMD CMD=TMONMVS,REP=LOGON,FORMAT=BAL
USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS
USSCMD CMD=TMVS,REP=LOGON,FORMAT=BAL
USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS
Our USSPARM has a REP=APPLID but I do not see one in yours.
Lizette
>
>I have the following entry in my USSTAB:
>
>P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
> USSPARM PARM=APPLID,DEFAULT=TMONMVS
>
>When I key in P39TMMVS we are really getting TMONMVS as the executable.
>
>What I don't understand is what path is followed to execute TMONMVS?
>
>Any help will be appreciated.
>
>
----------------------------------------------------------------------
Chris Mason
I seem to detect that you are taking an UNIX view of the world here. It is as
if the window into which you key "P39TMMVS" were controlled by some sort of
operating system and the command keyed mapped directly to a command
which was one of the operating system's repertoire of commands.
It isn't like that, it's sort-of simpler and maybe also sort-of more complicated!
Let us say just different!
Behind TMONMVS there is an application program, x, which is already running
in the z/OS system - I assume of the z operating systems. It was started,
probably using clever automation, with a z/OS START command referring to a
stored procedure in the procedure library the JCL of which included crucially
something like // EXEC PGM=x.
Early in its life, the program issued a call over the VTAM API involving a
supervisor call which "opened" an application control block (ACB). The ACB
referred to a text string which specified "TMONMVS". "TMONMVS" is the name
of a logical unit, LU, an entity within Systems Network Architecture, SNA,
which, together with the logical support of programming within computing
nodes within a network of interconnected nodes, allows reliable communication
between such an LU and another complementary LU comprising an SNA
session.
Note that reliable - connection-oriented - communication using SNA owes
absolutely nothing to the thoroughly unreliable - connectionless -
communication architecture normally associated with UNIX. SNA was devised
for business communication and was announced back in 1975. It has been
used extensively ever since. Only recently has the thoroughly unreliable
communication architecture normally associated with UNIX managed gradually
to push it aside and only because of massive efforts in piling up additional
nodes, protocols and programming to cover up the inherent deficiencies and
because the inherent inefficiency can be masked by the relative cheapness
of "bandwidth" - but I digress.
Presumably you are sitting at some sort of emulator entering your Unformatted
Systems Services (USS) command. Behind that emulator may be programming
actually supporting the LU which will become the SNA communications partner.
Alternatively, you may be rather closer to the UNIX experience and using
TELNET, specifically the "3270" flavour of TELNET, TN3270, more specifically,
since you have the ability to use USS commands, TN3270E. The partner in the
TN3270E connection will be a TN3270E server, either another program running
under z/OS - started incidentally in all likelihood as program x was started.
Alternatively it may be "outboard" and running in a node within the network
where there is a change of network protocol. If a TN3270E server is being
used it will be supporting additionally the LU which will become the SNA
communications partner.
When you enter the "P39TMMVS" command it is sent over a session which was
established when VTAM or, in the terminology of SNA, the System Services
Control Point (SSCP) "activated" the LU which will become the SNA
communications partner - actually a process comparable to that involved with
the "opening" of the ACB mentioned earlier. The session is the SSCP-LU
session. Note that the VTAMs involved need not be the same since we are
dealing with an advanced set of communication protocols here!
If there is no intervening TN3270E connection, the VTAM (SSCP) which
received the "P39TMMVS" command now refers to the USS table ideally
implicitly[1] defined for use with the LU. In your case, there is a mapping
of "P39TMMVS" to the USSCMD macro CMD operand - the name is typically
the same but is, in effect, a comment in the source since it is not present in
the object module. The USSCMD macro REP operand specifies that the
appropriate prototype is the "LOGON" command - as opposed to the LOGOFF
or IBMTEST - or, for VM systems, UNDIAL - commands.
The LOGON command prototype - which is, incidentally always available since,
if the command does not map to a command defined in the USS table defined
with the LU, the IBM-supplied USS table ISTINCDT is used - is, as Jim Wangler
partially indicated, as follows - in an abbreviated form concentrating on the
principle keywords:
LOGON APPLID(appl-name)DATA(logon-data)LOGMODE(logmode-entry-name)
Your USSPARM macro specifies that the default value for the APPLID keyword
is to be "TMONMVS". Thus your command "P39TMMVS" causes a session setup
request between the LU supported by your emulator and the application LU
known within SNA, and happening to be supported in the z/OS node over the
VTAM API, as "TMONMVS". The newly established LU-LU session now "takes
over" your emulator window. There may well be a little symbol in the bottom
left of the window which shows a "stick man" at the time you can enter the
USS command and a solid rectangle when the LU-LU session has "taken over".
QED
You will note that you have not supplied any value for the DATA keyword nor
the LOGMODE keyword. If you had wanted to supply some data for the DATA
keyword, perhaps an userid, you could have specified something like
"P39TMMVS DATA=HOWARD"
Note that you had elected to use the BAL, "basic assembled language", format
and so you would need to supply the equal sign. If you read up some more on
USS - as Rex Pommier suggested - you could find out how this could be made
more agreeable as
"P39TMMVS HOWARD"
Obviously the "data" is available to the program as part of the session setup
sequence. You will also note that the prototype commands, including the
LOGON command, use an alternative format encoded as FORMAT=PL1.
You could indicate the extent to which you had grasped the principles of the
USS table by entering the command
"P39TMMVS APPLID=TSO"
and finding yourself presented with the TSO LOGON panel! The point is
that "P39TMMVS" is a substitute for the "LOGON" command and "TMONMVS" is
only the *default* value for the APPLID keyword.
Unfortunately it may very well be a touch more complicated than I have
presented so far.
If there *is* an intervening TN3270E connection, it is the TN3270E server
which receives the USS command over the TN3270E connection.
If the TN3270E server is "outboard", what I have described so far applies since
the USS command is "relayed" over the SSCP-LU session which terminates in
the LU logic in the TN3270E server.
If the TN3270E server is running in z/OS, the USS table is defined to the
TN3270E server and the server program attempts to pretend to be VTAM. The
USS commands are mapped to "formatted" commands by means of calls over
the VTAM API supporting the application behaving as a workstation LU so that
the same fields are presented over the SSCP-LU session which logically exists,
necessarily all within the same set of programs running under z/OS, between
VTAM and the TN3270E server. Incidentally, there is logically a similar SSCP-
LU session running between VTAM and LU "TMONMVS" supported by program x.
It's important to have this picture clearly in mind when working out what
influence a mode table entry specified in the USS table set of entries might
have in the case of the z/OS TN3270E server as I was obliged to do recently.
Well, you did ask!
Chris Mason
P.S. I recommend you follow Rex's advice - as might Rex himself if this is a
topic he hasn't visited recently - and see what a wealth of information can be
presented in the USS *messages*, especially message 10 - and message 5 if
you are not using TN3270E. Post again if you are in this situation and message
5 does not immediately look promising.
[1] In the bad old days there would be an LU statement defined for each
possible workstation. Canny implementation today - and for the past decade
or so - will rely upon LU statement models, a "trick" similar to "CICS
autoinstall" if you are familiar with that.
On Mon, 9 Feb 2009 14:48:11 -0500, Howard Rifkind
<Rifk...@EMIGRANT.COM> wrote:
>I have the following entry in my USSTAB:
P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
USSPARM PARM=APPLID,DEFAULT=TMONMVS
When I key in P39TMMVS we are really getting TMONMVS as the executable.
What I don't understand is what path is followed to execute TMONMVS?
Any help will be appreciated.
T.Y.
_____________
Chris Mason
<quote>
If REP is not coded, it takes the value of PARM. (That is, the user-entered
parameter is used as entered.)
</quote>
Chris Mason
On Mon, 9 Feb 2009 15:22:45 -0500, Lizette Koehler
<star...@MINDSPRING.COM> wrote:
>Howard,
>
>I do not know if this will help, but in our USS tab we code TMON this way
>
>TMONMVS USSCMD CMD=TMONMVS,REP=LOGON,FORMAT=BAL
> USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS
> USSCMD CMD=TMVS,REP=LOGON,FORMAT=BAL
> USSPARM PARM=APPLID,REP=APPLID,DEFAULT=TMONMVS
>
>Our USSPARM has a REP=APPLID but I do not see one in yours.
>
>Lizette
>
>
>
>>
>>I have the following entry in my USSTAB:
>>
>>P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
>> USSPARM PARM=APPLID,DEFAULT=TMONMVS
>>
>>When I key in P39TMMVS we are really getting TMONMVS as the
executable.
>>
>>What I don't understand is what path is followed to execute TMONMVS?
>>
>>Any help will be appreciated.
----------------------------------------------------------------------
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex R.
>
> From what I remember from long ago is that the USSCMD replaces your
> keyed-in P39TMMVF with a LOGON APPLID(TMONMVS) which is what VTAM
> actually uses to log you on. For further information, check the SNA
> resource definition reference manual. There is a section on USSTAB
that
> (kinda) explains the parameters. :-)
And if you *really* want to know what's going on, read the SNA
Programming Reference manual. :-)
-jc-
Chris Mason
I realise this is intended to be a joke of some sort in response to another joke
of some sort. That aspect having been noted, in the matter of the mapping of
Unformatted System Services command text strings to VTAM API calls which
create Formatted System Services request units by the TN3270E server, the
z/OS Communications Server (CS) SNA Programming manual is not of any
great use in understanding the flow associated with USS tables.
What you need to create USS tables is explained in the z/OS CS SNA
Resource Definition Reference manual as Rex indicated. However you need to
have patience with the rather laboured treatment - par for the course in IBM
manuals in general - which reminds me that I heard that the author of a new
edition of a set of product manuals who had merely "rearranged the chairs"
under some misleadingly promising "How To" section titles received an award
for his efforts - "Plus ça change ..."
The USS section is worth "revisiting" from time to time in order to see whether
any new substitutions are possible in the USS messages. It may not generally
be appreciated that some of the fields are specifically for the benefit of the
TN3270E server pretending to behave like the VTAM SSCP but extending that
support to inserts relevant only for TN3270E.
If the author of RFC 2355 had taken the trouble to wade though that USS
section, he may have appreciated that the support for the USS LOGOFF
command should have been defined much, much more closely in terms of how
VTAM behaving as an SSCP supported the LOGOFF command.
The manual which actually offers help in "knowing what's going on" with
respect to USS flows is the z/OS CS SNA Diagnosis Vol 1, specifically Figure
119.
Chris Mason
On Tue, 10 Feb 2009 10:08:06 -0600, Chase, John <jch...@USSCO.COM>
wrote: