Manuals on modifying VTAM logon screen?

[Johnny Luo]

Hi,
I want to do some little modification to my test system's
default logon screen.I mean no big change,for example,
the default screen displays 'Z/OS' in red color and I want
to diplay 'Johnny's test Z/OS' in green.Just something like
this.

I know the steps to do it,however,when modifying the source,
I found it's written in assembler and I don't know its syntax.

So I begin to search IBM's manuals and find some SNA manuals
relevant.The bad thing is ,they contain many advance things about
VTAM and I didn't find exactly what I need.

Can anyone give me some suggestions?You know,what I want to do is
simple,just adding or deleting some messages diplayed on logon screen,
nothing else.

--
Best Regards,
Johnny Luo

----------------------------------------------------------------------
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

[Chris Mason]

Johnny,

I have sent you directly some presentation notes on the topic of USS tables.

By "logon screen" I assume you mean the USS 10 message which is sent as a
data stream to an LU immediately following the response to ACTLU if the LU
(or LOCAL) statement specifies a USS table in the USSTAB operand (and the
SSCPFM operand specifies something other than FSS or the statement is a
LOCAL statement).

Be aware that the ability to enter the LOGON command - or a customized
equivalent - is not restricted to when the USS 10 message is presented but
applies whenever any USS message is presented. Thus, ideally any short
advice you offer should appear on each USS message including the comment on
why the error USS message was presented for USS messages other than the USS
10 message.

Since you are talking about setting colours you are clearly talking about
the data stream used in USS tables associated with SSCPFM=USS3270 (or for a
LOCAL statement) rather than SSCPFM=USSSCS. Here the complication is
understanding 3270 data streams probably rather more than understanding
assembler language format.

The manual you need for this is the 3270 Data Stream Programmer's Reference,
GA23-0059-07, and has the Contents page
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/cn7p4000/CCONTENTS

If you ignore - for the moment anyhow - anything to do with "structured
fields" and "partitions" you will more quickly get through the manual and
understand how the current data stream you have works and how to modify it.

Please post again if you need any more help.

---

On resending the above because of the irritating inability of the software
supporting the group to remove the stuff at the end of a post, I can cover
the point you raised in your "Thank you" note, for which thanks.

The "DC" ("declare constant" if my memory serves me well) used in an USS
table is exactly the same as is used in an assembler program. The simple
reason is that the USS tables is, in truth, assembler programming. The USS
table is constructed from assembler macros and requires to be processed
using the assembler (compiler) in order to create object code which VTAM can
use.

Chris Mason

[Efinn...@ibm-main.lst]

In a message dated 1/7/2006 9:11:10 A.M. Central Standard Time,
chris...@BELGACOM.NET writes:

By "logon screen" I assume you mean the USS 10 message which is sent as a
data stream to an LU immediately following the response to ACTLU if the LU
(or LOCAL) statement specifies a USS table in the USSTAB operand (and the
SSCPFM operand specifies something other than FSS or the statement is a
LOCAL statement).

>>
You'd think if we(technofiles) can build methanol powered Laptops(Panasonic
fuel cell) we could come up with a GUI interface to build VTAM screens.

[Johnny Luo]

Chris,I tried to do some modification carefully and it now works.
It's a good beginning though I only changed the display contents
of logon screen,no color,no hilight,no other functions.

There are two questions here.

1,I checked VTAM procedure in JES2 proclib ADCD.ZOSV14S.PROCLIB(You know,
the sytem which I use for test is in fact an ADCD ZOS on lap) and found its
VTAMLIB concatenation like this: user.vtamlib
adcd.zosv14s.vtamlib
sys1.vtamlib
The user.vtamlib is empty and USSN module is in ADCD.ZOSV14S.VTAMLIB.
My plan is to place my own module in JOHNNY.VTAMLIB which resides on
a different volume and then add my own lib to the top of VTAMLIB
concatenation.
So if VTAM failed during IPL,I can vary the volume which JOHNNY.VTAMLIB
resides on offline and then restart VTAM.

Then I placed USSTAB source I modified in JOHNNY.VTAM.SOURCE and
the destination load module in JOHNNY.VTAMLIB.I modified the JCL and
submitted it to compile and link.

