|
|
Post by mueh on May 23, 2023 14:15:30 GMT -5
George: X command is invalid in 23143 . Please increase CmdNumber in ObjPCmdT .
I find it very usefull to specify all 3 Values in any order in 1 cmd . Even DCB x'80' F 80 works and sets EOL=80 RECFM=80 . Any HH value with A-F needs no x' is perfect .
Thanks
|
|
|
|
Post by George on May 24, 2023 8:09:43 GMT -5
Robert: The validation currently in there does handle stuff like EOL NONE by itself. It uses the current settings of (in this case) RECFM and LRECL to see if it's logical.
I'm not concerned about existing profiles being illogical. Most profiles in existence are in use, therefore they're OK. And it takes a fair effort to create an illogical one. It took me quite a few tries to duplicate the one MUEH reported.
George
|
|
|
|
Post by Robert on May 26, 2023 12:51:43 GMT -5
I have tested the 23.143 beta. I am finding the new syntax very confusing and counterintuitive. To allow EOL F as a valid command is simply weird, even if it 'works'. I wish you had done things differently.
Here is what I wish you had done:
1. Suppose the idea of "DCB" as a command were retained. Then, the syntax of DCB would be like this:
dcb-command:
DBC { dcb-argument } ...
dcb-argument:
{ RECFM command | LRECL command | EOL command }
This makes each part of this "DCB command" very clear as to their purpose, and allows for future flexibility if you needed to cross-validate other commands in the future. Right now, the only way your current beta can work is that you are counting on the syntax of each operand to be a unique type, so that only LRECL takes a number. If you needed to coordinate another Profile attribute that was ALSO a number, this current scheme would fail; you couldn't do it.
2. Once you had done part (1), you could make a change to the command parser, or perhaps implement this as a macro, to allow the DCB part to be omitted.
That is, if the user entered RECFM U LRECL 0, you would "rewrite" it
to make it the same as DCB RECFM U LRECL 0.
That way, internally there would be only one "real" command, that being DCB, but from the user's standpoint it would appear that the 'old' commands RECFM, LRECL, EOL were still there, and you would get your cross validation done.
|
|
|
|
Post by George on May 26, 2023 13:54:18 GMT -5
Robert: My problem is simply this. Over the last several months I have tried - twice - to rewrite the command parser. Both designs ended up requiring major revisions to nearly every primary command to adopt the new parse output. Basically just too major a change, so I've tossed both of them.
I just don't feel like re-visiting for a 3rd attempt right now.
SPF syntax has always been order independent, and to convert to one now where positional order is important is a significant change.
True, if in the future we add another Profile option to the 'set' being validated, AND there is an operand overlap then we can address this again.
And I seriously doubt anyone would enter EOL F to change the RECFM, instinctively it would be RECFM F. But it would work, even if it looks weird.
Also, don't forget there's an interaction of Primary commands and Line commands, yet another wrinkle to any re-write.
George
|
|
|
|
Post by Robert on May 26, 2023 18:52:03 GMT -5
You wrote, "True, if in the future we add another Profile option to the 'set' being validated, AND there is an operand overlap then we can address this again."
Yes, but you have forgotten something. There is ALREADY an overlap.
Suppose I want to use a custom EOL so that blanks are treated as the end of line. In 23.088 I can say EOL 20 and it works fine.
Now, if I were to say RECFM F 20, you take the '20' as an LRECL, because in your (incorrect) point of view, '20' ONLY means a parameter of LRECL.
As a result, EOL 20 will no longer allow a custom line terminator. The 23.143 beta now assumes that EOL 20 is exactly the same as LRECL 20.
By rushing this change to solve a problem, without doing a proper system analysis, you broke the EOL command.
You don't want to revisit this issue any more, after making three wrong decisions about it? That's up to you, but if so, I recommend you back out ALL of the changes you recently made, and take some time to do this properly.
George, you know I am the "parser guy" in the family. I realized from the start that you were heading for a parser conflict, but you didn't want to listen. Now would be a good time to listen.
|
|
|
|
Post by Stefan on May 27, 2023 0:45:15 GMT -5
Robert, The DCB command does allow what you describe, using the notiation DCB x'hh' or DCB x'hhhh' .
This slight but logical change also removes the inconsistency between the EOL and CHANGE/FIND commands, which accept hexadecimal values using the x'hh' notation.
George, I do agree with Robert that the use of the RECFM, EOL and LRECL commands with operands from another of those commands is a bit weird.
Given that it is also 'unlikey', I wonder if it is worth it.
I am very glad you retained the DCB command in the latest beta.
|
|
|
|
Post by George on May 27, 2023 9:18:45 GMT -5
Guys: This is getting a bit ridiculous. MUEH stumbled into a very weird combination of parameters, which actually takes 2-3 stabs to re-create, and got a crash. It's so obscure it probably would never happen again, but crashes must be eliminated.
Robert: I had already thought about the hex problem, and was going to go the route of using a proper X'xx' literal, something EOL should have been doing from the beginning.
What I will do is to stuff in your suggestion for the DCB RECFM xxx LRECL yyy EOL zzz format, and the additional kludge to fudge the old 3 commands into the new DCB format. That will mean no change to the majority of uses, and users will probably never have to use the DCB command itself to make multiple simultaneous changes.
Maybe that will shut this topic down.
George
P.S. I'm leaving the hex EOL operand as-is, since there is no longer a parse conflict.
|
|
|
|
Post by George on May 27, 2023 11:05:09 GMT -5
OK, another Beta pushed out, feel free to try out and comment.
George
|
|
|
|
Post by mueh on May 27, 2023 12:10:29 GMT -5
George: I think you missed my update on Top of page 2 .
X Command is still invalid in 23147 . CmdNumber in OblPCmdT needs to be increased .
Thanks
|
|
|
|
Post by George on May 27, 2023 15:07:08 GMT -5
MUEH: Grrr! I wish tables in PB were easier to set up. I've been caught on that one so often I usually always try an X command after changing the table to make sure I didn't mess it up. Obviously I missed that.
I'll replace todays Beta with a 'A' version to correct it.
George
|
|
|
|
Post by Robert on May 28, 2023 13:30:47 GMT -5
disregard this comment
|
|
|
|
Post by Robert on May 28, 2023 14:06:17 GMT -5
The current beta looks better.
I noticed while testing the Profile Edit GUI, if I type in u for a RECFM, the lower-case u is stored as is, and is not capitalized.
Further testing shows that intentionally entering a lower-case u is not caught, and will cause the cross-validation logic to work incorrectly. The "u" is NOT recognized as RECFM U.
==> This issue affects SOME, but not ALL, dropdown boxes in the Edit GUI. There are a couple of dropdowns where you can type your own text in addition to selecting from the dropdown's list. You should review this, and ones like RECFM that only have certain valid values probably shouldn't be allowed manual data entry. Or, if you continue to allow it, probably the value returned from the dropdown should be forced upper case. Just to make sure users can't enter bad profile values there.
|
|
|
|
Post by George on May 29, 2023 8:14:30 GMT -5
Robert: I forgot that a combobox can be typed into, and assumed the mouse selection of one of the items in the list. The validation handled it all properly (uppercasing it), but the problem with dialogs like that is that all the fields get validated before any are changed.
And the 2nd half simply fetched the value again and stored it without the uppercase. After all, it HAD been validated. I spotted a couple others like that.
Good catch.
George
|
|
|
|
Post by Robert on May 29, 2023 19:21:18 GMT -5
Beta 23.149 validates the RECFM field, and the value is being upper-cased correctly.
However, the error message might be confusing. When an "x" is entered, it says "No RECFM type selected" instead of "RECFM 'x' is invalid".
Perhaps that is a side-effect of how the dropdown control works, and you may or may not be able to make it work differently. Does the dropdown control give an RC to say that the value was not found in the list?
In any case, can't this dropdown work like the PRESERVE dropdown does? That one doesn't 'accept' typed-in values; you can ONLY select from the list. There is really no reason to allow RECFM to allow a typed-in entry, right? I mean, there aren't any OTHER values for RECFM that are valid, are there?
P.S. I see that the message box that says "No RECFM type selected" is non-modal. That means you can CANCEL the main Profile Edit GUI and the "No RECFM type selected" message is left hanging there. It looks odd, and isn't typically how Windows programs are written.
|
|
|
|
Post by George on May 30, 2023 8:59:39 GMT -5
Robert: The box was incorrectly specified, it was created as a COMBOBOX, it should have been COMBOBOXLIST, which does not accept typed input. So the message is worded properly. The message box WAS done MODAL, but did not have a proper 'parent'. I've prevented that from recurring.
George
|
|
