How Mainframe Startup Screen Works
Quasar Chunawala
I am a COBOL Programmer. Just out of curiosity, I would like to know, how
Mainframe Startup Screens(the first screen that you see, when you connect to
a Mainframe Server, and where you would type TSO) are written. I have heard
they use VTAM Commands. Is there a particular member in some system library,
which contains the actuaal Startup Screen code?
I know, this may not be the right place to ask such questions, but I don't
know any other forums or mailing lists specific to it.
Thank you very much.
Quasar Chunawala,
Author, Mainframes360.com
Cell : 9930389084
E-mail : quasar.c...@gmail.com
Blog : http://www.mainframes360.com
----------------------------------------------------------------------
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
Thomas Dunlap
There is a set of assembler macros and constants which make up something
called the "USS Table". This is how the initial logon screen is defined
through VTAM. As for where it is located, that is hard to say. Almost
every site customizes the USS table so it will reside in a library your
sight keeps any user modifications to the system.
--
Regards,
Thomas Dunlap Chief Technology Officer to...@themisinc.com
Themis, Inc. http://www.themisinc.com 1 (800) 756-3000
Lizette Koehler
Mainframe
> Startup Screens(the first screen that you see, when you connect to a
Mainframe
> Server, and where you would type TSO) are written. I have heard they use
VTAM
> Commands. Is there a particular member in some system library, which
contains the
> actuaal Startup Screen code?
>
> I know, this may not be the right place to ask such questions, but I don't
know any
> other forums or mailing lists specific to it.
>
> Thank you very much.
>
> Quasar Chunawala,
If I understand you - you want to know how to logon to the mainframe. The
following is a very simple overview.
The mainframe connection first needs a 3270 Terminal emulator. This can be
IBM PCOM, Attachmate !Extra, Hummingbird, bluezone, and so for.
Once the terminal emulator is install, you need to specify an IP address to
the mainframe system.
Then you should get a USS10 message. Which could be a one liner or a panel.
It will depend on your site. The USSTCPxx or USSTABxx contains the
application and VTAM Messages. For example, a USS10 message could be coded
as
MESSAGES USSMSG MSG=10,TEXT='@@LUNAME - ACF/VTAM10:: PROD SERVICEX
SYSTEM.'
Since this is a macro, it needs to be coded according to the assembler
language syntax. Then once all the applications and messages are entered
into your USSTABxx member, you assemble and link the source. The load
module will be placed into your VTAMLIB library. You need to contact your
VTAM system programmer for more information.
These are VTAM Assembler Macros you use to define your applications to VTAM
for logon.
Then when you have your VTAM USS10 message up, you can then enter things
like TSO, TPX, CICSXX if it is defined in those programs. If the
application is not defined in the USS Table of VTAM then you cannot access
it.
The COMMUNICATION SERVER manuals (VTAM or SNA) will provide much more
details on this process.
Others will correct me if I am incorrect.
HTH
Lizette
Hal Merritt
There is usually one for each type of hardware terminal supported.
It is a table, as it is most often used to take arbitrary entries and execute the VTAM commands necessary to invoke an application.
By the way, that initial z/os screen seems to have become known as a 'green screen'.
Hi,
Thank you very much.
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Hal Merritt
>
> This is called the 'USS Table' or Unformatted Screen Services (I
think). It is a BAL program using
> macros supplied with the VTAM product. The program source could be
anywhere; ask your VTAM guy if
> you have one or general sysprog if you don't. The executable can
reside in a number of different
> system load libraries. Again, ask your VTAM person or sysprog.
More precisely it's the 'USSMSG10 screen', a part of Unformatted System
Services.
> There is usually one for each type of hardware terminal supported.
>
> It is a table, as it is most often used to take arbitrary entries and
execute the VTAM commands
> necessary to invoke an application.
Here ITYM the USSCMD table.
> By the way, that initial z/os screen seems to have become known as a
'green screen'.
Indeed, the 'mainframe interface' generally is known as 'green screen'.
-jc-
Chris Mason
As a COBOL programmer in an installation, you need instructions over how to
access TSO which are specific to your installation. You cannot find this is any
manual provided by IBM.
> Just out of curiosity, ...
Does this mean you have such instructions and you can access TSO without
difficulty but you just want to know how it all works?
> ... I would like to know, how Mainframe Startup Screens (the first screen
that you see, when you connect to a Mainframe Server, and where you would
type TSO) are written.
Now I digest the rest of this post, I think the answer is yes, I stupidly
read "where you would type TSO" as "where would you type TSO" even
without the question mark!
The first display image you see once - I guess - you have started up your
TN3270 client and connected to the TN3270 server, as supported - again a
guess - by the z/OS Communications Server (CS) IP component, is an
Unformatted System Services Message 10.
-
We must pause here and I have to ask you to take care that you are not in
the vicinity of sharp objects! Since I don't want to have to key "Unformatted
System Services" every time I wish to refer to this function - or even
use "copy and paste" as just now - I need to introduce you to its abbreviation
as defined in
http://www-01.ibm.com/software/globalization/terminology/u.html
It is "USS". Now you may be under the impression that this stands for "UNIX
System Services" but despite massive misuse throughout cyberspace, this is
actually wrong - as you can easily see from that IBM site URL.
It is my opinion that people who misuse the initialism[1] should be aware of
the shock such a reversal of understanding could cause to folk relatively new
to z/OS.
Be aware that I will refer to USS commands and USS messages. These
commands and messages have nothing whatsoever at all in this planet to do
with z/OS UNIX System Services (z/OS UNIX, to use the correct abbreviation).
Now that you have reset your understanding of this matter, we can proceed.
-
> I have heard they use VTAM Commands.
In fact, no VTAM commands are involved as you will find them described in the
CS SNA (VTAM) Operations manual.
Case A. If, as I guess, you are using the TN3270 server, the commands you
enter were set up by your CS systems programmer - who probably has skills
extending to both of the components, the IP one covering the TN3270 server
and the SNA (VTAM) one. In that case the USS commands you enter are
processed by the TN3270 server in order to present the appearance of - to
keep it simple - a display terminal to TSO over an SNA session. I always like to
describe this configuration as a TN3270 TCP connection concatenated to an
SNA session.
Case B. If on the other hand you are *not* using the TN3270 server but your
workstation is connected over a data link which supports protocols which can
handle the connection-oriented traffic required by SNA[2], then the USS
commands you enter are processed by VTAM. In this case, you could say they
are "VTAM commands" but that is a misleading avenue to follow.
> Is there a particular member in some system library, which contains the
actual Startup Screen code?
There is definitely one and you should easily be able to locate a second, the
one you probably really want.
I'll explain!
In case A (TN3270), the one you should be able to find easily is the member
of the library in the typically concatenation of partitioned data sets (libraries)
containing *object* modules which logically uses the STEPLIB DD-name in the
procedure used to support the TN3270 server address space. There may not
actually be a STEPLIB so check with the appropriate systems programmer.
The name of the member is the name which is specified by the relevant
USSTCP statement in the PROFILE data set used by the TN3270 server
program. If you have a complicated TN3270 PROFILE data set, you will need
some help from the responsible systems programmer again.
In case B (VTAM), the one you should be able to find easily is the member of
the library in the typically concatenation of partitioned data sets (libraries)
containing *object* modules which use the VTAMLIB DD-name in the
procedure used to support the VTAM (named NET, typically) address space.
The name of the member is the name on the USSTAB operand which is
specified on the VTAM LU statement or the LOCAL statement which
corresponds to your workstation. I guess you are going to need the help of a
systems programmer who understands the VTAM environment to help you here.
Having keyed "LOCAL", I appreciate that you may be using the OSA-ICC
feature in which case there is a case C, similar to case B in that the
information for which you are looking is in VTAM data sets but similar to case
A in that you are using a TN3270 client. The TN3270 server in this case is
supported by the OSA-ICC feature and it gives the appearance of a pre/non-
SNA local 3270 display device to VTAM.
Communications is all "smoke and mirrors"!
But we still haven't got to what you probably *really* want to see which is
the *source* of the set of definition statements, assembler macros, in fact,
used to build the object module whether used by the TN3270 server (not the
OSA-ICC one but the CS IP one) or VTAM.
If your systems programmers had attended my classes of old, they would
know that the recommendation was to store the source files in the VTAM
VTAMLST data set using the same name as is used to store them in the
object partitioned data set. Why? So you would always know where to find
them! As it is, they may not have adopted this policy and have them stored
away somewhere else. Again you are at their tender mercies.
Finally, you are not dealing with WYSIWYG files here and so, even with the
source files at your fingertips, they may appear largely to be gobbledygook.
If you really want to understand what the macros in this file do, here are two
URLs for z/OS V1R12 - although the level is unimportant:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B6A0/5.11
http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/f1a1b3a0/2.2.1.4.15?
The first is the VTAM manual which is the authoritative one. The second is the
CS IP manual needed to cover where the object modules should be stored if
you are using the CS IP TN3270 server - in just the last paragraph of the page!
-
> I know, this may not be the right place to ask such questions, but I don't
know any other forums or mailing lists specific to it.
This is certainly a very good place to be asking - I guess not least because
you might get a more extensive answer elsewhere but I, for one, would like to
know where!
It's a particularly good place to be asking right now because there are a
number of list subscribers who very much need reminding that this function
exists, is alive and kicking and solicits interest - especially in those among
whom I assume you belong who are relatively new to z/OS.
There is another list which looks after matters more specifically concentrated
on mainly z/OS CS. The emphasis - as everywhere these days - is on the
functions within the IP component but because one important function is
Enterprise Extender, queries on this topic tend to be asked there and thus the
list becomes extended also to cover VTAM.
For IBMTCP-L subscribe / signoff / archive access instructions, send email to
LIST...@VM.MARIST.EDU with the message: INFO IBMTCP-L
-
[1] There are some who, despite knowing the correct use, persist in the
misuse and you will currently find a plethora of threads in IBM-MAIN trying to
uphold this erroneous position - very obstinate characters indeed!
[2] Which could include Enterprise Extender and so you could still in fact have
the connection wholly or in part supported by an/the IP network.
-
Chris Mason
On Tue, 10 May 2011 08:32:34 -0400, Quasar Chunawala
<quasar.c...@GMAIL.COM> wrote:
>Hi,
>
>I am a COBOL Programmer. Just out of curiosity, I would like to know, how
>Mainframe Startup Screens(the first screen that you see, when you connect
to
>a Mainframe Server, and where you would type TSO) are written. I have
heard
>they use VTAM Commands. Is there a particular member in some system
library,
>which contains the actuaal Startup Screen code?
>
>I know, this may not be the right place to ask such questions, but I don't
>know any other forums or mailing lists specific to it.
>
>Thank you very much.
>
>Quasar Chunawala,
>Author, Mainframes360.com
>Cell : 9930389084
>E-mail : quasar.c...@gmail.com
>Blog : http://www.mainframes360.com
----------------------------------------------------------------------
Ed Gould
Close...
You can actually logon on to *ANY* application in the world that is hooked up to
you network.
logon applid(cicsbombay)
Will take you to *WHERE EVER* ythe applid is running in the attached network.
IT really does not have to be defimes in any USSMSG just an active APPLID in the
SNA network that you are attached to.
Ed
________________________________
From: Lizette Koehler <star...@MINDSPRING.COM>
To: IBM-...@bama.ua.edu
Sent: Tue, May 10, 2011 8:32:15 AM
Subject: Re: How Mainframe Startup Screen Works
Don Poitras
http://www.sssgmbh.de/download/zos/sysp.usersrc/ussrole
To decode the 3270 bits, look here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7P4000/CCONTENTS
hase, John wrote:
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List On Behalf Of Hal Merritt
> >
> > This is called the 'USS Table' or Unformatted Screen Services (I
> think). It is a BAL program using
> > macros supplied with the VTAM product. The program source could be
> anywhere; ask your VTAM guy if
> > you have one or general sysprog if you don't. The executable can
> reside in a number of different
> > system load libraries. Again, ask your VTAM person or sysprog.
>
> More precisely it's the 'USSMSG10 screen', a part of Unformatted System
> Services.
>
> > There is usually one for each type of hardware terminal supported.
> >
> > It is a table, as it is most often used to take arbitrary entries and
> execute the VTAM commands
> > necessary to invoke an application.
>
> Here ITYM the USSCMD table.
>
> > By the way, that initial z/os screen seems to have become known as a
> 'green screen'.
>
> Indeed, the 'mainframe interface' generally is known as 'green screen'.
>
> -jc-
--
Don Poitras - zSeries R & D - SAS Institute Inc. - SAS Campus Drive
mailto:sas...@sas.com (919)531-5637 Fax:677-4444 Cary, NC 27513
Lizette Koehler
>
> You can actually logon on to *ANY* application in the world that is hooked
up to you
> network.
> logon applid(cicsbombay)
> Will take you to *WHERE EVER* ythe applid is running in the attached
network.
> IT really does not have to be defimes in any USSMSG just an active APPLID
in the SNA
> network that you are attached to.
>
>
If you want your user to use CICSAPP1 as the logon to CPRD001 (CICS System
Name), Then I think you need to code it in the USS Table pointing to that
Applid.
Is that correct?
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler
>
> > Close...
> >
> > You can actually logon on to *ANY* application in the world that is
hooked
> up to you
> > network.
> > logon applid(cicsbombay)
> > Will take you to *WHERE EVER* ythe applid is running in the attached
> network.
> > IT really does not have to be defimes in any USSMSG just an active
APPLID
> in the SNA
> > network that you are attached to.
> >
> >
>
> If you want your user to use CICSAPP1 as the logon to CPRD001 (CICS
System
> Name), Then I think you need to code it in the USS Table pointing to
that
> Applid.
>
> Is that correct?
Yes; "normally" in the USSCMD table.
-jc-
Lindy Mayfield
Ed Gould
Of course my example used CICS but as you mentioned TSO will act exactly the same.
BTW the APPLID can be called anything ((almost anyway). I have designed a few such systems and ts fun to watch the system evolve and subsequent systems peoe screw around with naming standards and it becomes a royal mess.
Ed
Gerhard Postpischil
> This is called the 'USS Table' or Unformatted Screen Services
> (I think). It is a BAL program using macros supplied with the
> VTAM product.
<pedantry> I'm not even sure it is possible to get a copy of the
Basic Assembler anymore, although somebody in the Hercules
groups might have a copy. And if you did, modern macros may not
assemble correctly under it. </pedantry>
So please don't use BAL unless you mean it.
Gerhard Postpischil
Bradford, VT
Hal Merritt
Key word here is -language-.
Most any version of the assembler should work just fine, assuming that the appropriate level macros are used. I last used ASMA90 in 2004.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Gerhard Postpischil
Sent: Tuesday, May 10, 2011 1:59 PM
To: IBM-...@bama.ua.edu
Gerhard Postpischil
Bradford, VT
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
----------------------------------------------------------------------
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Gerhard Postpischil
>
> On 5/10/2011 9:41 AM, Hal Merritt wrote:
> > This is called the 'USS Table' or Unformatted Screen Services
> > (I think). It is a BAL program using macros supplied with the
> > VTAM product.
>
> <pedantry> I'm not even sure it is possible to get a copy of the
> Basic Assembler anymore, although somebody in the Hercules
> groups might have a copy. And if you did, modern macros may not
> assemble correctly under it. </pedantry>
>
> So please don't use BAL unless you mean it.
Branch And Link? <g, d, r>
-jc-
Chris Mason
As you an probably tell, this is a topic not completely understood by the
generalists of the list and I need to introduce some comments to align what
you have been told by them with what I told you.
-
From Thomas Dunlap:
> There is a set of assembler macros and constants which make up something
called the "USS Table".
This is a reference to the source file which is assembled and linkage edited
into a load module. The load module must be available either to VTAM or the
TN3270 server. Only the systems programmer knows where the source file is
and the last one with whom I worked had forgotten!
> This is how the initial logon screen is defined through VTAM.
As I explained, the USS table need not be defined only for VTAM but for the
TN3270 server and I expect just about always is these days, sufficiently so
for the thought that you might have a purely VTAM configuration not even to
cross Lizette Kohler's consciousness!
> As for where it is located, that is hard to say.
Definitely in the case of the source file, not that difficult in the case of the
load module!
> Almost every site customizes the USS table ...
It is certain that your installation has a customized USS table since there is no
USS message 10 in the default table, ISTINCDT.
> ... it will reside in a library your sight keeps any user modifications to the
system.
Or possibly VTAMLST if your systems programmer managed to get to one of
my classes!
> ... sight ...
Thomas had a small rush of blood here and meant to say "site"!
-
From Lizette Koehler:
Lizette is considering only my case A.
> ... and so for.
I guess the fingers were too light on the keyboard and that should be "... and
so forth,"
> Once the terminal emulator is install, you need to specify an IP address to
the mainframe system.
Specifically this will be an IP address which allows access to a TN3270 server,
either the z/OS Communications Server (CS) TN3270 server via z/OS CS or
the OSA-ICC TN3270 server. Even in the former case, the CS TN3270 server,
should you actually need to ask for the IP address, you should specify that
you want the IP address of the *TN3270 server* since installations can now -
and have been able for a decade or so now -associate server applications
with specific IP addresses - as well as, as has always necessarily been the
case, with a specific port number.
> Then you should get a USS10 message.
You *may* get an USS message 10 if the TN3270 server has been so
configured. You have implied you do.
> Which could be a one liner or a panel.
What Lizette Kohler may have in mind here is whether the USS message is
defined using the USSMSG macro TEXT operand ("one line") or BUFFER
operand ("panel"). It is clearly possible that the "panel" could consist of just
one line but it is a bit more of a secret that it is possible to create a "multiline"
message with text positioned anywhere on the presentation space surface
even when using the TEXT operand[1] - not easy but possible. If the systems
programmer involved cracked his knuckles before tackling the job and
assuming we are talking about USS messages able to be built using the 3270
data stream, wonderful possibilities for artistic presentations reveal
themselves!
> The USSTCPxx or USSTABxx contains the application and VTAM Messages.
I fear Lizette Kohler may be introducing you to something specific to her
installation - but I can't work out what.
As far as I can tell from the latest manual, in the case of the TN3270 server,
my case A, you have only an USSTCP statement. Of course, she may be
relying on some supposedly enabling package which happens to
adopt "USSTCPxx or USSTABxx" as naming conventions. I wouldn't know
anything about that and neither, quite possibly, would you.
> For example, a USS10 message could be coded as
> MESSAGES USSMSG MSG=10,TEXT='@@LUNAME - ACF/VTAM10::
PROD SERVICEX
> SYSTEM.'
This illustrates two interesting points. The logical unit name, LU name, padded
to 8 characters in order to indicate how much space it might occupy, as
@@LUNAME, is the SNA name which represents the point of concatenation in
the TN3270 server between the TCP connection and the SNA session. The
@@LUNAME is a variable which is substituted during execution. If you have
any problems, this is an useful name to be able to present to the help desk.
The second point is that, if RFC 2355 had been a bit cleverer, it would be
possible to read off this name - from an USS message 5 typically - *if* it was
possible to access the SSCP-LU session while the LU-LU session was active.
RFC 2355 allows the use of an apparent SSCP LOGOFF but it is a pale shadow
of the "real thing". As it is, you are obliged to write the name down - and
you're always going to forget! - *before* you initiate the session with the
application.
> The load module will be placed into your VTAMLIB library.
Thanks to Lizette Kohler, I can mention that, before, when I said "object",
more correctly, I should have said "load", since the module has passed through
the linkage editor.
However, Lizette Kohler is mixing her cases. The VTAMLIB would be
appropriate for my case B (and C) but not for my case A which is the case to
which I thought Lizette Kohler was restricting herself - unless she had my
case C in mind all along!
> You need to contact your VTAM system programmer for more information.
It's not so much "more" as "any"! You'll have noticed in all these responses
that you're going to get nowhere at all until you find out who the systems
programmer is who considers this topic his or her manor.
> These are VTAM Assembler Macros you use to define your applications to
VTAM for logon.
In my case A, it is the TN3270 server which is managing the session setup
from the USS command and not VTAM
In my case B, it is VTAM
In my case C, it is also VTAM
> Then when you have your VTAM USS10 message up, you can then enter
things like TSO, TPX, CICSXX if it is defined in those programs.
There is a bit of an illusion operating here. These apparent application names
are in fact all aliases for the LOGON command. Each one has a default value
for the "application identifier", APPLID, which is the SNA name for the primary
LU, the application. There's nothing at all to stop you keying TSO, say, and
then keying a different application name such as CICS which then looks like
TSO APPLID(CICS)
TN3270 or VTAM will attempt to start a session with CICS.
> If the application is not defined in the USS Table of VTAM then you cannot
access it.
The above means that this isn't true - as Ed Gould mentioned. I remember
some colleagues of mine - including VTAM developers - thinking this might be
a "security" option but then, since the default session-level USS table,
ISTINCDT, is always logically concatenated after any customised USS table -
just like the default mode table, ISTINCLM, is always concatenated after any
customised mode table - they realised you cannot escape the LOGON APPLID()
LOGMODE()DATA() command being at the beck and call of the end user - or
more importantly - and this is why it's designed this way - any IBM service
representative.
> The COMMUNICATION SERVER manuals (VTAM or SNA) will provide much
more details on this process.
I gave you the specific URLs for V1R12. I think Lizette Kohler may have
intended to say "(IP or SNA)" - but I can't be sure. VTAM is Communications
Server SNA.
> Others will correct me if I am incorrect.
Touching faith I hope fully vindicated!
-
From Hal Merritt:
> ... Unformatted Screen Services (I think) ...
Now you see why I said there really was a need for greater awareness of this
function. This is the second time this misinterpretation has been offered
recently:
http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind1105&L=ibm-
main&T=0&F=&S=&P=5065
> It is a BAL program using macros supplied with the VTAM product.
You were closer with the "table":
> This is called the 'USS Table' ...
It is a pair of parameter tables - and a translate table.
One table is for the purposes of analysing commands with the objective to
supply minimally a primary LU name (an application name), and optionally a
mode name. There is also a data field but it's unusual to supply any default
value in the USS table.
The other table is to supply messages for various circumstances:
- one being initially to let you know that the configuration was "open for
business", the USS message 10
- others to let you know what a ham-fisted user of the keyboard you were in
not being able to provide suitable data elements,a number of other USS
messages
- one to let you know that, although the manner in which you specified the
data elements was acceptable, the session setup failed, USS message 7
- others such as the response to the IBMTEST command
You do not actually create a program. The standard programming logic uses
the table as parameters.
> The program source could be anywhere; ask your VTAM guy if you have one
or general sysprog if you don't.
I already mentioned the systems programmer with whom I was working had
initially forgotten where the source was and had to go hunting around for it. I
think there's some handy ISPF tool you can set going before you go off to
lunch.
It's just as well we found it since he took "early retirement" - and can now
support his soccer team at away matches - and they need all the support
they can get! - and his supposed replacement would have had even less of an
idea where to look!
> The executable can reside in a number of different system load libraries.
Again, ask your VTAM person or sysprog.
As I mentioned before, since the load module - not an "executable" -
necessarily needs to be available to the relevant programming, TN3270 server
or VTAM, that limits the places you need to go looking.
> There is usually one for each type of hardware terminal supported.
This is a somewhat open statement! A full discussion would probably be too
deep for the current context. If your curiosity extends to the full story of
USS/FSS, please post again and I can pull together my lecture notes into a
form which would not be dependent on the formatting program.
Since we are probably talking here about 3270 access to TSO - and - access
through the CS IP TN3270 server, we need only concern ourselves with the
3270 data stream - and, just possibly, with the SNA character stream format -
although that, in comparison with the 3270 data stream, is very limited.
> It is a table, ...
So it's not an executable then!
> ...as it is most often used to take arbitrary entries ...
Which I think, by "arbitrary entries" means tokens used to represent
applications which operate as I indicated earlier. The tokens can be exactly
the same as the application names or then can be used-friendly versions of a
name which only a systems programmer could love.
I'm not sure I follow the "most often" since there is no other purpose for at
least the USS LOGON commands.[2]
> ... and execute the VTAM commands necessary to invoke an application.
In one sense this is correct but it needs a little clarification. Again, the "VTAM
commands" mentioned here are nothing to do with what you find in the CS
SNA Operations manual.
When a TN3270 server program is processing the USS command, the TN3270
server program analyses the command in its unformatted form in order to
extract the elements necessary to put in control blocks for use with a call
over the VTAM API which further requests VTAM to initiate the SNA session
using SNA "commands", formally called "requests" - a bit more polite, don't you
think?!
When VTAM is processing the USS command, VTAM converts the command
from the unformatted form to the formatted form necessary for use in the SNA
request used to initiate the SNA session.
> By the way, that initial z/os screen seems to have become known as
a 'green screen'.
I can't imagine why. It's about as misleading as calling communication
controllers FEPs! The last "green screen" device with which I ever worked was
the 8775 in the early '80s. We shouldn't be imposing these antiquated
memories on new recruits - as I take you to be. A little before this date
someone tried to fob a mass of superannuated 3277s onto me all of them
demonstrating what the original concept of a "screen saver" was!
That was the "green screen " of not so blessed memory!
-
From Ed Gould:
> It really does not have to be defined in any USSMSG just an active APPLID
in the SNA network that you are attached to.
With a number of typos repaired! But one typo can't be repaired so easily!
I'm sure Ed means USSCMD, and associated USSPARMs, rather than USSMSG.
-
[1] There was a time when the very important USS message 7 needed to use
the TEXT operand if you wanted the option to insert the variables which
would describe why an attempted session setup had failed. Since I didn't want
me USS message 7 to be a feeble version of all my other USS messages, I set
to in order to exploit the possibility to string together many different types of
constant within the value field of the TEXT operand. It wasn't pretty but it
worked. Also the assembler barfed with error messages - something to do with
exceeding 255 characters - trying to claim that it hadn't done what I asked of
it but, by examining the resultant text records, it jolly well had!
[2] There are also possibly customised LOGOFF and IBMTEST commands, or,
with VM VTAM - and my systems, when I used to have them, with some
special trickery involving the real "executable" element of the INTERPRET
table - an UNDIAL command.
-
Chris Mason
Chris Mason
This looks like a template for people who might want to tackle actually building
USS commands and USS messages. As it stands, as far as USS messages are
concerned, it is worse than useless since it is misleading.
There are examples of USSMSG macros with the TEXT operand specified.
There are data areas defined which beg to be named in an USSMSG with the
BUFFER operand but this is mutually exclusive with the TEXT operand.
> A picture is worth a thousand words.
But it's better when they don't lie!
I tried to see if any help was available but, back at the "home page" I
discovered - and I'm doing this without references so German-speakers please
forgive me - wenn man Deutsch spricht dann geht es weiter!
Chris Mason
On Tue, 10 May 2011 11:23:47 -0400, Don Poitras <sas...@SAS.COM> wrote:
>A picture is worth a thousand words. Scroll down to MSG10S:
>
>http://www.sssgmbh.de/download/zos/sysp.usersrc/ussrole
>
>To decode the 3270 bits, look here:
>
>http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/CN7P4000/CCONTENTS
>
>--
>Don Poitras - zSeries R & D - SAS Institute Inc. - SAS Campus Drive
>mailto:sas...@sas.com (919)531-5637 Fax:677-4444 Cary, NC 27513
----------------------------------------------------------------------
Chris Mason
Shall we all ensure that we are singing from the same hymn-sheet on this one?
>> If you want your user to use CICSAPP1 as the logon to CPRD001 (CICS
System Name), then I think you need to code it in the USS Table pointing to
that Applid.
>> Is that correct?
> Yes; "normally" in the USSCMD table.
Yes, *if* you are talking about the ability for an application to have the LU
name XXX but you want the end user to be able to key YYY as the USS
LOGON command.
>...> If the application is not defined in the USS Table of VTAM then you
cannot access it.
No, if you mean that the *only* way to be able to access application with LU
name XXX is to have an USSCMD entry containing APPLID(XXX).
What Lindy Mayfield does indicates that customised USS commands, while
desirable, are not vital.
Lindy Mayfield appears not to have a customised USS table - the usual
indication is no message 10 since I can't imagine anyone taking the trouble
actually to set up a customised USS table without slipping in a handy message
10 - so she is, as it happens or necessarily, using the default ISTINCDT table.
With the aid of the LOGON command found in this always available table, any
suitable LU capable of being a primary LU in the SNA network of
conglomeration of SNA networks is, given that the systems programmers have
permitted it, available for attempting to initiate a session.
The only benefit of customised LOGON commands is to be user-friendly - but,
of course, it's not quite so friendly when you confuse them by, say, using TSO
as the LOGON command and then specifying, say, APPLID(CICS) - which is
about as bad as my drumming into students what echoplexing with
asynchronous ASCII devices was by having them enter the X.3 command to
turn it off! Soundproofing and solid walls for the students' laboratory a must!
Chris Mason
Chris Mason
It's possible that Hal Merritt has been bemused by one of the values of the
FORMAT operand of the USSCMD macro, namely BAL.
The purpose of this specification - the alternative is PL1 - is to define the
syntax of the USS command for the benefit of the logic which is to analyse
the command. The BAL format involves equal signs while the PL1 format
involves brackets. Both involve commas for the positional parameters but the
PL1 format insists on yet another pair of brackets.
In terms of being user-friendly, BAL wins by comfortable margin.
Chris Mason
On Tue, 10 May 2011 14:58:35 -0400, Gerhard Postpischil
<ger...@VALLEY.NET> wrote:
>On 5/10/2011 9:41 AM, Hal Merritt wrote:
>> This is called the 'USS Table' or Unformatted Screen Services
>> (I think). It is a BAL program using macros supplied with the
>> VTAM product.
>
><pedantry> I'm not even sure it is possible to get a copy of the
>Basic Assembler anymore, although somebody in the Hercules
>groups might have a copy. And if you did, modern macros may not
>assemble correctly under it. </pedantry>
>
>So please don't use BAL unless you mean it.
>
>Gerhard Postpischil
>Bradford, VT
Dale Miller
"So please don't use BAL unless you mean it."
sentence should have read:"So please don't use 'BAL' unless you mean
it."
</pedantry>
Dale Miller
dalel...@comcast.net
Gerhard Postpischil
> I
> think the sentence should have read:"So please don't use 'BAL'
> unless you mean it."
I won't tell you what to think if you won't try to tell me. <g>
I wrote the sentence as is, because I meant to imply that
neither the outdated acronym nor the primitive language should
be used. Unless you have a 360/30 or smaller machine in working
order, BAL is just an exercise in masochism!
Gerhard Postpischil
Bradford, VT
Jeff Holst
wrote:
>Lizette:
>
>Close...
>
>You can actually logon on to *ANY* application in the world that is hooked
up to
>you network.
>logon applid(cicsbombay)
>Will take you to *WHERE EVER* ythe applid is running in the attached
network.
>IT really does not have to be defimes in any USSMSG just an active APPLID
in the
>SNA network that you are attached to.
>
>Ed
>
>
And just to further confuse things, there is an option that tells VTAM to
expect the LOGON command in the format:
LOGON APPLID=cicsbombay
and if this is set, it will not accept the option with the applid within
parenthesis.
Don Poitras
screen source is and what "VTAM" commands it would need to produce it. I
think showing a sample of the source is exactly what he wanted. I
uploaded the sample and there are no assembler errors. I'm especially
pleased that some of the parms say FORMAT=BAL. :)
Mark Zelden
>And just to further confuse things, there is an option that tells VTAM to
>expect the LOGON command in the format:
>LOGON APPLID=cicsbombay
>
>and if this is set, it will not accept the option with the applid within
>parenthesis.
>
Yes,
FORMAT=BAL vs FORMAT=PL1 in the USSCMD macro.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:ma...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Ed Gould
Wayne Bickerdike
Most people throw away object after link edit because *LOAD* is what
is executed.
Don't want to confuse this guy any more than he no doubt is by now...
--
Wayne V. Bickerdike
Chris Mason
> ..., there is an option that tells VTAM to expect the LOGON command in the
format:
> LOGON APPLID=cicsbombay
This is probably not generally a good idea - but it is unfortunately shown in
the example offered by Don Poitras.
<quote>
LOGON USSCMD CMD=LOGON,FORMAT=BAL
USSPARM PARM=P1,REP=DATA
USSPARM PARM=APPLID,DEFAULT=TSO
USSPARM PARM=LOGMODE
</quote>
The reason it's not a good idea is that the IBM service representative should
be able to rely on the IBM-supplied tables in order to try to assist when
resolving problems. That goes equally for ISTINCLM although there was only a
relatively short period in the early life of Type 2.1 node support in VTAM
where it made technical sense to *have* to modify ISTINCLM.
> ... and if this is set, it will not accept the option with the applid within
parenthesis.
As I mentioned before, in effect, your customised USS table load module is
consulted first and then the USS load module supplied by VTAM, ISTINCDT -
or only ISTINCDT if you have not specified an USS table name as the value of
the USSTAB operand of the relevant LU or LOCAL statement - as applies to
Lindy Mayfield's definition. But if you provide an identical command in the
customized table to one in the ISTINCDT table, LOGON in this case, the
command in the customised table is obviously going to be used.
Chris Mason
On Wed, 11 May 2011 08:23:43 -0500, Jeff Holst <jeff....@FISERV.COM>
wrote:
>On Tue, 10 May 2011 08:23:33 -0700, Ed Gould <ps2...@YAHOO.COM>
>wrote:
>
>>Lizette:
>>
>>Close...
>>
>>You can actually logon on to *ANY* application in the world that is hooked
>up to
>>you network.
>>logon applid(cicsbombay)
>>Will take you to *WHERE EVER* ythe applid is running in the attached
>network.
>>IT really does not have to be defimes in any USSMSG just an active APPLID
>in the
>>SNA network that you are attached to.
>>
>>Ed
>>
>>
>And just to further confuse things, there is an option that tells VTAM to
>expect the LOGON command in the format:
>LOGON APPLID=cicsbombay
>
>and if this is set, it will not accept the option with the applid within
>parenthesis.
----------------------------------------------------------------------
Chris Mason
> I guess I'm missing your point.
Half-way though explaining what was wrong with the USSMSG macros in this
example, in looking more closely for an example in order to illustrate what I
wanted to say, I discovered the enormity:
- There is no place in an USS table to be used as an example for a novice
systems programmer for an ORG statement.
- There is no place in an USS table to be used as an example for a reasonably
experienced systems programmer for an ORG statement.
- There used to be a place for an ORG statement in an USS table when special
tricks were needed - and it was a test/education system like mine where
experimentation was acceptable. That has not been the case since the USS
message 7 variables were eligible to be placed in the data stream referenced
by the BUFFER operand, an enhancement which I tested for the benefit of the
VTAM developer responsible.
> I think showing a sample of the source is exactly what he wanted.
I'm afraid the above knocks a stagecoach and horses pursued by red indians
through this assertion.
-
The USS command examples are helpful, the USS message examples are most
unhelpful. This is the point I wanted to make before, I just hadn't spotted the
right reason for saying it was wrong!
Going back to the beginning I'll recover some of the text I wrote before the
thunderbolt struck.
-
The commands, the USSCMD macro and associated USSPARM macros in each
case, will work.
- If you key LOGON IBMUSER, you stand a chance of logging onto TSO, as
also an LU name, and your userid will be initialised as IBMUSER.
- If you key L IBMUSER, again you stand a chance of logging onto TSO, as
also an LU name, and your userid will be initialised as IBMUSER.
- If you key TEST APPLID=TSO,DATA=IBMUSER, yet again you stand a chance
of logging onto TSO, as also an LU name, and your userid will be initialised as
IBMUSER.
Indeed note the equal signs, the mark of the BAL option, and the absence of
brackets even around the positional parameter in the first two cases, also the
mark of the BAL option.
These might be handy examples to follow in producing user-friendly USSCMD-
based sets for other applications.
-
The USSMSG examples may work - in contrast to what I suspected before but
they are still enormously misleading.
In the very early days of Unformatted System Services, there was no BUFFER
option. These examples look as if they date from those days - sometime in the
late 1970s if I remember correctly. Actually I see an USS message 10 which I
thought came out after the BUFFER option was introduced or maybe at the
same time. It seems the programmer responsible for this was so chuffed with
his - thoroughly designed to confuse - *ORG* statements that he kept this
structure even after the availability of the BUFFER (used in place of the TEXT)
option.
> The OP wanted to know where the logon screen source is and what "VTAM"
commands it would need to produce it.
An example for a beginner who wants to know how it all works? The other one
has got Big Ben attached!!!
> I uploaded the sample and there are no assembler errors.
Most of the Assembler programs I have ever written - and tables created from
assembler macros - have had a clean assembly the first time but that was no
guarantee that WAC corresponded to WAD.
Actually, I rather think this will do the job but that's no excuse whatsoever to
fob totally unnecessary ORG statements onto a beginner when there is a much
more user-friendly alternative, the BUFFER option, which works almost
identically to what is shown but without the <expletive deleted> ORG
statements, of which, of course, every systems programmer has an intimate
understanding!
Just to show that this is not quite 100% bad, you *do* get a "service" from
the use of the TEXT operand which is missing in the case of the BUFFER
operand. The TEXT operand will cause VTAM to set up the "Erase/Write"
command character as the first character of the data stream, a "Write Control
Character"[1] as the second character and an input field will be defined then
or at the end - I can't remember - so that all you need concern yourself with
is the text - not easily full 3270 data stream - that you wish to present. When
you use the BUFFER option all these extra 3270 data stream requirements are
for you to set up.
The fancy trick used here - and I wonder where else - any takers in IBM-
MAIN? - as it were gets the "services" of the TEXT option with the benefits of
the BUFFER option - while paying the price of needing to understand what IBM
would legitimately claim was an undocumented interface, which all sensible
and responsible systems programmers who want to keep drawing a pay check
are encouraged to eschew.
Have I made my point?
I knew at first glance there was something wrong with those USSMSG
examples, I just hadn't spotted precisely what it was.
-
[1] When you rely on the TEXT operand to set up the 3270 "Write Control
Character", there's a bit set which depends on whether SSCPFM=USS3270 or
SSCPFM=USS3275 is specified - and the effect is counterintuitive! If your
3270 emulator is set up to have a printer function associated with the
emulator instance and SSCPFM=USS3270 is specified, each USS message is
conveniently sent to the printer function. Not everybody appreciates having
this "service". If it is to be avoided, the easiest remedy is simply to specify
SSCPFM=USS3275. QED!
-
Chris Mason
On Wed, 11 May 2011 09:31:16 -0400, Don Poitras <sas...@SAS.COM>
wrote:
>I guess I'm missing your point. The OP wanted to know where the logon
----------------------------------------------------------------------
Chris Mason
> from my POV it's not productive
I suggest you lay off all non-alphabetic symbols. Now I see where these
strange sequences come from. Of course, I don't know how the stuff after "...
POV it" and before "s not ..." is that's going to appear back to you!
And does your iPad try to second-guess what you want by creating upper
case letters and maybe adding a full stop when you are too (that's 2 "o"s)
slow?
>...> ... quit using it unless I have to ...
"smells" of compulsion, something your "suits" foisted on you.
You could try doing what I did when they tried to foist a PC on me in place of
my quite serviceable Infowhatever so-called "dumb" terminal. I said I'd be
delighted to use a PC when the keyboard could be set up to do all of the
keyboard actions I was very used to doing and was very quick with in the
process of editing files within ISPF - I lost!
-
I hope I answered the equal sign versus brackets matter in the posts to
Gerhard and Don.
Chris Mason
On Wed, 11 May 2011 10:01:02 -0700, Ed Gould <ps2...@YAHOO.COM>
wrote:
> Interesting point, frankly I have never seen a place that changed it to use
equal sign. frankly that smells customization (debatable I guess). During
instalation that takes extra time and with. The install cycle being either once
or twice a year, it takes to much time and from my POV it's not
productive and no real benefit.
----------------------------------------------------------------------
Chris Mason
Be so kind as to read all the posts in a thread before jumping in with a not
very kindly expressed comment - however much it may contain a correct
observation.
Lizette Kohler referred to *load* modules and I appreciated that, in my
concern to emphasise that these modules were *not* source modules which
was probably what the Quasar Chunawala expected, I had specified the wrong
favour of non-source module. That error was extremely quickly corrected at
Tue 17:29 -5 with your "correction" at Thu 6:12 +10. If you know how these
time-stamps work - I don't! - you will probably end up with about a day's
delay. That to me means you should certainly have been able to pick up my
correction of "object" to "load" long, long ago!
But it shows how you need to keep on your toes in this febrile environment!
P.S. I'm sorry if you have posted an apologetic retraction in the meantime!
Chris Mason
On Thu, 12 May 2011 06:12:56 +1000, Wayne Bickerdike
<way...@GMAIL.COM> wrote:
>Since when has *object* been stored in libraries generally found in STEPLIB?
>
>Most people throw away object after link edit because *LOAD* is what
>is executed.
>
>Don't want to confuse this guy any more than he no doubt is by now...
----------------------------------------------------------------------
Wayne Bickerdike
You didn't fully contradict that object modules have no place in STEPLIB.
Feel free to bluster on...
--
Wayne V. Bickerdike
Chris Mason
more correctly, I should have said "load", since the module has passed through
the linkage editor.
Since when has it been so difficult to understand such a clear sentence?
Feel free to explain what aspect of the sentence causes you problems with
understanding.
If my previous references to "object" modules are to be understood as
references to "load" modules, in what sense I am to be considered advocating
that "object" modules should be put into a partitioned data set referenced by
DD-name STEPLIB?
These are not rhetorical questions. If you feel you have any useful
contribution to make, you should answer them. Otherwise much advice has
been offered recently over the appropriate action to take which I expect you
do not need repeated.
-
Oh, I see I must offer an apology to everyone, when I wrote "favour" before,
it should have been "flavour". I hope that didn't upset anyone's understanding
too much! It's one of those cases where a mere spell-checker doesn't hack it!
Chris Mason
On Thu, 12 May 2011 07:38:50 +1000, Wayne Bickerdike
<way...@GMAIL.COM> wrote:
>I'm reinforcing the point for the benefit of all concerned.
>
>You didn't fully contradict that object modules have no place in STEPLIB.
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 10:01 AM, Ed Gould <ps2...@YAHOO.COM> said:
> Interesting point, frankly I have never seen a place that changed it
>to use equal sign. frankly that smells customization (debatable I
>guess).
Changed? The macro invocations are whatever the installation codes. If
they never coded it any other way then they didn't change it.
--
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)
Shmuel Metz , Seymour J.
<1910AEA19CD2554FB5940...@MMOEXCHMBS01.jhacorp.com>,
on 05/10/2011
at 02:29 PM, Hal Merritt <HMer...@JACKHENRY.COM> said:
>Basic Assembly Language.
As Gerhard wrote, BAL is well and truly out of support. It was part of
BPS/360 and doesn't run on any current hardware. Further, it doesn't
support macros.
>We used to call it ALC (Assembly Language Code).
That's not the same as BAL. The name "ALC" is generic, but I wouldn't
try using any assembler but HLA[1] for USS macros in z/OS.
>I last used ASMA90 in 2004.
That's HLA, the current z/OS assembler.
[1] Or HLA clones.
--
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)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 09:32 AM, Lizette Koehler <star...@MINDSPRING.COM> said:
>Once the terminal emulator is install, you need to specify an IP
>address to the mainframe system.
No. What you specify depends on how you are connected.
Also, for a TN3270 client connecting to the TN3270 component of CS,
there is a separate set of definitions similar to the USSTAB.
Shmuel Metz , Seymour J.
at 08:32 AM, Quasar Chunawala <quasar.c...@GMAIL.COM> said:
>I am a COBOL Programmer. Just out of curiosity, I would like to know,
>how Mainframe Startup Screens(the first screen that you see, when you
>connect to a Mainframe Server, and where you would type TSO) are
>written.
There really is no such thing as a "Mainframe Startup Screen". What
you see depends on how VTAM and the VTAM applications are configured.
Some of the possibilities are:
Session monitor, e.g., TPX, logon. You typically see that when your
terminal is defined as having the terminal monitor as a default
application.
Unformatted System Services (USS) prompt. You typically see that for a
3270 that has no default application.
TN3270 prompt. You typically see that for a TN3270 client on a PC with
no default application. The definitions for this are very similar to
those for USS but are in a different library.
Mike Schwab
<shmuel+...@patriot.net> wrote:
> In <BANLkTimnnfDeua8W...@mail.gmail.com>, on 05/10/2011
> at 08:32 AM, Quasar Chunawala <quasar.c...@GMAIL.COM> said:
>
>>I am a COBOL Programmer. Just out of curiosity, I would like to know,
>>how Mainframe Startup Screens(the first screen that you see, when you
>>connect to a Mainframe Server, and where you would type TSO) are
>>written.
>
You might give the Hercules Tur(n)key 3 CD-Rom a try at home. Yeah,
its the 1983 24 bit operating system, but it can give you a taste of
what system administrators do.
http://en.wikipedia.org/wiki/Hercules_(emulator)
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?