But the job failed. The system says it's waiting for data sets.I checked the

log and got the message:

*IEF861I* *FOLLOWING* *RESERVED* *DATA* *SET* *NAMES* UNAVAILABLE TO
IBMUSERA
DSN=JOHNNY.VTAM.SOURCE
DSN=JOHNNY.VTAMLIB
It's strange.No other users or jobs are using these two data sets,why
they're
unvailable to my job?

2,So I canceled my modification to JCL and resubmitted it.This time there is
no problem.However,after re-IPL,the new logon sreen only works when you
connect to it using port 3270.On the other side,if you use TCPIP port 23,
the logon screen is still the old one.Why does this happen?

[Terry Sambrooks]

Hi,

Johnny Luo wrote:

"The user.vtamlib is empty and USSN module is in ADCD.ZOSV14S.VTAMLIB. My plan is to place my own module in JOHNNY.VTAMLIB which resides on a different volume and then add my own lib to the top of VTAMLIB concatenation......

,,,,,However,after re-IPL,the new logon sreen only works when you connect to it using port 3270.On the other side,if you use TCPIP port 23, the logon screen is still the old one.Why does this happen?"

My own system is down at present so I cannot say why the problem being experienced is happening, but having undertaken a similar change then I may be able to offer a solution.

The library USER.VTAMLIB has been provide as a repository for this precise situation. (The are other USER. libraries in the ADCD collection to allow other modification, i.e. own TSO Exits, own CLISTs/REXX etc, where own means installation not personal.) The only difference in approach between our two methods is that I created a USER.ZOSV1R3.VTAMLST, and subsequently a USER.Z16.VTAMLST to hold the source code and provide consistent naming. Assembling and linking the USSN into
USER.VTAMLIB means that the modified USSN appears for both VTAM and TCPIP access, i.e. whether the Telnet Listener or TCP/IP Port 23 is used.

As an asside If there are going to be a number of users accessing the system, use TCPIP as the primary entry. If you drop into VTAM via the Telnet Listener which connects as a local VTAM terminal it generates activity at the Linux level and this can induce poor performance if Linux and z/OS compete on paging activity.

Kind regards - Terry

Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
South Yorkshire
UK

Tel +44 (0) 114 262 0933
Web www.kmsitltd.co.uk

Reg: England & Wales 3767263 at the above address

All outgoing E-mails are scanned but it remains the responsibility of the recipient to ensure that their system is protected from infection by virus, Trojans, and worms.

[Johnny Luo]

Terry,thanks for the reply.

1,'The only difference in approach between our two methods is that I created

a USER.ZOSV1R3.VTAMLST, and subsequently a USER.Z16.VTAMLST to hold the

source code and provide consistent naming'

Weird....Maybe it's the HLQ that makes the difference?
I checked a book 'MVS System Programming'.It's old but concerning
VTAMLIB,it says
that all library must be 'APF authorized'.As for 'APF',I wonder what on
earth it is and what's
the relationship between APF and RACF.
Anyway,my guess is that HLQ is relevant on this issue for the 'USER' HLQ
is shipped with
the system and it's the only difference between 'user.**' and
'johnny.**'.However,I dont know
the real reason underlying.

2,'Assembling and linking the USSN into

USER.VTAMLIB means that the modified USSN appears for both VTAM and TCPIP

access'

USSN module must be in USER.VTAMLIB?You know,if you don't do any change,
USER.VTAMLIB
is empty and the sytem finds the module in ADCD.ZOSV14S.VTAMLIB.However,at
that time,
the logon screen seems to be the same for for both VTAM and TCPIP access
too.

--
Best Regards,
Johnny Luo

----------------------------------------------------------------------

[Chris Mason]

Johnny,

By saying you have had some success, do you mean that you changed the source
of USSN (in whichever library that is located), assembled and linkage edited
this source into a USSN load module in ADCD.ZOSV14S.VTAMLIB replacing the
existing USSN load module?

Note that the source library has significance only for the assembler step
and is of no interest whatsoever to the VTAM procedure.

Now we have three more problems:

