开云体育

Possible Diag 8C Issue

William Denton All Messages By This Member #6268 I am working on an update to CP that would allow pretty much arbitrary display screen sizes. ? One thing I noticed in the current Diagnose 8C code is that the returned column count is being hardwired at 80.In fact, the code actually comments out the statements that set the column count from the RPQ results. ? I am wondering why that is? Is there some function someplace that calls Diag8C and can't deal with arbitrary values? ? cheers, William
Bob Polmanter All Messages By This Member #6269 The original Diagnose 8C code only supported 3270 models 2, 3, and 4 because at the time that was all that was supported in the VM/370 code that we had.? Later, when model 5 support was added to the system, then Diagnose 8C was extended to support that device and 132 columns as well as 80 columns.? See patch HRC073DK, which among other things modified the Diagnose 8C code. ? Regards, Bob ?
William Denton All Messages By This Member #6271 Bob.. Thanks for pointing out to me that the update for mod 5 also bumped the Diag8C return values. I guess my point was that the current Diag8C implementation does not return values based on the RPQ results. ? I suppose the larger question is how would users of Diag8C respond to arbitrary values for row/column configurations... I suspect that the VM Rel3 Editor would have issues without a mod... what about EE and others??? My "any size" mod to CP is not prepared to make any updates to C code... not exactly sure how to package that?? Have the C coders anticipated the use of the CMS UPDATE command used against their code???? ? Sorry to introduce many other issues here... but... ? cheers, William ? ? ? ?
Dave Wade All Messages By This Member #6272 On 03/11/2024 08:02, William Denton via groups.io wrote: Bob.. Thanks for pointing out to me that the update for mod 5 also bumped the Diag8C return values. I guess my point was that the current Diag8C implementation does not return values based on the RPQ results. I suppose the larger question is how would users of Diag8C respond to arbitrary values for row/column configurations... I suspect that the VM Rel3 Editor would have issues without a mod... what about EE and others??? My "any size" mod to CP is not prepared to make any updates to C code... not exactly sure how to package that?? Have the C coders anticipated the use of the CMS UPDATE command used against their code???? Seeing as "C" code cannot have sequence numbers in 73-80 you can't use UPDATE to maintain it. There are copies of "DIFF" and "PATCH" on the CE edition which can be used in the same way, but I suspect most "C" developers store their code in GIT , or a similar modern source management system, which tracks changes in a similar way. Sorry to introduce many other issues here... but... cheers, William Dave
Ross Patterson All Messages By This Member #6273 On Sun, Nov 3, 2024 at 04:23 Dave Wade via <dave.g4ugm=[email protected]> wrote: On 03/11/2024 08:02, William Denton via wrote: > Have the C coders anticipated the use of the CMS UPDATE command used against their code???? Seeing as "C" code cannot have sequence numbers in 73-80 you can't use UPDATE to maintain it. Back when I worked for VM Software/Systems Center/Sterling Software (whew!? I'll never write that again!), we had a lot of CMS application code written in C.? We had our own toolset to maintain it, but at the bottom of it all was XEDIT in UPDATE mode and EXECUPDT.? I forget which VM/SP level introduced?EXECUPDT, but it used UPDATE* in the classic VMFASM manner to create a variable format output file without sequencing (and other optional changes that made no sense for C code). The net of it was that we could edit C code exactly like in any other editor, the editor created UPDATE files, we could apply them and produce a source file exactly like the compiler expected, and all of our UPDATE-oriented code management tools just worked. Ross * When IBM introduced EXECUPDT, it also modified UPDATE to support files wider than 80 columns.
Bob Polmanter All Messages By This Member #6274 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 ?

Previous Topic Next Topic