Edward, <snip> (Regardless of the logmode, some software like Netview won't support anything other than a 24x80 primary size. I have a special modified version of Netview that gets around this restriction so long as the primary screen size width is always 80.) <snip>
I think you do NetView a disservice. Are you sure you don't have a rather more obscure - "functionally stabilised" I guess - product such as "Host Command Facility" (HCF) in mind? Until I got a rudimentary CICS working on my VTAM/NCP class systems, I used to have to use logons to HCF when I wanted to be sure that only a single session would be involved. But still dredging memory, the "such as" excludes HCF even, since that got stuck at the point of accepting the X'7F' logmodes I seem to recall. HCF never achieved the sunny uplands of supporting the X'03' logmodes. Are there any who can defend NetView's honour who daily work with NetView? Chris Mason ----- Original Message ----- From: "Edward E. Jaffe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Tuesday, 20 December, 2005 6:20 PM Subject: Re: Creating dynamic 3270 screen size definitions for increased productivity > Shmuel Metz (Seymour J.) wrote: > > >In <[EMAIL PROTECTED]>, on 12/19/2005 > > at 09:02 AM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said: > > > > > > > >>One of the changes to the protocol I've been trying to get IBM and > >>other to implement is to allow for user-defined primary screen > >>sizes. > >> > >> > > > >That has existed for decades; set your 3180 or later to an extended > >model number and it will accept a BIND with, e.g., a 43x80 primary > >size. I suspect that what you really want is a *dynamic* user-defined > >screen size. > > > > > > No. The choices today are a) host-defined logmodes with both primary & > alternate screen sizes hard-coded therein (e.g., SNX3270x) or b) > host-defined logmodes that have a 24x80 primary size and an alternate > size to be determined via RPQ (e.g., D4x32XX3). These choices are > spelled out in the definition if BINPRESZ both in the protocol documents > and in the software. > > For example, to get 62x80 primary with 62x132 alternate, you must use a > logmode with a PSERVIC value like X'0280000000003E503E847F00' where both > sizes are hard-wired at the host in the logmode definition. D4C32XX3 has > a PSERVIC value of X'028000000000000000000300' which -- as defined in > the protocol -- forces a 24x80 primary screen size but lets the > alternate size be specified by the user. > > (Regardless of the logmode, some software like Netview won't support > anything other than a 24x80 primary size. I have a special modified > version of Netview that gets around this restriction so long as the > primary screen size width is always 80.) > > > > > > >>One of the changes to the protocol I've been trying to get IBM and > >>other to implement is to allow for user-defined primary screen > >>sizes. My proposal has been to allow a x'00' BINPRESZ value > >>(undefined) to be loosely interpreted as "not defined by the host". > >>That is, both sizes will be defined by the response to > >>Read-Partition Query. > >> > >> > > > >ITYM by a negotiated BIND. Are you sure that the support isn't there > >already? Did you create an appropriate LOGMODE and try it? > > > > > > I think _you_ need to try it before commenting further. > > As stated previously, I've been working with development groups at both > IBM and Macro4 as well as providers of 3270 emulators for years on this > project. It's slow going. So far, the only two 3270 emulators that > allow user-specified primary screen sizes are BlueZone and Vista. All of > our 3270-based software supports this, but getting IBM's software to > "play nice" has been a challenge. > > BINPRESZ=x'00' is a proposed method of allowing primary as well as > alternate sizes to be specified by the user. Unfortunately, in today's > reality some things won't work with BINPRESZ=x'00' (especially for > "normal" customers that don't have the special modified versions of IBM > software that I have). So our software's workaround approach thus far > has been to _violate the protocol_ and allow the RPQ response to > override the 24x80 primary screen size implied by BINPRESZ=x'03'. > > (BTW, if you use a VTAM session manager, you'd better hope it > understands this protocol violation might occur and should not be > considered an error. The "IBM Session Manager for z/OS" developers at > Macro4 have been quite responsive to this and other requests in trying > to make this support a reality.) > > -- > .-----------------------------------------------------------------. > | Edward E. Jaffe | | > | Mgr, Research & Development | [EMAIL PROTECTED] | > | Phoenix Software International | Tel: (310) 338-0400 x318 | > | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 | > | Los Angeles, CA 90045 | 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