1. How to modify a JCL procedure

The fact that a library (partitioned data set) in a procedure resides on a
different volume is of no interest to a procedure just so long as the
library is either cataloged or the DD-statement includes a reference to the
volume.

In the days when I played with MVS (what z/OS used to be called) JCL, your
strategy of varying the volume with your JOHNNY.VTAMLIB offline would not
have worked, the procedure would have failed and maybe would have created
that IEF861I message.

I assume removing the modification to JCL applies to the VTAM procedure.

2. How to run an assembler/linkage edit job.

We can't really help a great deal here. It's all about how you run your
system which I am having to guess from your reference to "lap" is an
experimental system just for you on a laptop.

Fortunately you talk about setting up those data sets on a separate volume
and you even talk about varying the volume online and offline so perhaps
your volume is somehow not online when you run the assembler/linkage edit
job - just a guess.

3. How to use USS tables with CS IP TELNET 3270 as opposed to VTAM local
non-SNA 3270 display devices

I have to make a big assumption here in that port 3270 means that some sort
of supporting software in the clever system on your assumed laptop provides
the appearance of a channel-attached 3270 display device emulating - let's
get back to basics - a 3272 control unit and a 3277-2 (although I'd be
surprised if it didn't support the more advanced 3270 data stream
capabilities of a 3174-1D and the many display devices that could attach to
a 3174-1D - which is where we came in on this thread after all).

If that big assumption is correct, it means that with port 3270 we are
dealing purely with VTAM in terms of z/OS software, or more precisely these
days, purely the SNA side of CS.

If you are using port 23, you will, by default, be using TELNET. Here, if
TELNET 3270 is negotiated, the USS table operates rather differently. The
first point being that you need to place the USS load module in a library
which can be accessed by the procedure supporting the TELNET 3270 server
logic however you have that set up in your system. In principle the USS
module can be the same load module.

If you look at those notes I sent you, you'll see that the USS table load
module name - USSN in the example you have been using - must be provided on
a statement in a member of VTAMLST, probably a LOCAL statement. This is
where VTAM finds the name of a USS table module. In the case of CS IP TELNET
3270, the name of the USS table is provided in the statements relating to
TELNET - which used to have to be in the PROFILE data set but which can now
be in a data set accessed by a separate TELNET procedure I believe. When CS
IP TELNET sets up a session with CS SNA (VTAM) VTAM knows nothing about any
USS tables (in definition terms, SSCPFM=FSS is assumed for the TELNET 3270
secondary APPL statement). The TELNET 3270 server in CS IP simulates the USS
table processing purely over the TELNET 3270 TCP connection - and then only
partially but that's another sorry story.

After all this I still wonder where the 3270 emulation is coming from in the
case of both the use of port 3270 and port 23. I'm afraid that, when asking
for help, you shouldn't assume complete familiarity with what sounds like a
wonderful playpen for getting familiar with z/OS.

I further suspect that you have been sold falsely on the idea that you do
not need to understand all the tricky bits and pieces that have been
clobbered together under - I guess - the ADCD system label.

Perhaps you can supply an URL where I can read about the essentials of this
ADCD system and can perhaps disentangle the confusion they have led you
into.

I now have read Terry's contribution. It would appear that, in order to try
to avoid you actually having to understand what you are doing - always a
futile objective in my experience - this USER set of libraries has been set
up in such a way that the USER.VTAMLIB is available to both the VTAM
procedure and the procedure supporting the TELNET 3270 logic so that you can
be unaware - in principle - that you modify simultaneously both the USS
module as processed by VTAM and the USS module as processed by the TELNET
3270 server.

Chris Mason

----- Original Message -----
From: "Johnny Luo" <johnny.xi...@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-...@BAMA.UA.EDU>

[Chris Mason]

Johnny,

With regard to this reply to Terry, I can see we've got a long way from USS
tables here and are now trawling the basics of MVS-z/OS. I used to
understand these issues intimately when I ran multiple MVS systems (under
VM) for education and test purposes. Unfortunately I don't any more without
having to reread the manuals. Perhaps Terry can guide you on these MVS
issues.

