Re: USSTAB color question
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 case of VTAM the actual communication between the SSCP logic performing the USS functions and the SSCP logic acting on the formatted request - and everything else that the SSCP does - is hidden.[1] In the case of the TN3270E server, the communication between the TN3270E logic performing the USS functions and the SSCP logic acting on the formatted request is the formatted request itself as created using the VTAM API[2], the REQSESS and TERMSESS macros, within the TN3270E server logic. Using this point of view the TN3270E server precisely performs the USS functions and not merely a subset. This anyhow is true of the LOGON/REQSESS half even if it is not true - because of the failings of the RFCs - of the LOGOFF/TERMSESS half. Incidentally, I don't think I would be able to identify any other SSCP functions performed by the TN3270E server - but I'm open to suggestions! Chris Mason [1] I seem to remember noting from NLDM displays that, in addition to the text messages explaining why a session could not be established such as USS message 7, one could also see the (formatted) negative responses to, in effect, to what the USS command had been converted. Take a look next time you have a chance. [2] In platforms other than VTAM, the TN3270E server could decide to be the convert type rather than the pass-through type with respect to USS functions and so could use the SNA API relevant to that platform. On Wed, 4 Jun 2008 15:29:22 -0500, Patrick O'Keefe [EMAIL PROTECTED] wrote: 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 a lot more than convert USS to FSS[1]. ... I agree, and I didn't mean to imply otherwise. What I was trying to say was that since there is no SNA session (LU-LU or SSCP-LU) with the client, any SSCP-ish functions needed by the client are supplied by the Tn3270 server. That includes a subset of USS functions. The pass-through kind of server (like the Tn3270 servers on Cisco's channel-attached routers) pass the commands and messages between the server and the real SSCP-LU sessions. Servers like in z/CS emulate any SSCP functions provided. Pat O'Keefe Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 a lot more than convert USS to FSS[1]. ... I agree, and I didn't mean to imply otherwise. What I was trying to say was that since there is no SNA session (LU-LU or SSCP-LU) with the client, any SSCP-ish functions needed by the client are supplied by the Tn3270 server. That includes a subset of USS functions. The pass-through kind of server (like the Tn3270 servers on Cisco's channel-attached routers) pass the commands and messages between the server and the real SSCP-LU sessions. Servers like in z/CS emulate any SSCP functions provided. Pat O'Keefe Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 a lot more than convert USS to FSS[1]. Maybe it's time to comment on the RFC. If you do, you might want to suggest text on the use of Formatted System Services (FSS). [1] An overloaded acronym. Here the context is VTAM, not JES. -- 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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 rather than 3270 buffer orders? Aren't the USS messages actually sent in an interim LU-LU session? -- 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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
-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 are sent on the (real or emulated) SSCP-LU before any BIND has been processed. Doesn't the LU-SSCP session use SCS rather than 3270 buffer orders? I think it depends on the logmode of the LU: If an SNA logmode, then SCS; else 3270 datastream. But this may be over-simplification (what about line-mode, LUTYPE0, etc.). Aren't the USS messages actually sent in an interim LU-LU session? I thought that by definition the USS messages under discussion originate at the SSCP. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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, the TN3270E RFC - and this thread is all about TN3270E - take a peek at the original post, in defining how the TN3270E server and the TN3270E client should simulate the USS command and message flow over the TN3270 server to TN3270 client connection, allows not only SCS but also 3270 data stream. The original question could have been more technically correct if it had been couched the other way round, perhaps more as Since the TN3270E server acts in a manner very similar to the VTAM LU simulation logic, shouldn't it always be just the 3270 data stream and not SCS? The reason that VTAM permits USS messages to be defined with the 3270 data stream is that, for those device configurations where the 3270 data stream is required, such as with the non/pre-SNA channel-attached 3270, VTAM necessarily passes the data stream, whether it is to be treated as flow on the SSCP-LU session or the eventual LU-LU session, through some LU simulation logic.[1] The LU simulation logic acts in a manner similar to the TN3270E server and converts the USS commands into a format which can then be further handled by VTAM as if it was a formatted SNA INIT type request. As was also mentioned recently in this thread, this is one of the least troublesome tasks out of the very many undertaken by the VTAM SSCP function. The VTAM developers could have added the function to the LU simulator to work with SCS in addition to the 3270 data stream. However, 3270 devices defined as non/pre-SNA devices would not have known what to do with it since, at the very least, it would not have the command and write control character prepended to the data stream. All of this has nothing at all to do with the mode table entry associated with any eventual session and not only because the USS command is needed first in order to specify - even if by default - what the mode table entry name should be! What you may have in mind is the possibility to specify two USS table names in the USSTCP statement, the first using messages defined with the 3270 data stream and the second using messages defined with SCS. The first name is chosen based on the TN3270 client being capable only of the TN3270 protocol level and the second name is chosen based on the TN3270 client being additionally capable of the TN3270*E* protocol level. If there is no second name, the TN3270E server and client are required to be clever enough to work with the 3270 data stream and thus can use the table with the first name. - That's an interesting suggestion that a LINEMODE TELNET connection could be supported with USS processing. Unfortunately, the possibility to use USS processing with the TN3270E server came after I had test systems to play with or I would have spotted this apparently missing function and made sure it really was missing. The Communications Server Configuration Guide says nothing about USS and LINEMODE. Of course, if USS processing were to be supported, the format of the table would need to be SCS or, just possibly, the formatting used for an NTO device (SSCPFM=USSNTO). But, unless anyone has information to the contrary, this is all idle speculation. - Aren't the USS messages actually sent in an interim LU-LU session? I thought that by definition the USS messages under discussion originate at the SSCP. Take a look at RFC 2355. Probably what was meant here is that, the TN3270E client is prepared for the use of 3270 data stream in the USS flow by means of a TN3270E BIND followed by a TN3270E UNBIND when the USS flow is complete. This may be described - by some stretch of the imagination - as an interim LU-LU session. The SSCP sees nothing of these shenanigans! Here's the text of a handy Usage note from the description of the USSTCP statement: quote If an SCS format USS table is specified, it is used for all TN3270E connections. Non-TN3270E connections continue to use the 3270 format USS table. If no SCS format USS table is specified, all connections use the 3270 format USS table. In this case, a BIND/UNBIND is sent to the TN3270E client before/after USS processing. /quote Chris Mason [1] This is all laid out in Chapter 11, Programming for the IBM 3270 Information Display System. The purpose of the chapter is explained in the first paragraph: quote This chapter describes VTAM application programming for sessions that use LU type 0 protocols. Other 3270 protocols (for example, for LU types 1, 2, and 3) are not described here; refer to the 3270 manuals for these protocol descriptions. /quote -- For IBM-MAIN subscribe / signoff / archive access
Re: USSTAB color question
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. - Pat: IBM allows of substitution of some variables in MSG7 and MSG10. Chris: You can have variable substitution in ***all*** USS messages, not just USS message 10 and USS message 7. Pat: I understand the value of the messages and substitutions in them, ... I hope now I have put the parts of the conversation together where that misunderstanding came from. - I started composing comments on the ACBNAME problem but they became so extensive that I have created a new post. - Pat: VTAM has supported different ACB and LU names in APPL defs since the stone age. While thinking through how we got into thus ACBNAME mess, I decided that the operand was probably introduced with multiple domain SNA which puts the SNA stone age in about 1979! - Chris: The RFC defines two types of TN3270E server: - a pass-through type which can support the passing of SSCP-LU requests - a convert type which must convert unformatted flow to formatted flow Pat: 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. The server sends the USS messages; the server processes the USS commands. When what I call the convert type of TN3270E server processes an USS command and there is no session in place, it happily *converts* the partner LU (application) name, the mode name and the data to values in fields set up for the REQSESS macro. In effect, it is converting an *Unformatted* System Services request to a *Formatted* System Services request since, after all, any APPL statement implicitly specifies SSCPFM=FSS (in the same way that a LOCAL statement sort-of implicitly specifies SSCPFM=USS3270 although, because of the print bit oddity, you can specify SSCPFM=USS3270 or USS3275). USS and FSS are two sides of the same coin; they are both about the requests which establish - and terminate - sessions. In the pass-though case, it is business as usual and the owning VTAM performs the conversion from USS to FSS in order to create the formatted request, some flavour of INIT. In the convert case, the TN3270E server performs the conversion from USS to VTAM macro specifications from which VTAM creates the formatted request. As far as the end-user is concerned and as far as the VTAM which processes the formatted request is concerned, the process is identical - just as it should be - for the LOGON case. What I'm after is for all of that to apply in exactly the same way for the LOGOFF case, substituting TERMSESS for REQSESS, some flavour of TERM for some flavour of INIT and the TYPE value in place of LU name, mode name and data - along with the same USS commands, specifically the LOGOFF versions obviously, and messages as usual being used. After all what is the TN3270E server doing with the inflexible LOGOFF command but issuing an inflexible TERMSESS? (See some more notes below.) In a phrase much loved by a very popular British columnist, presenter and, inevitably, best-selling author, How hard can it be? - Naturally the above applies to the rest of what you said. - Except for the point about commenting on the RFC. Perhaps I should take Request for Comment literally. [1] Except for IBMTCP-L which has to be run from e-mails - as far as I can tell - so I operate that list from GMAIL. I'm commuting sporadically between Brussels and Plymouth - from where the Mayflower *left*[2] obviously! - and, away from home, my usual ISP refuses to accept e-mails, hence the reliance on the archives. [2] Did you know the departure city was supposed to be Southampton but they had some trouble and had to put into Plymouth. Not a good omen! --- Before your response appeared, I'd been thinking a bit more about this issue and prepared the following. I guess an expression involving a dog and a bone comes to mind! Section 10.5 of RFCs 1647 and 2355 contain an incompatibility as far as the TN3270E client end user experience is concerned. Let us assume that an organisation is using an outboard TN3270E server and is operating USS functions according to the pass-through specifications. Perhaps they decided to recustomize the LOGOFF command as LOGOUT. Perhaps their IBM technical specialists persuaded them that it would be better to use the TN3270E server built into the Communications Server IP component. You can see where I'm going can't you? Now the poor put-upon TN3270 client end users will be obliged to use the LOGOFF command whenever they get into trouble. It gets worse. Let us assume that the TN3270E client end users or the help desk on their behalf have invested in working out the relative
Re: USSTAB color question
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 was surprised by that response then and I'm surprised to here it from you now. This is my fault for not being clearer - and not being aware that the LUNAME variable text was substituted with the value of the ACBNAME operand rather than the APPL statement name. In order to establish the terminology, if my presentation notes on the topic are to be believed, the formal description of these two names is network name for the name of the APPL statement and uninterpreted name for the value of the ACBNAME operand. My question should have been What is this ACB name problem? Presumably I hadn't noticed that LUNAME was substituted with the value of the ACBNAME operand because I never had reason thoroughly to revisit USS tables when the USS function was added to the TN3270 server, this being after my active teaching days. Shame! Since the issue doesn't arise with the LU statement, there's nothing in my presentation notes about it. Incidentally it's easy to see how it happened. The developers responsible for implementing the USS function within the TN3270 server will have taken the LU name from the control block from which the LU name is extracted by the VTAM USS function, strictly its equivalent for the APPL resource. Knowing nothing of the application deployment subtlety implicit in the network name and the uninterpreted name and probably not really knowing the use to which the LUNAME variable would be put, you end up, in all innocence, with the ACBNAME operand value. Of course, as far as the users, to whom they imagine they are being so helpful, are concerned, this is rank stupidity. I suggest you present the requirement for the network name in the usual way and keep at the developers' heels. Simply they made a mistake and they need to correct it. I fear they may feel impelled to create a new substitution variable, say @NLUNAME or @NETLUNM, since some customers may actually like @@LUNAME as the ACBNAME. Perhaps, however, like - I think - what Sam did with the PSWEIGHT start option default, a function can be changed under customers' noses to what it should have been in the first place hoping nobody will notice! Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
Gerhard 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. 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 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 don't know where you get your near universal interest from. The number of active players involved in this discussion was raised significantly thanks to your contribution. Nevertheless I trust that the passive readership has picked up a few points regarding the philosophy of communicating partners assuming function in their partner without checking that it exists first. And the discussion has moved on to discuss an aspect of the USS function which you should have noticed, assuming you have read all the contributions assiduously, has no equivalent in network solicitor applications. I refer of course to the SSCP-assisted logoff. This is quite up to date since it concerns the TN3270E server and its failings caused by being backed by a deficient RFC. I had an idea you might be wrong regarding the inability of USS processing to be case-insensitive. The evidence I found at first was the following regarding the TRANSLATE operand of the USSPARM macro: quote TRANSLATE=NO Specifies that the USSPARM will not be translated. TRANSLATE=NO is only intended to be coded on the USSPARM for DATA when the data contains a mixed case password and the destination application supports mixed case passwords. /quote But then I got a bit cleverer with my search words. In the description of ISTINCDT in Table 85, Description of the IBM-supplied USS tables, we find the following: quote Default session-level USS table used by terminal operator users. Contains the following: - ... - ... - Translation table that is used for character-coded input from the terminal. The translation table, named STDTRANS, converts lowercase characters to uppercase and converts horizontal tabs to spaces. /quote And in the description of the TABLE operand of the USSTAB macro we find the following: quote If no translation table is specified, VTAM uses the translation table associated with the IBM-supplied USS table (or its user-written replacement). If the IBM- supplied table (or its user-written replacement) does not have a translation table, VTAM does no character translation. /quote And, as already mentioned, the IBM-supplied USS table happens to have STDTRANS as its translate table so, by default the translation table is STDTRANS and USS commands are case-insensitive. Maybe you had in mind the requirement for the *Interpret* table LOGCHAR macro SEQNCE operand. I seem to remember I used to worry about case translation with my routine to disconnect 3270s dialed from VM to MVS by way of the Interpret table. In promoting a sample network solicitor application, I guess you should reflect on the availability or otherwise of suitable skills to understand and modify the sample and maintain the evenual customized local network solicitor application when an IBM-supplied and maintained table-driven function is available. However, you remind me of a network solicitor application I wrote in order to promote the image of the demonstration centre where I was working - and getting to know SNA software and hardware - back in 1976. In those days IBM supplied a sample network solicitor application with VTAM. It was required to cater for BASIC mode devices - and maybe only BASIC mode devices - I forget that detail. In any case, I took it and used it to create a RECORD mode version for use with the non-SNA 3270s dialed from VM. Now when I read about TN3270 parameters relating to network solicitor applications using the SIMLOGON macro with OPTCD=Q specified following using the CLSDST macro with OPTDC=PASS specified, I know exactlky what they are talking about! It helped then - as it ceratinly would not today - that I had recently attended the basic VTAM class which was so short of the usual topics to teach that VTAM programmming was included. Rewriting the sample network solicitor was an opportunity to put the theory into practice. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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. An end user gets into trouble - it happens from time to time I believe - and calls the help desk. 2. The Help desk says Well, I need to know something about your workstation. Please do the following: a. Invoke the SYSREQ function (all end users have been instructed how to do this) b. Press Enter[1] c. Tell me what you see in white[2] d. Invoke the SYSREQ function again e. The rest depends on what the end user reports and may conclude with the following: p. Invoke the SYSREQ function yet again q. Enter LOGOFF r. Whether and how the application is accessed again is at the discretion of the help desk [1] This will return USS message 5 - if USS support operates as it is supposed to, that is, VTAM does and the TN3270 server (supported by the deficient RFC) doesn't. If the end-user is clumsy - I guess some might be - and enters some characters one of the following will happen - again assuming proper USS support: a) a valid LOGON command - USS message 6 b) a valid LOGOFF command - USS message 10 (TN3270E parameters may intervene) c) other - USS message 1 or 2 Except for b - which should be avoided by being clumsy-proofed - any of these messages can have the key white[see 2] information inserted. [2] I am supposing that the IP address and the LU name - and possibly other useful variables - have been set up to show in white (protected/intense) as has been encouraged by one of the responders in this thread! You are correct that USS message 7 is a bit special in that only the RUNAME and SENSE variables are valid in USS message 7. What's the problem with the ACB name? The RFC doesn't read to me as allowing Servers are free to support more than LOGOFF if they want. and that is the interpretation of the Communications Server IP component. - You have obliged me to revisit section 10.5 The SYSREQ Function of RFC 1647 (and 2355 - no significant changes found) and here are my comments indicating precisely where Mr Kelly has got it wrong: - There is a quite correct comment that only SCS (not 3270 data stream) is allowed on the SSCP-LU session. It's interesting to note that VTAM relaxes this limitation for the case of non-SNA 3270 - necessarily[3] - and the limitation is relaxed in the case of the TN3270E server - even when the LU-LU session uses the SNA version of the mode table entry. - The 3270 session states are a bit more complicated than as described. The states should be covered as follows: - No sessions -- nothing - Only SSCP-LU -- SYSREQ toggles between unowned (question mark) and SSCP-LU (stick man) - Both SSCP-LU and PLU-SLU -- SYSREQ toggles between PLU-SLU (square blob) and SSCP-LU (stick man) - The RFC defines two types of TN3270E server: - a pass-through type which can support the passing of SSCP-LU requests - a convert type which must convert unformatted flow to formatted flow Note that my description of the second type allows a proper implementation of the intent of USS flows while the RFC just gives up!!! This is where it all goes wrong with the RFC: the point where the RFC says this makes full support of the SYSREQ key impossible. - rubbish!!![4] Note that TN3270E cannot be a pass-through type - you cannot specify SSCPFM=USSSCS on an APPL statement - but it is perfectly capable of being a convert type. Unfortunately Mr Kelley seems to be unaware of the subtleties of VTAM programming when implementing a secondary LU. I'd need to check again but I believe last time I examined this hole in the RFC I checked that each of the USS LOGOFF options had its equivalent in the VTAM API. (It goes without saying that each of the USS LOGON options has its equivalent in the VTAM API.) What I'm after is support for USS when an LU-LU session exists in the same way as when an LU-LU session does not exist - for the convert type of TN3270E server. There is no technical reason why this cannot be done. All the necessary mechanisms are described in the RFC. It just needs an understanding that the VTAM API to which the convert type of TN3270E server has access on behalf of the TN3270E client can do everything that is defined in the usual VTAM-supplied USS messages. No unnecessary short cuts please! [3] Non-SNA 3270 as emulated by VTAM also has the SSCP-assisted LOGOFF limitation. Relying on my presentation material - since I haven't done it in ages - and also, mea culpa, there are no additional notes, a stuck non-SNA 3270 end user needs to do the following: - Press RESET - assuming this is necessary in order to unlock the keyboard - Key logoff - Press TEST REQ Well, I had to be sure and indeed this handy function is described where it logically belongs even if not
Re: USSTAB color question
-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 exchanges on the SSCP-LU session - either the real one or the emulated one. ... And even if it were interested, we're talking about a hard-coded datastream containing the extended color attributes. The most VTAM or a Tn3270 server could do would be to refuse to send the message. I submit that it is not the province of VTAM or TCPIP to refuse to deliver a message based on its content, any more than it is the province of the postal system to refuse to deliver mail based on its content. So long as the envelope is proper and the correct postage is affixed, the carrier _must_ make every effort to deliver it. It is up to the recipient to accept or reject it, with or without a return to sender notification to the carrier. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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. 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. 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 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. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 that's all the fault of the RFC. More on this in a few lines. ... What's the problem with the ACB name? I got that same response at SHARE when I complained to a couple of the TCP/IP designers at SHARE once. I was suprised by that response then and I'm surprised to here it from you now. At my last shop I had a set of Tn3270 defs shared aomg LPARs. Being lazy, I used the same ACB names on all LPARs and used a system symbol in the applid (LUname). Sure, I could have used the system symbol in both LUname and ACBname. But why??? VTAM has supported different ACB and LU names in APPL defs since the stone age. So when luname was displayed in MSG10 it was really the the ACB name (containing no LPAR identifier). Anyway, if they were going to use the ACBname they should have called the substitution phrase @ACBNAME. :-) ... The RFC doesn't read to me as allowing Servers are free to support more than LOGOFF if they want. and that is the interpretation of the Communications Server IP component. ... You have obliged me to revisit section 10.5 The SYSREQ Function of RFC 1647 ... LIkewise. In fact, I had to go back and forth between your posting and the RFC a number of times and discovered I had completely misinterpreted parts of what Mr Kelly was saying. And, yes, I agree he got it wrong. The RFC defines two types of TN3270E server: - a pass-through type which can support the passing of SSCP-LU requests - a convert type which must convert unformatted flow to formatted flow Note that my description of the second type allows a proper implementation of the intent of USS flows while the RFC just gives up!!! This is where it all goes wrong with the RFC: the point where the RFC says this makes full support of the SYSREQ key impossible. - rubbish!!![4] ... Perhaps if the RFC had said real or actual it would have been correct. As you surmised, the pass-through mode must be the outbourd implementations where VTAM's USS processes are really involved. USS commands really can be passed over to the SSCP-LU sessions, and VTAM will really send USS message back on those sessions. 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. The server sends the USS messages; the server processes the USS commands. ... Unfortunately Mr Kelley seems to be unaware of the subtleties of VTAM programming when implementing a secondary LU. Perhaps. Or maybe he was just being literal. You can't pass the input to VTAM as a USS command so it isn't real USS processing. It's too bad the RFC used the term SSCP-LU session when talking about USS processing. Too bad they didn't say The design of some TN3270E servers allows them to fully support the SYSREQ key because they are allowed to send USS commands to the USS command processor. Then the USS command processor could have been in either VTAM or the server. Maybe it's time to comment on the RFC. It hasn't been updated since 1998 and is still a Standard track RFC, not a Standard. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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, and I think most important, reason is: it's supported. A more significant reason is that most USS processing is now for Tn3270 rather than VTAM. The network solicitor now would have to sit between Tn3270 clients and a Tn3270 server. Those probably exist but I don't think they are common. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 Partition Query exchanges on the SSCP-LU session - either the real one or the emulated one. I detect a tendency in your and Edward's responses to regard the possibility to use the enhancements to the 3270 data stream which came in with the 3279 - back in 1979 wasn't it? - as just a set of enhancements. It's rather more complicated than that. The purpose of the Read Partition Query request and response is to establish just which of the enhancements are actually present and in what shape - literally. If we assume that the possibilities are either basic or enhanced, then, if two sets of messages can be specified, one of each, it would make some sort of sense for VTAM or the TN3270E server to ask which applied and use the appropriate set. However, since the enhanced set can logically be constructed only on the basis of what is contained in the reply, even all this rigmarole doesn't make sense. But, but, but I hear you say, you're making too much of a fuss. What if the enhancement is understood to be limited to just colours and maybe extended highlighting such as underscores and reverse video. Unfortunately, this wouldn't work in the case of the 3290 which would happily claim to be queryable but would return only the possibility to present orange characters. Well, today's emulators don't restrict themselves just to emulating the 3290 ... As I indicated in the earlier response, it is only good practice to check before you chance your arm. It's not really to be dignified as a *standard* in that, not having followed a standard, you are possibly going to hit a problem when there are some future enhancements which assume a standard has been followed - as if there were going to be any enhancements in this area in the future! Except perhaps one - one which perhaps from today might be described as a Hilary Clinton! There is a glaring deficiency in the TN3270E RFC - USS messages ***are*** involved in the case of the traditional SSCP-LU session in the exchanges over the SSCP-LU session. It is the availability of such USS messages - and the substitution of variables such as, and most importantly, the LU name - that allows the help desk scenario where a complaining end user can easily identify his/herself and his/her LU name so that the immediate problem can be solved and the trouble ticket created. Very stupidly RFC 1647 imagines that the only use for the SYSREQ function while a session is in place is to invoke the SSCP-assisted logoff. The fact that identifying information can be passed over, most conveniently USS message 5, has entirely escaped the authors of this otherwise excellent RFC. When you're in the game of emulating you should emulate everything. When you take short cuts, you're liable to discard unappreciated function. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 sure VTAM never issues a QUERY on the SSCP-LU session, and it's even less likely that a Tn3270 server does that on its emulated SSCP-LU session. Fair enough. I was using terms to identify the host and 3270 device that really don't apply prior to the BIND. I simply meant to say that the 3270 will accept programmable color orders without having told the host, via RPQ response or negotiated BIND, that it is safe to send them. 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 datam True. And, in 1988 I would worry about that a lot more than in 2008. I can't imagine there are *any* 3270s in my shop that won't accept extended color orders. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 available until 18 months later (and ultimately was even later). The first actual support for mainframe graphics shipped by any vendor was that in the SAS/GRAPH product from SAS Institute. I think 3279 FCS was sometime in Fall of 1980, but I have been unable to locate my records for that. We put in a first day order and received an appropriately early ship date. I know we got some of the first 3279s if not the very first (simply judging from the serial numbers). When we reported an unusual problem to IBM on two, the CE who showed up was the actual power supply design engineer for the 3279. All the engineering for the 3279 was done at IBM's RTP site near Raleigh, NC. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 more than in 2008. I can't imagine there are *any* 3270s in my shop that won't accept extended color orders. ... 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. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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. The user will have to trade it in for something more modern. Likewise, we don't care about teletypes, mountable DASD, data cells, MSS, reel-to-reel tape drives, bus-tag parallel channel cables, acoustic modems, etc. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 were interested, we're talking about a hard-coded datastream containing the extended color attributes. The most VTAM or a Tn3270 server could do would be to refuse to send the message. I detect a tendency in your and Edward's responses to regard the possibility to use the enhancements to the 3270 data stream ... ...as just a set of enhancements. ... I can't speak for Ed but I was addressing this in the context of the original post which refered to changing the colors. ... If we assume that the possibilities are either basic or enhanced, then, if two sets of messages can be specified, one of each, it would make some sort of sense for VTAM or the TN3270E server to ask which applied and use the appropriate set. However, since the enhanced set can logically be constructed only on the basis of what is contained in the reply, even all this rigmarole doesn't make sense. I'm afraid I agree. But, but, but I hear you say, you're making too much of a fuss. Actually, I would have said Yabut, yabut, yabut, ... What if the enhancement is understood to be limited to just colours and maybe extended highlighting such as underscores and reverse video. Unfortunately, this wouldn't work in the case of the 3290 which would happily claim to be queryable but would return only the possibility to present orange characters. As I recall, the 3290's QUERY reply was very truthful regarding its support of color. It supported all 7 and promised to present each one as ... uh, actually, I don't remember. Defualt probably. And its default was orange. ... There is a glaring deficiency in the TN3270E RFC - USS messages ***are*** involved in the case of the traditional SSCP-LU session in the exchanges over the SSCP-LU session. ... and the substitution of variables ... Actually, this complaint should be directed at the server, not the RFCs. Both RFC 1647 and 2355 include SSCP-LU-DATA Tn3270 Data messages. IBM allows of substitution of some variables (as you mentioned earlier in the thread) in MSG7 and MSG10. LUname is almost one of them. The key for substitution is @@LUNAME. Too bad they insert the ACB name instead. ... Very stupidly RFC 1647 imagines that the only use for the SYSREQ function while a session is in place is to invoke the SSCP-assisted logoff. ... Once again, this is a defect of the server, not the RFCs. The set logoff as the minimum to be supported. From RFC 1647 ... user may then enter any valid Unformatted Systems Services commands, which are defined in the USS table associated with the SLU. The most common USS command users employ is LOGOFF, ... ... Servers that are not allowed to send USS commands on the SSCP- LU session should behave as follows: - if the user transmits the string LOGOFF (upper or lower case), the server should send an Unbind SNA RU to the host ... - if the user transmits anything other than LOGOFF, the server should respond with the string COMMAND UNRECOGNIZED ... Servers are free to support more than LOGOFF if they want. (IBMTEST would be nice.) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 Yan Ying wrote: 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. BR YY [SNIP] Yan Ying, If you think the following macros would help, I suppose I could send 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 MUYAL PROPERTY OF MCGILL UNIVERSITY COMPUTING CENTER Many changes made by Leonard D. Woren of the University of Southern California and we used to run McGill's TN3270 before they sold it to Hummingbird. Here are a few lines of our assembler code that lay out the USSTAB using the F3270 macro of the TCPHEAD package to specify positions and colors: * Put the following in green at line 1, column 62 F3270 POS=(1,61),ATTR=(SFE,GREEN) DC C'ENGINEERING LPAR' * Continue in green at line 2, column 3 F3270 POS=(2,2) DC C'For assistance call the UIS Help Desk at (202)687-4949.' * The following in red at line 3, column 63 F3270 POS=(2,61),ATTR=(SFE,RED) DC C'Authorized use only' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Windows Live Photo gallery 数码相机的超级伴侣，轻松管理和编辑照片，还能制作全景美图！ http://get.live.cn/product/photo.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 not believe the SLU will ever reject an attribute with extended color prior to the query exchange. The device accepts what it accepts at all times. The query response simply tells the host side that it's OK to send such orders. ... 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 sure VTAM never issues a QUERY on the SSCP-LU session, and it's even less likely that a Tn3270 server does that on its emulated SSCP-LU session. 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 datam Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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-seventies rather than what is usually implied by USS in this list, namely UNIX System Services, very much a Johnny-come-lately. I felt that was worth an airing given how infrequently we encounter a thread dealing with genuine USS. - Yan Ying Exploiting the 3270 data stream, which is what you are really asking about, can be a rather complex topic. It needs a quite detailed understanding of how the 3270 data stream works. The first point to get out of the way is that the format of the USS messages about which you are asking is the 3270 format. I see that you include the @IPADDR text which implies that you are using the USS table in the context of the TN3270 server rather than purely VTAM. You have the opportunity these days to use USS messages in 3270 data stream format or SNA Character String (SCS)[1] format. It's only when you use the 3270 format that you can play with colours.[2] I guess the second point to get out of the way is that the details of the formatting characters has very little - not quite nothing - to do with VTAM or the TN3270 server. Thus you will look in vain in Communications Server (CS) documentation for an explanation of how to enhance the presentation of your USS messages. If you are very persistent in reading through the CS IP Configuration Guide manual - I used the V1R9 edition, SC31-8775-12 - you can find a reference to the manual John Chase suggested, namely the 3270 Data Stream Programmers Reference manual. The following hierarchy of section titles takes you to the relevant text: - Chapter 10. Accessing remote hosts using Telnet - TN3270E Telnet server - Using the Telnet Solicitor or USS logon panel - Using the Telnet USS and INTERPRET support - Creating a USS table: quote - Both the 3270 data stream and the SNA character stream (SCS) formats are supported. For more information, see 3270 Data Stream Programmers Reference and the table samples. /quote - Now a short introduction to what you want to do: First of all, given the USS message 10 you put in your post, you should already be seeing colours in what is shown on your presumed TN3270 emulator window. The following is the relationship between colours and 3270 data stream field attributes: protected normal: blue unprotected normal: green protected intense: white unprotected intense: red Thus IBM z/OS SYSTEM V1R9, IP Address= @IPADDR, VTAM Terminal = @@LUNAME and STARTED DATE : 2008-03-27 will appear in white since the attribute byte which applies, positioned at row 24, column 80, - after wrapping from the last character to the first character - is protected intense. (I haven't checked X'C8' is indeed protected intense since I am relying on the comments.) The only other attribute byte you have is the one positioned at row 23 column 80 which is unprotected normal and so the command text which you key will appear in green. Had I been faced with what you want to do using real 3270 display terminals and associated controllers, say, 20 years ago, the only enhancement regarding the use of colour I would feel was appropriate might be to set all the unchanging text to protected normal, hence blue, and arrange for the variable text to be protected intense, hence still white so that it stood out. Setting up some text in an unprotected field just so that it would appear in red is not a source of possible confusion I would impose on my end users. The reason I would not be any more adventurous is the reason given by John Chase in that I would not have been certain that the combination of display and controller in the case of a CUT display or the display itself in the case of a DFT display supported anything other than the basic attribute bytes as described above. Today with clever TN3270 client programs running on PCs and the like I would expect that you could step up to the next level of colour exploitation and use the extended attribute bytes and hence use any of the colours, red, green, blue, turquoise, pink, yellow and white, to your heart's content. Your organisation probably has a standard for TN3270 client and so you can probably simply check your USS messages with your own PC to be sure that the messages will appear correctly on any of your organisation's PCs. It's now that I'm afraid I have to contradict Pat O'Keefe. As I, in effect, just said, when I exploited colours in my USS messages long, long ago, I limited myself to the colours which translate to the basic attributes. However, I had a colleague running another set of classes who was somewhat bolder. His USS messages - probably just his USS message 10 - was set up to exploit the full range of
Re: USSTAB color question
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 VTAM's Unformatted System Services which has been around since the mid-seventies rather than what is usually implied by USS in this list, namely UNIX System Services, very much a Johnny-come-lately. I felt that was worth an airing given how infrequently we encounter a thread dealing with genuine USS. I *highly* doubt a single person was confused. The context of the original post clearly referenced VTAM and was obvious (just as all the USS references to z/OS Unix are obvious by the context of the posts that I have seen). Even if someone was confused, all the replies referenced 3270, VTAM and TCPIP. So why not give this a rest already. It's old. If you personally can't figure out which one somebody is talking about, feel free to post about that to get clarification or write the OP directly. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
Yan Ying wrote: 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. BR YY [SNIP] Yan Ying, If you think the following macros would help, I suppose I could send 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 MUYAL PROPERTY OF MCGILL UNIVERSITY COMPUTING CENTER Many changes made by Leonard D. Woren of the University of Southern California and we used to run McGill's TN3270 before they sold it to Hummingbird. Here are a few lines of our assembler code that lay out the USSTAB using the F3270 macro of the TCPHEAD package to specify positions and colors: * Put the following in green at line 1, column 62 F3270 POS=(1,61),ATTR=(SFE,GREEN) DCC'ENGINEERING LPAR' * Continue in green at line 2, column 3 F3270 POS=(2,2) DC C'For assistance call the UIS Help Desk at (202)687-4949.' * The following in red at line 3, column 63 F3270 POS=(2,61),ATTR=(SFE,RED) DCC'Authorized use only' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 those field attributes in your USS tab. 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? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 USS messages are sent on the (real or emulated) SSCP-LU before any BIND has been processed. The BIND contains the extended datastream flag. Before there has been a positive response to the BIND VTAM (or the Tn3270 server pretending to be VTAM at USS processing time) does not know that the receiver can handle extended datastreams and the receiver does not know that it should handle extended datastreams. Therefore, the USS data uses the most basic datastreams available. 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. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 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 not believe the SLU will ever reject an attribute with extended color prior to the query exchange. The device accepts what it accepts at all times. The query response simply tells the host side that it's OK to send such orders. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 name. You are correct that VTAM's USS logic and the TN3270E server logic will not interfere with any other text including 3270 data stream orders. Assuming you specify your USS message using the TEXT operand, VTAM's USS logic and the TN3270E server logic are actually required to construct the 3270 data stream around the provided text. Again there is variable substitution within the text provided in the TEXT operand - but no manipulation of text in orders - except for the sneaky action of OPT=BLKSUP which I mentioned in my previous post whereby multiple concatenated blank characters can be reduced to one. I think the OPT=BLKSUP function is there mainly for the operator message use of USS rather than the terminal user message use. You are not really encouraged to use the TEXT operand for the purposes of 3270 text and orders rather than just 3270 text but it works. The only snag I have found - other than the challenge of making it readable - is that OPT=BLKSUP action when trying to build a set buffer address for location 0. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
USSTAB color question
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. BR YY My usstabis look like that: USSN TITLE '-- ACF/VTAM USS TABLE FOR NONSNA DEVICES' SPACE */* -- */* */* USS TABLE FOR NONSNA DEVICES ... */* */* . CAN USE 3270 CONTROL CHARACTERS */* */* -- SPACE USSN USSTAB FORMAT=DYNAMIC SPACE LOGONUSSCMD CMD=LOGON,REP=LOGON,FORMAT=BAL USSPARM PARM=P1,REP=DATA,DEFAULT=' ' USSPARM PARM=LOGMODE USSPARM PARM=APPLID,DEFAULT='TSO' SPACE CICSAUSSCMD CMD=CICSA,REP=LOGON,FORMAT=BAL USSPARM PARM=P1,REP=DATA USSPARM PARM=LOGMODE USSPARM PARM=APPLID,DEFAULT='CICSA' EJECT USSMSG10 USSMSG MSG=10,BUFFER=(BUF010,SCAN) BUF010 DS0H DCAL2(END010-BUF010) * DCX'F5C7' COMMAND + WCC DCX'11',AL2(((24-1)*80)+(80-1)) R=24,C=80 DCX'1DC8' PROTECTED,INTENSIFIED * DCX'11',AL2(((02-1)*80)+(01-1)) R=01,C=01 DCC' IBM z/OS SYSTEM V1R9 ' DCC' IP Address= @IPADDR ' * DCX'11',AL2(((03-1)*80)+(01-1)) R=02,C=01 DCC'' DCC' VTAM Terminal = @@LUNAME ' * DCX'11',AL2(((19-1)*80)+(01-1)) R=19,C=01 DCC' STARTED DATE : 20' DCC'08-03-27 ' * DCX'11',AL2(((23-1)*80)+(80-1)) R=23,C=80 DCX'1D40' UNPROTECTED DCX'13' INSERTCURSOR END010 EQU * EJECT END USSEND END ,END OF ASSEMBLY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
-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 Data Stream Programmer's Reference_ describes how to specify the necessary attributes (and extended attributes, if the device supports them). Bookmanager format: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7P4000/CCON TENTS .PDF format not available. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USSTAB color question
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 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 those field attributes in your USS tab. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
