Hi William,
?
It is true that DIAG8C does not return row/column values based on the RPQ result, but mostly because it doesn't need to.? CP was already built around having fixed model numbers for 3270 devices and only supported model 2 and 2A 3270s at the time Release 6 of VM/370 was released.? These fixed model numbers are based around the DMKGRT/DMKGRW tables in CP, one for each model number and their screen size characteristics.
?
Someone else added support for models 3 and 4 around 2006, and I added support for model 5 devices in 2018.? At that time, I also added the RPQ support so one could use MODEL=DYNAMIC in DMKRIO and thereby avoid having to code a fixed model size for each individual device or having to regenerate the CP nucleus just to change a terminal to a different size. Each of these sizes from models 3-5 require a new DMKGRx table, which were added in 2006 and 2018.
?
The RPQ support uses the returned row/column information to establish which of the IBM defined models 2-5 a given device is using.? If the row/column information returned is not one of those, then the model number is forced to model 2 and a 24x80 display.? However, the real purpose of DIAG8C as used in VM/370 is simply to return the extended data:? whether the terminal has color features, extended buffer addressing, and so on.
?
Also you may or not be aware that there is documentation for DIAG58/DIAG7C/DIAG8C and dynamic model and model 5 support.? There is an extensive PDF document for each of these.? Since these features were preinstalled by someone else on VM/CE, I do not know what happened to the documentation.? But in any case, the documentation is available in the files section of this group within the "diag58v310.zip" package (all of this support is in the one package).? The documents are important if you want to extend any features or make changes because the present limitations are also defined and explained.? They also explain the RPQ and when it is issued by CP.
?
For something like the Logical Device Facility (LDF, DIAG7C), this isn't really designed to work with the extended screen sizes you are proposing.? This is because my LDF support was made to function to the VM/SP 5 specification (as explained in the documentation mentioned above) and that specification is specifically for model 2-5 devices as documented by the relevant VM/SP manual.? That's not to say that it could not be extended, but it is an extra complication.?
?
For extended size support in general, dealing with the vagaries of DMKGRF, which in my view is a miserable piece of code, will be quite difficult, as well as coping with the fixed tables of DMKGRT and their ilk.
?
As for the MECAFF editor EE and its friends FSVIEW and FSLIST, this software issues its own RPQ upon invocation, and if you are using an extended size 3270, say 62x160 for example, these commands will display properly in that mode, right now today.?? However, once you exit the MECAFF tool, then your screen reverts to model 2 mode for everything else.?? At least that's the behavior under VM Sixpack, which is what I use (I can't get behind VM/CE and some of the crazy stuff that has been done to it; just my personal opinion).
?
There may be other things that might have issues with extended screen sizes.? For example, even to introduce model 5 support, the CMS EDIT command had to be modified to handle the increased line length.? See patch HRC073DS.?? With a large size, CP might also have issues with the line length for CP commands, and/or might need extensive changes in DMKVCN (CP virtual console support) in order to deal with size issues, as well as supporting the original DIAGNOSE 58 non-full screen functionality that was already part of CP as distributed, long before the full-screen support was introduced.
?
Regards,
Bob
?