I would advise that, until you are familiar with APF etc., you follow the
path the ADCD system designers want you to take and use the USER HLQ
libraries for the moment.

Back to USS issues: The USSN load module must reside in a library in the
VTAMLIB concatenation - for the purposes of CS SNA (VTAM). I believe - you
should check this - that the USSN load module must reside in a library in
the STEPLIB concatenation of the appropriate procedure, the main TCP/IP
procedure or the TELNET server procedure - for the purposes of CS IP.

Note that, in both cases, VTAM or the TELNET 3270 server, if you change the
name of the USS load module, you will need to find where the name appears in
VTAM or TELNET 3270 server definition statements and change it there also.

The USS 10 message (whet you call the "logon screen") and the rest of the
USS messages and commands are available to what you call "both VTAM and
TCPIP access", in other words, VTAM and the TELNET 3270 server, because
ADCD.ZOSV14S.VTAMLIB is both in the VTAMLIB concatenation and the STEPLIB
concatenation of the appropriate CS IP-related procedure, the main TCP/IP
procedure or the TELNET server procedure. (I guess, if the ADCD system tries
to keep things relatively simple, this will be the main TCP/IP procedure.)
Check it out.

Chris Mason

----- Original Message -----
From: "Johnny Luo" <johnny.xi...@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-...@BAMA.UA.EDU>
Sent: Sunday, 08 January, 2006 1:32 PM
Subject: Re: Manuals on modifying VTAM logon screen?

[wm0...@hotmail.com]

Hi,

I had some really good working examples that use almost every
USS function, howeve, Johnny's e-mail address came back invalid
on my send attempt.

Regards,
Wayne

[wm0...@hotmail.com]

I had some good documented samples, using almost every USS function;
however, Johnny's e-mail aggress came back invalid for me.

[Chris Mason]

Johnny,

Well, I have been doing some Googling and I now see what your - and
Terry's - system is all about. It appears that I was correct in guessing
that "port 3270" enables you to be pretending to be a local non-SNA
channel-attached 3270 display device represented in VTAM by a LOCAL
statement necessarily using a USS table with USS message text consisting of
the 3270 data stream. It seems that FLEX-ES provides a TELNET 3270 server -
what Terry calls the "Telnet Listener" - which provides the appearance of
this local non-SNA channel-attached 3270 display device to the supported
operating system, in this case z/OS.

However I still haven't been able to discover why "port 23" seems to get
straight through to the CS IP TELNET 3270 server. Given the complexity of
the environment - with more smoke and mirrors than the seediest of
nightclubs - my assumption in an earlier post that port 23 would take you
through to the CS IP TELNET 3270 server was rather rash! I haven't succeeded
in finding out how you route between the various operating system types and
instances that may be running on your laptop from the x3270 instances that
you are starting up. Is there some table where ports are defined - to be
associated for local clients with the "loopback" address, 127.0.0.1 - on the
lowest level operating system TCP/IP instance which map to the different
operating system instances, with redefined ports perhaps - a bit like
Network Address Translation? "Oh what a tangled web we weave when first we
practice to deceive."

So to answer my questions from the snip below:

1. It seems that x3270 is the TELNET 3270 client supplied in the FLEX-ES
package.

2. You needn't send me any URLs unless there is one which explains how port
23 takes you through to the CS IP TELNET 3270 server logic.

Chris Mason

----- Original Message -----
From: "Chris Mason" <chris...@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-...@BAMA.UA.EDU>
Sent: Sunday, 08 January, 2006 3:24 PM
Subject: Re: Manuals on modifying VTAM logon screen?

<begin snip>

> After all this I still wonder where the 3270 emulation is coming from in
the
> case of both the use of port 3270 and port 23. I'm afraid that, when
asking
> for help, you shouldn't assume complete familiarity with what sounds like
a
> wonderful playpen for getting familiar with z/OS.
>
> I further suspect that you have been sold falsely on the idea that you do
> not need to understand all the tricky bits and pieces that have been
> clobbered together under - I guess - the ADCD system label.
>
> Perhaps you can supply an URL where I can read about the essentials of
this
> ADCD system and can perhaps disentangle the confusion they have led you
> into.
>
> I now have read Terry's contribution. It would appear that, in order to
try
> to avoid you actually having to understand what you are doing - always a

