Edward I used your post as a prompt to read up on this "enhancement" I have heard about from time to time in this "forum".
Here's my thoughts on your "NextGen 3270" document: Unfortunately "Bit Bucket x'1F'" is not/no longer available so I am unable to review "the whole story". <For the benefit of those not steeped in this topic:> The name PSERVIC, for "presentation services", is the name of the MODEENT macro keyword operand used to create the mode table entry in the assembled mode table referenced by the VTAM entity describing the representation of the logical unit, for example, LU, LOCAL, APPL or CDRSC statements. PSERVIC is described in section 5.6.4.17, "PSERVIC" of z/OS Communications Server SNA Resource Definition Reference. The names beginning with BINPS refer to fields in the DSECT which maps fields within the BIND request data for use by a VTAM program. These names can be found in section F.1.14, "BIND area format and DSECT" of z/OS Communications Server SNA Programming. The data provided by the value of the PSERVIC operand map to the fields with names beginning with BINPS because they are the same parts of the BIND request data. </benefit> The "Query Reply", the request data sent in response to the "Read Partition Query" request, contains 4 presentation space dimensions fields, a row and column for the alternate dimensions, used when the space is initialized using an "Erase Write Alternate" 3270 command, and a row and column for the default, seemingly called "primary" in some circles, dimensions used when the space is initialized using an "Erase Write" 3270 command. Thus the default presentation space dimensions need *not* necessarily always be 24 rows and 80 columns. It may only be a convention that they are so limited, a convention established by the choice taken by devices which follow the initial design choice of the models 3, 4 and 5 3278 displays. The design choice was taken for obvious reasons, namely that, when using the alternate dimensions, newer applications could be accommodated while. using the default dimensions, existing older applications could be accommodated. Also any applications which didn't bother to check the equivalent of the penultimate byte of the PSERVIC operand but just assumed the 24 rows and 80 columns dimensions would continue to work. "suboptimal" depends on what you want to do. I expect you mean "suboptimal" from the point of view of a developer of software who wishes to exploit the possibility to use different presentation space dimensions. Possibly also from the point of view of a user who has enough clout to bully the developer of a highly used application into exploiting the possibility to use different presentation space dimensions. By the heavily used application, I mean, of course, TSO. I'm wondering why all this effort described in "NextGen 3270" was made. 24 rows and 80 columns is *not* necessarily forced. Is there architecture-level documentation somewhere that says it should be?[1] If so, were the authors of that documentation not communicating with the people who designed the "Query Reply" request unit who must surely also be dubbed "architects"? There's not even a protocol requirement that it should be. That is, it's not as if anything should break if, say, an emulator were to return default presentation space dimensions other than 24 rows by 80 columns. Surely applications should - if they are worth their salt - check the returned default dimensions and UNBIND if they don't like what they see. If they don't they should be "APARed" to do so. If they are "out there" with no support or obstinate support - I've experienced such sterling obduracy - then whoever sets up the emulator configuration will have to make the compensation. Is this perhaps the "blood on the carpet" stuff in the document I can no longer get at? [1] While preparing this for posting, I filled in the references and that brought me to what the VTAM Programming manual said about BINPSZ3. It happens to include the text "24 rows and 80 columns" and is unintelligible thereafter - which stands out rather given that the neighbouring descriptions make sense. Unfortunately "SNA Formats", the relevant architecture manual spurns all LU types other than LU 6.2 so this Appendix in the VTAM Programming manual is the closest one can easily get to any documentation on this subject. I contend that what is specified in the VTAM Programming manual should not be regarded as definitive - even if it made sense - since it is *not* an architecture manual and may, in this case, merely be trying to describe the practice of the initial 3270 devices which supported default and alternate presentation space dimensions. I can't see how having yet another option in the coding of PSERVIC helps in understanding that the 7E, 7F and 03 options, as it were, already exist. This refers to the contention that having dimensions other that the default is a "secret". It's my belief that the 00 option specification is like LU type 0, in other words, "all bets are off". You, namely the logic behind the primary and secondary half-sessions, make of it what you will. I seem to remember that some applications, maybe NetView before it was called NetView, i.e. NCCF, probably also HCF, maybe even CICS in days gone by (clearly TSO was/is fussy!) just assumed the usual 24 rows and 80 columns dimensions. I've checked my notes on these matters but can't see this specified precisely anywhere. One point that worries me about the 00 option is the "S3270" mode table entry in ISTINCLM. This has no PSERVIC operand specified which means that, by default, it specifies the 00 option. I expect in the mid and late seventies the applications that appeared at that time supporting 3270 devices tolerated the 00 option in the S3270 mode table entry and simply assumed the ubiquitous "model 2" dimensions. I expect this applied/applies to TSO. Perhaps the 00 option should be given this new role you propose only when LU 2 protocols are used. If customers still use the S3270 mode table entry or have their own mode table entries which do not specify the PSERVIC operand, possibly because they copied what was specified for the S3270 entry before they made their changes, maybe introducing subarea COS operands, you should not blindly allow the use of the "Read Partition Query". I would have preferred the use of a code other that X'00' in the penultimate byte if it is really necessary. Reuse of something which exists already in protocols is always open to unexpected consequences. I see the APAR applies only to TSO but I don't see it being limited to LU type 2. I can't see any harm in having an emulator (a) allow the specification of the default dimensions (b) always return both the specified default and alternate dimensions when a Read Partition Query is received There can be "harm" if whoever customises the emulator somehow imagines that mere specification of different default dimensions will cause the application to respond appropriately. Indeed such harm is already possible if the application cannot respond properly to the specification of the *alternate* dimensions - see Peter Hunkeler's posts in this thread. As usual, there's no substitute for understanding what you are doing. One can go too far in trying to prevent foot-shooting. This is all to suggest that insisting that the emulator notes that the 00 option (BINPSZ0) is in use should be unnecessary. I don't quite follow the points you list about NVAS. The conclusion seems to be that NVAS as it is would tolerate default dimensions other than 24 rows and 80 columns but surely this is only currently with the 03 option and not the 00 option. It's inappropriate to suggest that there is any BIND negotiation (the SMCS points). This just gets some of the list participants unduly excited. <g> In terms of "Where to go from here", to my mind the key point is to encourage developers of 3270 emulators to allow the default size to be specified. Thus, when "queried", the default dimensions may be other than 24 rows and 80 columns. Application developers can then use the full specifications provided either by the "Query Reply" - or - in the BIND presentation services field when the 7F and 7E options are used. If the application developer doesn't like the former, the session can be "unbound" or if it doesn't like the latter, the CINIT request (containing the BIND image) can be rejected. A suitable sense code, "unacceptable presentation space dimensions"?, can be inserted in both cases. Unfortunately, while checking for another post on this topic I could not find such a suitable sense code. I hope you explain that D4x32XX0 mode table entries are *not* (yet) provided in ISTINCLM. Thus you should explain how to create them. This is the end of comments on what is present in the "NextGen 3270" document. Now for what is not present: I find it very surprising - given there has been supposedly so much discussion of these matters - that you nowhere deal with the possibility to use default dimensions other than 24 rows and 80 columns under the 03 option. It's such an obvious suggestion even if there's some fatal flaw in the idea which I'm too feeble to imagine. However, I've been doing some "designing" of my own. Let us assume that, using the 03 option, in effect, returning the default presentation space dimensions in the "Query Reply" is redundant: they will always be 24 rows by 80 columns, the application is entitled to expect this and ignores whatever is returned for the default presentation space dimensions, the emulator ignores whatever is specified as the default presentation space dimensions, if such customization is available, and always overrides with 24 rows and 80 columns and so anticipates the formatting which will be provided when an "Erase Write" command appears. Now let us propose that, using the 00 option - although I would have preferred a new option, say an 04 option - the default presentation space dimensions in the "Query Reply" are significant: they can be other than 24 rows by 80 columns, the application knows to pay attention to whatever is returned for the default presentation space dimensions, the emulator also respects whatever is specified as the default presentation space dimensions, if such customization is available, but uses 24 rows and 80 columns when such customization is not available and anticipates using the specified dimensions for the formatting which will be provided when an "Erase Write" command appears. Thus the emulator is capable of providing three formats for the presentation space on its own initiative, as it were: 1. 24 rows and 80 columns when the "Erase Write" command is used and the BIND contained the 03 option 2. customized default dimensions when the "Erase Write" command is used and the BIND contained the 00 (04) option 3. customized alternate dimensions when the "Erase Write Alternate" command is used and the BIND contained either the 00 (04) option or the 03 option It may also be capable of providing others, of course, if dimensions other than any customized are imposed when the BIND contains either the 7F or the 7E option. Of course, the emulator could reject a BIND where an attempt to impose such dimensions differed from the customized dimensions but I would consider such behaviour rather inflexible. For completeness, dimensions of 24 rows and 80 columns are used for both the "Erase Write" and the "Erase Write Alternate" commands when the 02 option is used. (We'll pass over any 01 option!) Since you'd got me musing over these matters my ideas wandered ever further. Since the 7th to 10th bytes of PSERVIC are not expected to contain any values according to the way the 03 option is currently defined - and no customer systems programmer should have had the lack of wit to specify anything there for a locally created mode table entry - perhaps one may use the 7th and 8th bytes for an override for the default values specified in the emulator customization and the 9th and 10th bytes for an override for the alternate values specified in the emulator customization. I've described this addition in terms of the PSERVIC operand but it may be of greater use when the application sets the values in the BIND image between receiving the CINIT request unit (the VTAM LOGON exit) and sending the BIND request unit (the VTAM OPNDST call). This is the sort of discussion I would expect to have found somewhere. Perhaps it exists in that file I cannot access. Chris Mason ----- Original Message ----- From: "Edward Jaffe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Tuesday, 22 August, 2006 9:27 PM Subject: Re: >27x132? > Tom Marchant wrote: > > On Sat, 19 Aug 2006 09:13:51 -0700, Edward Jaffe > > <[EMAIL PROTECTED]> wrote: > > > >> For users that need to use TSO/ISPF, I recommend 51x80 primary (default) > >> screen size and either 51x132 or 62x132 alternate screen size. > >> > > > > Does anyone know how to set the primary screen size in IBM Personal > > Communications? > > > > It can be set only from the host side. There is no function to set it > from the client side. You might find my 'NextGen 3270 Update' in > Baltimore Bit Bucket X'20' of interest. Get it from: > http://ew.share.org/client_files/callpapers/attach/SHARE_in_Baltimore/S2817EJ064923.pdf > > -- > 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
