Last August I worked with Chris Mason on a USS table issue. A brief recap:
TCPIP provides symbol substitution in USS messages which contain system
symbols and certain defined character strings that start with two or more '@'
characters. VTAM also provides symbol substitution for defined characte
words, using a "3270 format" table can be considered as
somewhat abnormal when using TN3270E - but don't let that bother you!
-
Lastly, let's clean up your switched major node definitions.
>
TEST VBUILD TYPE=SWNET,MAXNO=1000,MAXGRP=2
PUZZ88 PU ADDR=XX,PUTYPE=2,MAXPATH=1,MAX
Martin
Great job! - thanks for all the tests. It's just about the worst case possible.
Only the upper case somewhat relieves the risk.
Even VTAM folk haven't been quite clever enough to spot the risk with the "@"
variables but the chances of an "accident" with them is very, very small with
all
>You seem to have a sandbox available to you so I would like to suggest some
>more tests.
>a. Does the VTAM implementation skip order sequences when scanning
>for "@" characters? Check with HOSTNET preceded by an SF with attribute
>byte X'7C', "protected", "autoskip" and "nondisplay" - which is
On Tue, 11 Aug 2009 10:47:37 -0500, Chris Mason
wrote:
>...
> I have seen system programmers deliberately colour their
>USS message fields without regard to whether or not the colour
>caused the field to become unprotected.
>
Guilty as charged ... almost. Not exactly "without regard to
whet
Martin
> ... but felt you should know I haven't dropped the discussion.
That's good to know!
> It's highly unlikely someone would ... but, 'highly unlikely' is just the
> type of
open pit someone eventually falls into.
Precisely. It's because of that "open pit" - 'for some value of' likely s
>You seem to have a sandbox available to you so I would like to suggest some
>more tests.
Yes, but only as time permits - I am working on those tests, but felt you
should know I haven't dropped the discussion.
>Note that there's not too much point in checking the TN3270 implementation
>with "@"-
Richard
> ... so I got a copy of the old network solicitor from someone ...
That may be *an* old network solicitor. The original IBM network solicitor was
written with "basic" mode macros rather than "record" mode macros. ("Basic"
mode was or pre-SNA devices and was dropped eons ago. NTO was a
Of John Hamman
>> Sent: Thursday, August 06, 2009 4:21 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: USSTAB
>>
>> Still use custom USS tables here in Mississippi for both VTAM
>> and TN3270 access...
>> FWIW
>>
>> John Hamman
>
>so do we her
John
Here's a set of questions you - and all other people responding positively to
Martin's question - need to answer for yourself regarding the system symbols
enhancement (the first question you have answered already):
- Do you use USS tables with your z/OS TN3270 server, that is, you use the
ed the thread did all
the list subscribers a kindness by using "USSTAB" as the "Subject" for this
long-running thread. He could have caused immense confusion by using
the "Subject" "System symbols in USS" as he would have been thoroughly
entitled (pun) so to
Martin
You seem to have a sandbox available to you so I would like to suggest some
more tests.
a. Does the VTAM implementation skip order sequences when scanning for "@"
characters? Check with HOSTNET preceded by an SF with attribute byte
X'7C', "protected", "autoskip" and "nondisplay" - which
Martin
> I have indeed opened an ETR with IBM as a low-priority problem. Progress is
as expected, slow, though I have gotten the support person to agree there
is/are issue(s).Is that "issue" as in "issue" or "issue" as in "problem". Only
when
they acknowledge the latter are we going to see som
Martin Kline wrote:
BTW, for everyone (anyone?) who bothered to read this far, how many use a
custom USS table? Is it just Chris, Patrick, myself and a couple other people in
the world?
When we had real 3270's, I used a custom table.
When we first setup TCP/IP the TN3270 server didn't support
On Fri, 7 Aug 2009 00:28:07 -0500, Barbara Nitz
wrote:
>> Fixing USS design flaws isn't going to be very high on anybody's list.
>
>But having enough complaints from different people (not just me -
>after all, we're just someone out in Europe!) may get a few of
>the 'suits' thinking, and a few
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Hamman
> Sent: Thursday, August 06, 2009 4:21 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: USSTAB
>
> Still use custom USS tables here in Mississippi for
> Fixing USS design flaws isn't going to be very high on anybody's list.
But having enough complaints from different people (not just me - after all,
we're just someone out in Europe!) may get a few of the 'suits' thinking, and a
few technicians in a position to do something about it might start
Still use custom USS tables here in Mississippi for both VTAM and TN3270
access...
FWIW
John Hamman
Senior Systems Programmer
BlueCross BlueShield of Mississippi
601.664.4410
jham...@bcbsms.com
>>> "Patrick O'Keefe" 8/6/2009 4:09:57 PM >>>
On Thu, 6 Aug 2009 14:20:53 -0500, Martin Kline
wro
On Thu, 6 Aug 2009 14:20:53 -0500, Martin Kline
wrote:
>...
>BTW, for everyone (anyone?) who bothered to read this far,
>how many use a custom USS table? Is it just Chris, Patrick,
>myself and a couple other people in the world?
>...
You already know I'm in the customized camp, but I thought
hursday, August 06, 2009 2:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: USSTAB
I appreciate the continued discussion. It's interesting banter.
I have indeed opened an ETR with IBM as a low-priority problem. Progress
is
as expected, slow, though I have gotten the support person to agree
there
i
I appreciate the continued discussion. It's interesting banter.
I have indeed opened an ETR with IBM as a low-priority problem. Progress is
as expected, slow, though I have gotten the support person to agree there
is/are issue(s).
I'm not sure how this would be a "requirement." I just want the
On Wed, 5 Aug 2009 20:07:50 -0500, Chris Mason wrote:
>...
>To someone who understands the matter - see the analysis above -
> "incompetence" is the only word that seems to fit. The appearance
>of "incompetence" may have been forced on both the designers and
>developers - in which case my abject
Pat
I'm looking at this from the point of view of an acceptable level of quality in
the implementation of a function - an acceptable level for IBM, that is. I have
deliberately stayed away from how it could be fixed because that is now very,
very difficult. That's the problem with a botched des
On Tue, 4 Aug 2009 19:03:22 -0500, Chris Mason
wrote:
>...
>Yes, the whole design is a total mess. I suggest you hit your IBM
>support with this shoddy design with as much force as you can
>muster. It's incompetence piled on incompetence, in the
>implementation *and* the description. It shows w
Yes, that would be it.
>>> Chris Mason 08/04/09 8:00 PM >>>
Scott
Is the explanation in this reference what you hoped you had correctly
recalled?:
2.3.4.3 Rules for coding IEASYMxx
Follow these rules when coding IEASYMxx:
1. Define new system symbols that are 1- through 8 characters long,
Juergen
It would have helped if you had indicated where the "quotation" ended. I can't
be sure whether your last paragraph is part of the quotation or your thoughts.
Anyhow thanks for dragging this confession out of IBM and passing it on to us
all.
Because there is (a) VTAM logic supporting te
John
> "you should know" you need a SF[E] with at least an attribute byte,
immediately following a SBA.
Who says? Simon?
This is absolutely not true. You can use SBA order sequences to scatter text
at will around the presentation space, something I have done and mostly with
USS messages. The
Martin
Having now verified that Scott Rowe was correct, there will be no overlaying
because the substituted text is too long since this is not allowed. However, I
can see that, in the event that you inadvertently use a valid system symbol
name following your second address byte or the attribute
John
> Of course, I'm "ass.u.ming" you follow the SBAs immediately with SF[E]
orders
In which case, it's the attribute one would have to worry about!
Chris Mason
On Tue, 28 Jul 2009 08:00:33 -0500, Chase, John
wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List
Scott
Is the explanation in this reference what you hoped you had correctly
recalled?:
2.3.4.3 Rules for coding IEASYMxx
Follow these rules when coding IEASYMxx:
1. Define new system symbols that are 1- through 8 characters long,
excluding the required ampersand and the optional period. For
Martin
Thanks to you we now know that, when the substituted text has fewer
characters than the system symbol, the length of the text string is reduced
and there is no substitution with blanks, for example. This is in sharp
contrast
to the variables defined with the aid of the "@" character whe
hello everybody,
thank you also for the responses. My fault was, that I only looked in the
VTAM-books as done for years. So I didn't find/knew the new functions in IP.
But .. I opened a question at service-link about this and this is the answer:
Even though both TN3270 and VTAM SNA are using the s
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Martin Kline
>
> "Strange and wonderful" was a good guess. The code which scans the
buffer
> does not check for 3270 orders, and may simply overlay them. Aparable?
Since
> the description reads, "The entire string spec
"Strange and wonderful" was a good guess. The code which scans the buffer
does not check for 3270 orders, and may simply overlay them. Aparable? Since
the description reads, "The entire string specified by BUFFER is searched,
using the character @," I suppose this depends on how you want to inte
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Martin Kline
>
> My test showed system symbols were replaced by removing or adding
> characters as necessary. (Because I can't remember exactly how to get
> ampersands to diplay correctly on the list server and I'm too
IIRC, system symbol values CAN NOT be longer than the name of the symbol
(including the ampersand).
>>> Martin Kline 7/27/2009 2:58 PM >>>
My test showed system symbols were replaced by removing or adding
characters as necessary. (Because I can't remember exactly how to get
ampersands to dipla
My test showed system symbols were replaced by removing or adding
characters as necessary. (Because I can't remember exactly how to get
ampersands to diplay correctly on the list server and I'm too lazy to look it
up,
my examples will use pound signs, '#', instead).
For example '---#SYSNAME--
thanks Chris will do some testing ... let ya know what I find out..
From:
Chris Mason
To:
IBM-MAIN@bama.ua.edu
Date:
07/27/2009 11:29 AM
Subject:
Re: USSTAB
Sent by:
IBM Mainframe Discussion List
Ron
The summary:
VTAM USS does *not* support MVS system symbols
The TN3270 server
0500, Ron Wells
wrote:
>from what I gather some synbols not support---vtam vs tcpip..
>is there or has some tested which apply..?
>at this point only interested in tcpip/tn3270 and have the smfid of the
>system being displayed..
>
>
>
>From:
>Martin Kline
>To:
>IBM
from what I gather some synbols not support---vtam vs tcpip..
is there or has some tested which apply..?
at this point only interested in tcpip/tn3270 and have the smfid of the
system being displayed..
From:
Martin Kline
To:
IBM-MAIN@bama.ua.edu
Date:
07/24/2009 07:58 AM
Subject:
Re: USSTAB
t of USS macros and they some from a VTAM
>>distribution library, SISTMAC1.
>>
>>> The IP reference, however, also indicates that you can use system
>>>symbols, whereas the SNA reference does not.
>>...
>
>It's important to remember that even though the
the SNA reference does not.
>...
It's important to remember that even though the same USStab load
module can the used by both VTAM and the Tn3270 server, different
code processes the table. VTAM development could have have put
support in the macros for functions supported only by the Tn3270
Juergen
As I said in my last reply to Marin, it's garbled. The manual authors have let
themselves and us all down yet again!
The relevant description would be better written as the following
LUNAME|SCAN
Specifies that the entire string specified by BUFFER is searched using the
characters @
Chris said:
>This question of which version of the USS table also occurred to me after my
>last post. I would assume the one used by the Communications Server IP
>component TN3270 server program in both Ron's case and Juergen's.
>However, when Communications Server development change the USS tab
Juergen asked:
>I've looked through the IP-Reference (1.8 - SC31-8776-10) and did not find
>any entry that you can use system symbols in USSMSG. There are some
>varables starting with @ but no system-symbols. Is it a function in 1.9 or
>1.10?
I am using the 1.9 manual. SC31-8776-13 Section 2.10
Martin
Note that there is only one set of USS macros and they some from a VTAM
distribution library, SISTMAC1.
> The IP reference, however, also indicates that you can use system symbols,
whereas the SNA reference does not.
Interesting!
>From the explanation of the SCAN (alternately and origi
Thank you for underlining this, Martin !
That exactly was the reason asking Ron about VTAM- or TN3270-USSTAB usage.
ciao Lutz
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists
Martin,
I've looked through the IP-Reference (1.8 - SC31-8776-10) and did not find
any entry that you can use system symbols in USSMSG. There are some
varables starting with @ but no system-symbols. Is it a function in 1.9 or 1.10?
Juergen
---
ease of z/OS. The availability of system
symbols in USSTAB processing appears to have changed between z/OS 1.7
and z/OS 1.9. The manuals I used above are both for z/OS 1.9. The 1.7
versions do not refer to using system symbols in the USSTAB. Both versions,
however, allow the use of certain s
USS table processing, I
am sure they will be sure to cover both the VTAM use and the TN3270 server
use.
Chris Mason
On Fri, 24 Jul 2009 05:52:34 -0500, Lutz Hamann
wrote:
>Ron,
>
>may I ask what USSTAB you mean ? A 'native' USSTAB used by VTAM for
>NON-SNA or SNA-major no
VTAM and TCPIP handle the screens differently if the manuals can be trusted.
The two manuals are SC31-8776 z/OS Communications Server IP Configuration
Reference, and z/OS Communications Server SNA Resource Definition
Reference.
Both manuals describe the USSMSG macro. Both specify that if you w
Ron,
may I ask what USSTAB you mean ? A 'native' USSTAB used by VTAM for
NON-SNA or SNA-major nodes or an USSTAB offered TN3270E-emulations
by the TN3270-Server (by using a STEPLIB) ?
ciao Lutz
Juergen
Since what you want needs support from the VTAM logic which supports the
loading, manipulation and presentation of the USS messages, only the
documented "inserts", such as @@LUNAME, are available. These are the items
found in Table 91, "Valid character strings for message definition" in
I also wanted to have the systemid on screen when getting the Vtam-good-
morning-message. The supplied variables do not give a chance to do that like
LUNAME etc. So I had to code a separate table for each system. You can tell
assembler to use some variables but once it is coded it will be used. V
Ron
This is not a matter for VTAM since an USSTAB is created from the assembler
(and linkage editor - or whatever it's called these days).
The VTAM support is described in Network Implementation Guide - Chapter 3
Implementing a VTAM network - Using MVS system symbols. It does *not*
in
not a guro on asmblr... trying to figure out where this is to go and
coding it from older copy I have..
From:
Martin Kline
To:
IBM-MAIN@bama.ua.edu
Date:
07/23/2009 03:16 PM
Subject:
Re: USSTAB
Sent by:
IBM Mainframe Discussion List
>Anyone have a copy/example of using &sysparm
That should specify two ampersands and the character string 'SYSPARM'
without my quotes and without spaces.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: G
>Anyone have a copy/example of using &sysparm in the USSTAB for VTAM
>logon screen,, to place system-id on screen. I know there is something once
>on the cbt tape but I do not have access to it..
No sample, but code "BUFFER=(addr,SCAN)" on the USSMSG macro, and code
wit
Anyone have a copy/example of using &sysparm in the USSTAB for VTAM logon
screen,, to place system-id on screen.
I know there is something once on the cbt tape but I do not have access to
it..
--
Email Disclaimer
This E-
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. :-)
>
&
urther 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 Re
Need I say more?
On Mon, 9 Feb 2009 14:48:11 -0500, Howard Rifkind
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 executa
t;
>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.
>>
s*, 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 -
=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 k
LOGON APPLID(TMONMVS)
Jim Wangler
214-502-6445
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Howard Rifkind
Sent: Monday, February 09, 2009 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: VTAM USSTAB QUESTION
I have the following entry in
>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
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
Pat
"USS functions" can be described in the following terms:
- Inbound: the analysis and conversion of text into a formatted request
- Outbound: the selection of messages explaining where the analysis failed or
substitution of the response to the formatted request with text[but see 1]
In the c
On Mon, 2 Jun 2008 00:23:30 -0300, Shmuel Metz (Seymour J.)
<[EMAIL PROTECTED]> wrote:
>...
>>The other kind of Tn3270 server - like z/CS's - has APPL LUs and
VTAM
>>does not do USS processing there. The server, rather than VTAM, is
>>acting as the SSCP for the clients.
>
>No; the SSCP does
John
>> Doesn't the LU-SSCP session use SCS rather than 3270 buffer orders?
When the environment is pure SNA - Oh happy days - the text on the SSCP-
LU session was required to be the SNA Character String (SCS). This was so
even when the device normally supported the 3270 data stream.
However, t
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour
J.)
>
> In <[EMAIL PROTECTED]>, on 05/20/2008
>at 02:30 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:
>
> >I could be wrong. I haven't looked into it for a LONG time, but USS
> >messages a
In <[EMAIL PROTECTED]>, on 05/20/2008
at 02:30 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:
>I could be wrong. I haven't looked into it for a LONG time, but USS
>messages are sent on the (real or emulated) SSCP-LU before any BIND has
>been processed.
Doesn't the LU-SSCP session use SCS
In <[EMAIL PROTECTED]>, on 05/23/2008
at 05:57 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:
>The other kind of Tn3270 server - like z/CS's - has APPL LUs and VTAM
>does not do USS processing there. The server, rather than VTAM, is
>acting as the SSCP for the clients.
No; the SSCP does
me to ignore mixed case in input,
which USSTAB doesn't support (unless very permutation is defined). With
suitable coding, it permits single signon for multiple applications, brief news
messages on the logon screen, etc. And a very nice starter version was
available on the CBT tape.
-
I do
Pat
>>> Pat: LUname is almost one of them. The key for substitution
is "@@LUNAME". Too bad they insert the ACB name instead.
>> Chris: What's the problem with the "ACB name"?
> Pat: I got that same response at SHARE when I complained to a couple of
the TCP/IP designers at SHARE once. I
Pat
There are a few misunderstandings to clear up here - and some more
explanations. For complicated reasons[1] I operate from the archives rather
than e-mails. In order to try to reduce ambiguities I'm going to have to be
more adventurous over quoting the text upon which I am commenting.
-
>
On Fri, 23 May 2008 08:35:41 -0400, Gerhard Postpischil
<[EMAIL PROTECTED]> wrote:
>...
>I haven't been involved in this since retirement, but can't help
>wondering why this near universal interest in USS. When VTAM
>first appeared in my installations, we used a network solicitor.
>...
The first
On Fri, 23 May 2008 06:26:51 -0500, Chris Mason
<[EMAIL PROTECTED]> wrote:
>...
>You can have variable substitution in ***all*** USS messages, not
just USS
>message 10 and USS message 7. ...
>...
Chris, I understand the value of the messages and substitutions in
them, but I still don't think th
g why this near universal interest in USS. When VTAM
first appeared in my installations, we used a network solicitor.
It goes through a normal BIND process, so a query was available,
it allowed me to ignore mixed case in input, which USSTAB
doesn't support (unless very permutation is defi
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Patrick O'Keefe
>
> On Thu, 22 May 2008 06:31:49 -0500, Chris Mason wrote:
>
> >...
> >You may be sure that VTAM - let alone the TN3270E server -
> will not be
> >interested in managing "Read Partition Query" exchan
Pat
You can have variable substitution in ***all*** USS messages, not just USS
message 10 and USS message 7. It's the substitution of variables in USS
message 5 which is at the heart of my help desk scenario which, since there's
so much misunderstanding here I'd better cover in more detail:
1.
On Thu, 22 May 2008 06:31:49 -0500, Chris Mason
<[EMAIL PROTECTED]> wrote:
>...
>You may be sure that VTAM - let alone the TN3270E server - will not be
>interested in managing "Read Partition Query" exchanges on the
SSCP-LU
>session - either the real one or the emulated one.
>...
And even if it
Patrick O'Keefe wrote:
My only thought there is that if you DID run into such a benighted
device or emulator you would likely be unable to use it if it locked
up because of the extended datastream.
We no longer allow 1970s-technology to connect to our system. If it
doesn't work, too bad. T
On Thu, 22 May 2008 08:18:44 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:
>...
>> I think that doesn't change anything you said, but I also think
>> that you're outside of any standards if you use extended data
>> streams for USS data ...
>>
>
>True. And, in 1988 I would worry about that a lot
Chris Mason wrote:
> ... the enhancements to the 3270 data stream which came in
> with the 3279 - back in 1979 wasn't it? -
The 3279 color display station models 2 and 3 and the 3287
color printer were announced on October 2, 1979. The GDDM
programming support for PS graphics would not be avai
Patrick O'Keefe wrote:
True, but at the time USS messages and commands are processed
there IS no PLU; all this is taking place on the SSCP-LU session.
(Ok. You could be sending a LOGOFF cmd on the SSCP-LU session
to break an existing LU-LU session, but no message is involved.)
I'm pretty su
Pat
Edward's response was a bit ambiguous in his emphasis on the PLU. If you
ignore the first paragraph he is simply confirming your "everything (probably)
works". The PLU is irrelevant.
You may be sure that VTAM - let alone the TN3270E server - will not be
interested in managing "Read Partiti
Pat
Implicit in what you are postulating here is that the logic behind the real or
emulated 3270 half-session actually cares whether or not there has been
some prior agreement that the presence of the extended data stream
capability is understood by both parties. I believe this is *not* the cas
On Tue, 20 May 2008 12:40:24 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:
>...
>Modern (emulated) 3270 devices generally tell the PLU that they can
>handle extended color orders via the response to Read-Partition
Query.
>That tells the PLU such orders will not be rejected by the SLU.
>
>I do n
Hi all,
Thanks for all your help.I will try what your said.
Tom,
if the macros are free,I'd like to try them.
Thanks again.
BS
YY> Date: Tue, 20 May 2008 12:37:40 -0400> From: [EMAIL PROTECTED]> Subject:
Re: USSTAB color question> To: IBM-MAIN@BAMA.UA.EDU> >
Edward
Assuming you specify your USS message using the BUFFER operand, VTAM's
USS logic and the TN3270E server logic will scan the message looking for text
such as @@LUNAME in order to be able to insert, in this case, the secondary
LU name - in the case of the TN3270E server, the selected APPL
Patrick O'Keefe wrote:
That being said, I have no idea what happens if the USS data is an
extended datastream. VTAM and Tn3270 servers probably send it.
If the receiver processes it without first being told it should, then
everything probably works.
Modern (emulated) 3270 devices generally
On Tue, 20 May 2008 09:44:20 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:
>...
>You're saying that VTAM and/or TCP/IP actually scan through your USS
>message looking for specific orders? That's hard to believe. To what
end?
>...
I could be wrong. I haven't looked into it for a LONG time, but
Patrick O'Keefe wrote:
I haven't looked into this for a long time, but I don't think VTAM
and TCP/IP USS processing support extended attributes. The best
you can do figure out which 4 colors you emulators use to map the
basic attribute combinations (normal/intense, protect/unprotect)
and set
them to you.
Laying out the USSTAB screen using colors is easy with a set of 5
macros, which I will call the TCPHEAD package, that my shop has. I am
not sure where they came from, but I suspect McGill University because
the TCPHEAD macro itself says:
WRITTEN BY: JOSETTE
On Tue, 20 May 2008 10:09:54 -0500, Chris Mason <[EMAIL PROTECTED]> wrote:
>To all the denizens of the list who are now thoroughly confused over what this
>thread might have to do with what they understand as "USS", we actually
>happen to be talking here about the real and original "USS", namely V
To all the denizens of the list who are now thoroughly confused over what this
thread might have to do with what they understand as "USS", we actually
happen to be talking here about the real and original "USS", namely VTAM's
Unformatted System Services which has been around since the mid-sevent
On Mon, 19 May 2008 17:58:38 -0500, Yan Ying
<[EMAIL PROTECTED]> wrote:
>...
>I want to change the logon panel 's color.I cannot find
>how to control the color of the TEXT in USSTAB.Anybody
>know where IBM explain how to control that?Thanks a lot.
>...
I haven't looked into this for a long t
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Yan Ying
>
> Hi all,
> I want to change the logon panel 's color.I cannot find
> how to control the color of the TEXT in USSTAB.Anybody know
> where IBM explain how to control that?Thanks a lot.
The manual _3270
1 - 100 of 130 matches
Mail list logo