> futile objective in my experience - ...

<end snip>

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Ed Finnell
> Sent: Saturday, January 07, 2006 10:22 AM
> To: IBM-...@BAMA.UA.EDU
> Subject: Re: Manuals on modifying VTAM logon screen?
>

> You'd think if we(technofiles) can build methanol powered

> Laptops(Panasonic
> fuel cell) we could come up with a GUI interface to build
> VTAM screens.
>

Probably could. Have you presented a Business Case? <GRIN> Or are you
just hoping some geek will decide it would be fun to do?

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

[Chris Mason]

John and Ed,

This is the text from the last page from my VTAM Miscellaneous presentation
last given 10 years ago. I haven't heard of any other uses for PC facilities
to "enhance the VTAM experience". No doubt some probably significant
customer asked for these functions, the functions were provided and - just
maybe - one or two of their younger system programmers bothered to set them
up and use them - but I could be wrong.

From my notes, the "message" function appears to have arrived with VTAM V3R4
and the "command" function with VTAM V4R3.

---

Workstation Support for VTAM
============================

VTAM Message Manual Online
--------------------------

Lookup of VTAM messages on a PS/2

by entering a keyword
by cursor positioning in a host session
for example, a NetView session

VTAM Messages and Codes manual types

messages
sense codes
return and feedback codes
etc.

Supported by EASEL OS/2 EE Runtime from V 1.1

VTAM Command Prompts
--------------------

Operands selected on a PS/2

by "clicking" on prompts
by entering names in boxes

Supported by Command Tree/2

---

Chris Mason

----- Original Message -----
From: "McKown, John" <john....@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-...@BAMA.UA.EDU>

Sent: Monday, 09 January, 2006 3:10 PM
Subject: Re: Manuals on modifying VTAM logon screen?

> > -----Original Message-----
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Ed Finnell
> > Sent: Saturday, January 07, 2006 10:22 AM
> > To: IBM-...@BAMA.UA.EDU
> > Subject: Re: Manuals on modifying VTAM logon screen?
> >
>
> > You'd think if we(technofiles) can build methanol powered
> > Laptops(Panasonic
> > fuel cell) we could come up with a GUI interface to build
> > VTAM screens.
> >
>
> Probably could. Have you presented a Business Case? <GRIN> Or are you
> just hoping some geek will decide it would be fun to do?
>
> --
> John McKown
> Senior Systems Programmer
> UICI Insurance Center
> Information Technology

----------------------------------------------------------------------

[Shmuel Metz , Seymour J.]

In <ae3908060601070420p60b...@mail.gmail.com>, on
01/07/2006

at 08:20 PM, Johnny Luo <johnny.xi...@GMAIL.COM> said:

>I want to do some little modification to my test system's default
>logon screen.

I'm not sure what you mean. Are you referring to

1. The prompt in USS?

2. A prompt from a network solicitor or session manager?

3. The TSO full screen logon panel?

I suspect that you mean USS, in which case you may need to change it
in two places. Search tor USSTAB, note the restrictions on the data
streams you can use, then read the 3270 data stream manual.

>I know the steps to do it,however,when modifying the source, I found
>it's written in assembler and I don't know its syntax.

Then you need to learn. Take an assembler class and write some sample
programs.

>Can anyone give me some suggestions?

Walk before you run. Get a sandbox system if you don't already have
one.

--
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)

[Sebastian Welton]

On Mon, 9 Jan 2006 13:59:27 +0100, Chris Mason <chris...@BELGACOM.NET> wrote:

>Well, I have been doing some Googling and I now see what your - and
>Terry's - system is all about. It appears that I was correct in guessing
>that "port 3270" enables you to be pretending to be a local non-SNA
>channel-attached 3270 display device represented in VTAM by a LOCAL
>statement necessarily using a USS table with USS message text consisting of
>the 3270 data stream. It seems that FLEX-ES provides a TELNET 3270 server -
>what Terry calls the "Telnet Listener" - which provides the appearance of
>this local non-SNA channel-attached 3270 display device to the supported
>operating system, in this case z/OS.

