Re: V6R1 CHGPF bug? No. CL command prompting issue

David FOXWELL wrote:

I have a habit of doing this when I want to make the same changes
to a bunch of test files :

Modify the first one then press F9 :
? CHGPF ?*FILE(mylib/myfile1) ?<SIZE(*NOMAX) ??TEXT('mytext ')

Change the name of the file to the next file to be modified : ? CHGPF ?*FILE(mylib/myfile2) ?<SIZE(*NOMAX) ??TEXT('mytext ')

Press enter + F10. The CHGPF screen shows myfile2 and *nomax is
also shown. Change the other files. Run the program which crashes
because the file size is not big enough.

Press F9 to recall the CHGPF command :
? CHGPF ?*FILE(mylib/myfile2) ??TEXT('mytext ')

Where did the *NOMAX go?

The issue is almost surely with command prompting. Just about any command you could issue with similar prompting [most notably to have included a "?<" selective prompt] would exhibit the same issue for when the command failed with an escape message.

When the prompted CHGPF gave an error, the *Escape message caused the command processor to leave the command string at the command line. When F9 is pressed, the command shell retrieves the command issued immediately *prior* to the failed command which remained on the command line entry. Since the prior command completed against MYFILE1 however, I expect the actual result of the F9 would have shown instead of what was noted above [note file name and case folding to upper]:

? CHGPF ?*FILE(MYLIB/MYFILE1) ??TEXT('mytext ')"

If as I infer, then the NOMAX() parameter specification had disappeared for the completed\processed command string because its selective-prompt-characters requested to /hide/ the parameter. That the command string which was retrieved was the one that previously completed without error, and thus its /hidden/ parameter specification was not logged and thus not retrieved.

Regards, Chuck