Salva Your post does not appear in the archives of the IBM-MAIN list. You should ensure that you post correctly in order to get the widest audience.
Here is the standard text on how to subscribe: <quote> For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html </quote> - I can summarize your post in the following terms: 1. I can use 3270 data stream in the USS messages with the z/OS Communications Server TN3270 Server and my TN3270 client (3270 emulator) PCOMM 2. I cannot use 3270 data stream in the USS messages with VTAM and an OSA feature configured as CHPID type OSE Incidentally, the mode table entry defined for use in the latter case is NSX32702. - What you want to do is supposed to be impossible and, with this 3270 emulator, PCOMM, what is *supposed* to be impossible appears actually indeed to be impossible. I'll explain. The configuration which your emulator *should* be emulating is that of an SNA-era[1] 3270 display device - of which there have been many starting with the 3278 - and an SNA-era[1] 3270 controller with the capability to connect to a LAN. That being so, the *only* LU type which should be supported for a display-type session is LU type 2[2]. I find it surprising - but given that emulator software can be very flexible and perhaps extend its capabilities further than strictly required by what is supposedly emulated - that you can use the supplied mode table entry named NSX32702 in the second of your two cases, the one which cannot use the USS messages based on the 3270 data stream. Getting finally to the question asked in your post, the reason the second of your two cases cannot support USS messages based on the 3270 data stream is that the data stream used on the SSCP-LU session for the subject configuration is defined to be "byte strings consisting of SCS control codes and SSCP-supported graphic codes"[3] where SCS stands for "SNA Character String". In a way this quote is a bit misleading. Since you have invested some time and effort into creating a pretty picture with the full range of 3270 data stream capabilities, you are probably keen to try something equally impressive using SCS. Forget it! Apart from text, "graphic codes", the only "control code" available to you is the "new line", NL, character. Thus the only formatting is to place a line of text to follow the previous line of text. Furthermore you need to be aware that two NL characters together act as a single NL character. If you want to create a blank line you need to place a blank character between the NL characters. Odd but true! - Now the question is, why were you successful with the z/OS Communications Server TN3270 server? The reason is that RFC 2355 allows some flexibility in the data which flows over the *simulated* session between the SSCP and the LU. Note that the actual session between the SSCP, VTAM, and the LU, the CS TN3270 server program, is fully formatted and, if you imagine an SSCPFM operand on an APPL statement where the APPL statement is behaving as a "device-type" LU which is necessarily the secondary LU in any LU-LU session, it would necessarily be specified as SSCPFM=FSS. That means there would be no reason for *unformatted* system services since all system services are *formatted* between the application using the VTAM API and VTAM itself. As a kindness, the CS TN3270 server *pretends* to be VTAM in that, using the protocols established by RFC 2355, the TN3270*E* RFC, the CS TN3270 server sends out the text of the messages defined by the USS table specified in the PROFILE data set under the appropriate circumstances, USS message 10 initially, and it accepts and analyses the input data at the time the TN3270 server has not established any session with a VTAM application over the SNA network.[4] Because the TN3270 server is performing the processing and because RFC 2355 has provided protocols for switching between 3270 data stream and SCS, it is possible for the CS TN3270 server to use an USS table where the messages and input are either using the 3270 data stream - just as complicated as you like providing the TN3270 client program can handle it - or SCS. You simply use an USS table defined to use the 3270 data stream by specifying the name of the table as the *first* positional parameter of the first token of the USSTCP statement or an USS table defined to use SCS by specifying the name of the table as the *second* positional parameter of the first token of the USSTCP statement. If TN3270 - without the "E" - is being used, the USS table named by the first parameter is used. If TN3270E is being used, the USS table named by the second parameter is used if present. If TN3270E is being used, the USS table named by the first parameter is used if the second parameter is missing. Here's those points as described in the "Usage notes" of the USSTCP statement from the CS IP Configuration Reference: <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> Note how the TN3270 server is obliged to create a sort of mini-session, BIND/UNBIND, in order to use the "3270 format" table when TN3270E has been agreed. In other 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,MAXOUT=7,PACING=0, + DISCNT=(NO),IRETRY=YES,ISTATUS=ACTIVE, + IDBLK=XXX,IDNUM=XXXXX, + USSTAB=USSNEW,VPACING=0,SECNET=YES ZZ88 LU LOCADDR=02,DLOGMOD=NSX32702, + SSCPFM=USS3270,FEATUR2=(MODEL2,EDATS) /> The MAXxxx operands were "sunset" many VTAM versions/releases ago. The z/OS Communications Server (CS) SNA Resource Definition Reference (RDR) manual - in its own peculiar way - expresses the point thus: <quote> Restriction: The MAXDLUR, MAXGRP, and MAXNO keywords on the VBUILD definition statement and the MAXPATH keyword on the PU definition statement are obsolete. If these keywords are defined, the values are not checked and the keywords are ignored. No messages are issued. </quote> The IRETRY operand applies only to SDLC multipoint and so is totally irrelevant. The MAXOUT operand may have a role in setting a key 802.2 parameter - RW to be precise - but does not apply to OSA features configured as CHPID type OSE since that emulates a 3172 as far as VTAM is concerned and VTAM will just ignore the MAXOUT operand when used in conjunction with XCA resources. The ADDR operand applies only to an SDLC secondary station. It is however described in the CS SNA RDR manual as required. This is a mistake and it is not required and, being totally irrelevant should be discarded. I'm intrigued to see the SECNET operand specified as YES. In the past, when what is defined as a LINE really could approximate to an SDLC "line", there was some purpose in arranging that a yellow asterisk appeared on the configuration diagram in a NetView Hardware Monitor presentation of the resource hierarchy associated with an "Event"in order that the operator should be alerted to the fact that the actual configuration was more complex than as shown. Today when all configurations tend to be more complex than a single SDLC line, the SECNET=YES specification tends to lose its usefulness. Be sure that the SECNET=YES specification has no other purpose. Although relevant, there is, in the case of the ISTATUS operand, little likelihood that you would ever want the specification to be other than YES and, in the case of the PUTYPE operand, no likelihood that you would want the specification to other than 2, both of which specifications are the default values. Thus I tend not to bother with ISTATUS=YES and PUTYPE=2. Turning from the PU statement to the LU statement we now examine the LU statement operands bearing in mind that a number of them have been placed on the PU statement, potentially handy as a way of grouping many operands which all apply to following LU statements - unless we use LU *model* statements of course. I commented on the potential unsuitability of NSX32702 above. Please let us know whether or not you succeeded in initiating a session with LU type 0 mode table entry NSX32702 using the switched definitions and the OSA feature configured as CHPID type OSE. The FEATUR2 operand is a bit odd. It was created as an extension of the FEATURE operand which was an NCP-only operand which qualified other essentially NCP-only operands used to define non-SNA resources. The FEATUR2 operand is designed for use only with non-SNA 3270 resources as mentioned in the CS SNA RDR section on the NCP major node.[5][6] There does, however, appear to be a connection between the DUALCSE/LOWERCSE suboperand of the FEATUR2 operand and USS processing - about which I confess to having forgotten. FEATUR2=EDATS is irrelevant for your case. It applies only to non-SNA 3270 devices. the statement "You cannot use this operand for terminals attached by SDLC lines.", if it were brought up-to-date, would list all the ways that you could use to connect 3270 devices to VTAM *excluding* BSC lines. There are very many corners in the manuals which the manual authors have not looked into for 20 years or more just gathering dust! Similarly FEATUR2=MODEL2 is irrelevant for your case. It also applies only to non-SNA 3270 devices. Before it became possible for the "query" function to be used once the session had started, the presentation space dimensions for non-SNA 3270 devices could be communicated to a program only by definition. FEATUR2=MODEL1/2 was one of the definition options available. As far as I know, only the predecessor programs to NetView ever used this parameter - and it was quickly abandoned! PACING=0 and VPACING=0 are very sensible specifications since they permit that no pacing is used. This is suitable when the traffic is naturally pacing by being a conversation where the volume of data in one direction at any one time is very limited. It is nevertheless important that the mode table entry used to initiate the session also has a value of 0 specified for the pacing operands. As we have been discussing the USS table needs to be created using SCS and the SSCPFM operand needs to be specified as SSCPFM=USSSCS. It may be that the reason you may not yet have discovered that you cannot use mode table entry NSX32702 with this configuration is that VTAM is so confused by having SSCPFM=USS3270 specified and the emulator using SCS that is cannot work out how to initiate a session for you. Thus a "cleaned-up" version of your switched PU statement and following LU statement could be as follows: TEST VBUILD TYPE=SWNET PUZZ88 PU IDBLK=XXX,IDNUM=XXXXX, + DISCNT=NO ZZ88 LU LOCADDR=02, + DLOGMOD=D4C32XX3, + PACING=0, + VPACING=0, + SSCPFM=USSSCS, + USSTAB=USSFRESH Note that I am suggesting a supplied mode table entry which will discover the presentation space dimensions dynamically. This should work with PCOMM. I have also implied that you need to change your USS table by giving it another name! Chris Mason [1] I use "SNA-era" in order to exclude the original pre-SNA channel-attached and BSC-attached 3277 display devices and 3272 and 3271 respectively controllers. [2] Take a look at section 4.1.4.3.1, "Initiating an LU-LU Session", in "3174 Establishment Controller Functional Description", GA23-0218-11. You will see that the LU types supported are 1, 2, 3 and 6.2. LU types 1 and 3 are used for printer-type sessions and LU type 6.2 is used for a special purpose in the context of a 3174 for file transfer. Thus LU type 0, the LU type indicated by mode table entry NSX32702, is not *required* to be supported by a 3270 emulator when emulating a 3174, the emulation corresponding to an OSA feature configured as CHPID type OSE (as implied by SNA native support). Only LU type 2 remains for a display-type session. [3] Taken from section 4.1.12.2, "Outbound Message Handling", in "3174 Establishment Controller Functional Description", GA23-0218-11. [4] RFC 2355 also defines how USS can be used while there is an LU-LU session in place but - one can only suppose because of the ignorance of the RFC author - it is a pale shadow of what should be possible if it had been designed correctly. [5] I was a bit confused over why the FEATUR2 operand appeared in the description of a switched major node. I checked - and discovered that the manual authors are similarly confused - so what hope is there for relative newcomers to VTAM as I take you to be? The heart of the confusion in the manual is to say that the operand is for NTO resources when the suboperands concern only 3270 facilities and 3270s were never NTO resources - confusion worse confounded - again!!! [6] You will find the parameters specified by the suboperands of the FEATUR2 operand in the NIB DEVCHAR (ISTDVCHR) control block described in the CS SNA Programming manual. - Salva wrote: > Hi, > I've write a USSTAB that make intwense use of 3270EDS. It works well for TN3270, but not when I connect throw a SWNET (OSA Attached). > This is my testing node: TEST VBUILD TYPE=SWNET,MAXNO=1000,MAXGRP=2 PUZZ88 PU ADDR=XX,PUTYPE=2,MAXPATH=1,MAXOUT=7,PACING=0, + DISCNT=(NO),IRETRY=YES,ISTATUS=ACTIVE, + IDBLK=XXX,IDNUM=XXXXX, + USSTAB=USSNEW,VPACING=0,SECNET=YES ZZ88 LU LOCADDR=02,DLOGMOD=NSX32702, + SSCPFM=USS3270,FEATUR2= (MODEL2,EDATS) > I've tried a lot of combinations of SSCPFM, FEATUR2, MODETAB, ... parameters but allways receive an unformated MSG10 at my PCOM. > Any help apreciate. Thank's in advance. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