FLEX-ES provides something called the 'Terminal Solicitor' which gives you
access to local non-SNA terminals which are defined in the configuration
file. To use the 'Terminal Solicitor' you would telnet to port 24 of the
host operating system. x3270 is the standard 3270 emulation package which is
installed with FLEX-ES and you can connect directly to your S/390 OS from
the laptop by doing a telnet to localhost (or 127.0.0.1) which will give you
the first USSTAB in your VTAMLIB concatenation.

If however you have configured your system so that an ethernet adapter is
emulating, for example, a 3172 then you can directly telnet in to the IP
address of you S/390 OS, which would by default be port 23. Once again you
will get the first USSTAB in your VTAMLIB concatenation unless you have
created a new USSTAB for TCPIP and modified your TCPIP PROFILE to point to
this USSTAB. Exactly like 'big iron.'

If anyone is using port 3270 I suspect they are using Hercules.

Sebastian.

[Efinn...@ibm-main.lst]

In a message dated 1/9/2006 8:10:36 A.M. Central Standard Time,
john....@UICIINSCTR.COM writes:

Probably could. Have you presented a Business Case? <GRIN> Or are you
just hoping some geek will decide it would be fun to do?

>>
Guess I was impressed with the ISIS/AFP interface. Builds a WYSIWYG screen
for PAGEDEFs/FORMDEFs/OVERYLAYs on big high resolution PC then generates PPFA
or OGL for HOST.

My attempts at screen modification have been met with varying degrees of
success. It's sorta like graphical standards more politics than technology. Had
one we got that was pretty fancy with dots and slashes for highlighting looked
real sharp. One whole
department couldn't LOGON 'cause they were screen scraping and looking for
the Help Desk number in row 20/column 50 "like it's always been".

[Chris Mason]

Sebastian,

Thanks for your contribution to this rolling mystery.

Perhaps my Googling went of course by starting with ADCD. URL
http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.adcd.global.html(readme17)' led me
into thinking that the base system was FLEX-ES. I am dimly aware there are
other such platforms so perhaps ADCD also runs on a Hercules if port 3270 is
specific to Hercules. I did notice that FLEX-ES documents kept mentioning
port 24 - but it's easy enough to change ports - if the software sticks to
the "goodness" convention of always using the getservbyname() call and the
/etc/services file is modified appropriately. Perhaps the ADCD package
somehow thought that it would be cleverer to use port 3270 in order to
access the local non-SNA channel-attached 3270 emulation.

That paragraph has at least one too many "perhaps's" in it for comfort.

Now I do know about VTAM and I'm afraid you are wrong about the USS table -
or maybe just not quite precise enough. You don't get just the first USS
table. What you get is the first USS table that has the name as specified in
the - in this case - LOCAL statement in the VTAMLST member which defines the
local non-SNA channel-attached 3270 devices using the USSTAB operand.

Also if you are using the CS IP TELNET server for 3270 access you will get
the USS table specified in the TELNET parameters. This USS table has to come
from a load module partitioned data set which can be accessed by the
appropriate CS IP procedure. This may be a dataset with VTAMLIB in the name
but it is NOT the VTAMLIB concatenation by which you imply the VTAM
procedure using VTAMLIB as a DD-statement name. If you are using some TELNET
server for 3270 access where the server emulates a, say, 3174 with attached
display devices then you can get the USS tables as defined to VTAM for those
emulated LUs, probably from "switched" definitions in VTAMLST which can have
USSTAB operands along with SSCPFM=USSSCS. This cannot happen in the case of
the CS IP TELNET server since the 3270 devices are emulated by means of APPL
statements in VTAMLST which cannot have USS tables associated with them.

I wonder if you have read the rest of this thread from the beginning. Johnny
rather confused us by equating the use of port 23 and port 3270. He tells us
he changed the USS table in the VTAMLIB concatenation and saw his changes
using port 3270 but did not see that changes when using port 23 and he is
surprised by the difference:

<snip from post from Johnny Luo of Sunday, 08 January, 2006 10:38 AM>

