IBM Mainframe Forum

If it is effectively a "user application" then it is no different from having to complete a data-entry screen correctly, or abandoning it, before moving on to the next then.

Obviously if applied to general editing in an IT environment, expect a Lynch Mob.

Hello,

And once the "force" is entered into the data, anyone else editing the data will be able to update it . . .

Methinks this needs to be rethought. . .

I do the same / opposite for myself. When I try to edit (ISPF option 2) an SCLM controlled data set, I exit immediately with a warning message not to edit that data set.

Wow...tough room. Prino and Enrico are like those two guys in the balcony of The Muppet Show, or maybe Tom Servo and Crow from MST3K.

Wow...tough room.

I agree with the other posters about the original post being poorly written, but I was more forgiving because English is likely their second (or third) language.

In the product I support, we have had to resolve customer problems: 'Why did you let me save values that were invalid?' (it caused problems downstream). Though my problem did not occur in the editor, the basic issue is a valid concern.

Mr. Pedro
I want to use forcing for our JCL editors to writes associated comments on associated line if the JCL. If they are to refrain from writing comments, upon they want to exit from JCL members whitout writing a comment for example in line 2, my edit macro show them a message like this:
"YOU MUST PUT COOMENT ON YOUR CHANGES"
and doeing prevention to exit.
Is my meaning obvious for you and other friends?

for critical data, to protect myself from fat fingers
I use an initial macro to issue an AUTOSAVE PROMPT, so that it nullifies PF3
and forces typing SAVE in the command line

Mehdi shri,

I'm not sure that what you are trying will be as effective as you think.

There is no way your macro can know that a comment is "meaningful", yet you can get a "false sense of security" by thinking that everything has a comment in it.

I think it would be better to list out all the comments of all those members which have changed "recently" (being whatever period of time is chosen) and then subject them to a "human review" (someone reads them) so that the comments are known to be: present; meaningful; correct connected accurately to external references for the change.

Personally I'd list the changed JCL as well, as there is no point in the comments being fine if the JCL is wrong/not even changed.

Hello,

For this concern, i like what Enrico has provided:

for critical data, to protect myself from fat fingers
I use an initial macro to issue an AUTOSAVE PROMPT, so that it nullifies PF3
and forces typing SAVE in the command line

I am also a big believer of regular (proven) backups. . .

I also offer that if these members are "special", not very many should have the ability to update them.

I think you need a formal library system where changes can only be promoted after a code review and approval.