However, after re-IPL, the new logon screen only works when you connect to
it using port 3270. On the other side, if you use TCPIP port 23, the logon

screen is still the old one. Why does this happen?

<end of snip>

In my ignorance of these wonderful platforms for running z-software on
emulated z-hardware, I assumed, faced with this perhaps accidental
disingenuity, that we were talking about the same IP address being used in
both cases. According to your information this cannot be the case.
"Loopback" is used in order to access the FLEX-ES (and, I expect, the
Hercules) TELNET 3270 server from the TELNET 3270 client - only assumed to
be x3270 from the FLEX-ES references I found - while some address associated
with the z-operating system is used to access the operating system's, in
this case z/OS CS IP, TELNET 3270 server. That's why - in the second
paragraph of my post which you did not include - I speculated over some sort
of "passthru" facility that would allow some ports to be reflected through
to the supported operating system instances supported by something like a
NAT table if port translation was required.

I'm reminded of another quotation which can so often apply to anything to do
with these "smoke and mirrors" techniques, from Alexander Pope this time
rather than Sir Walter Scott: "A little knowledge is a dang'rous thing"

Chris Mason

----- Original Message -----
From: "Sebastian Welton" <seba...@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-...@BAMA.UA.EDU>
Sent: Monday, 09 January, 2006 5:21 PM
Subject: Re: Manuals on modifying VTAM logon screen?

[Sebastian Welton]

On Mon, 9 Jan 2006 18:31:37 +0100, Chris Mason <chris...@BELGACOM.NET> wrote:

>Sebastian,
>
>Thanks for your contribution to this rolling mystery.
>
>Perhaps my Googling went of course by starting with ADCD. URL
>http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.adcd.global.html(readme17)' led me
>into thinking that the base system was FLEX-ES. I am dimly aware there are
>other such platforms so perhaps ADCD also runs on a Hercules if port 3270 is
>specific to Hercules. I did notice that FLEX-ES documents kept mentioning
>port 24 - but it's easy enough to change ports - if the software sticks to
>the "goodness" convention of always using the getservbyname() call and the
>/etc/services file is modified appropriately. Perhaps the ADCD package
>somehow thought that it would be cleverer to use port 3270 in order to
>access the local non-SNA channel-attached 3270 emulation.
>
>That paragraph has at least one too many "perhaps's" in it for comfort.
>
>Now I do know about VTAM and I'm afraid you are wrong about the USS table -
>or maybe just not quite precise enough. You don't get just the first USS
>table. What you get is the first USS table that has the name as specified in
>the - in this case - LOCAL statement in the VTAMLST member which defines the
>local non-SNA channel-attached 3270 devices using the USSTAB operand.

Chris,
I was not being precise enough as I could see that you know what
you're talking about.

I think everything has been cleared up by now on what he needs to do (now I
would just like a nice tool to create the USSTAB screens as it takes me
hours :-)

[Paul Hanrahan]

Ca realia might have a pc based tool for this.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Of Sebastian Welton
Sent: Tuesday, January 10, 2006 5:24 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: Manuals on modifying VTAM logon screen?

[Johnny Luo]

Chris,
Following your guide,I've finally created my customized
USS TABLE successfuly.Without your help,I can not imagine
how long it'll take for me to accomplish this.

1,Complie and link. I'm sorry for that because it's indeed a
'false' question raised by me.I deleted and re-created the
libraries and submitted the job with no error.

2,Just as you said,ADCD's VTAMLIB is a concatenation and on
the other side, STEPLIB in TCPIP procedure is only ADCD.ZOSV14S.VTAMLIB.
So I modified both to add my own lib JOHNNY.VTAMLIB to the
top of concatenation.

3,Both VTAMLIB and STEPLIB of TCPIP require that all libraries
must be APF authorized.After reading some IBM redbooks,I know
that APF list is controled by parmlib memebers.So I find these
members and add JOHNNY.VTAMLIB to the APF list.

I attach a pic of my new logon screen in a mail to your personal address.It's
not that good but it
works------Thank you again,Chris.

--
Best Regards,
Johnny Luo

----------------------------------------------------------------------