That is why I suggested later that if such a change were to be made, it should be at a release boundary and the Conversion Guide should scream about it. Even then, there would be those who missed noticing it until it bit the users.
That said, the ability to choose whether or not to change it could easily be left up to the sysprog who installs and maintains the system as an installation option. Or it could even be done as the other Mike suggested - a system-wide profile that invokes the user's profile before exiting. And if you haven't noticed, directory manager programs generally allow you to put an installation specified PROFILE EXEC on the user's a-disk when the userid is created. That EXEC could be nothing other than a one-time program that would install the defaults for the id, replacing itself with the true initial PROFILE EXEC when done. That would give you control over the initial profiles for things like XEDIT, RDRLIST, FILELIST, etc., if you so desired. So there are alternatives to having IBM change the default actions. Some even give you greater control over the initial, and I emphasize initial, settings a user sees. Once the id has been turned over to a user, it is out of your hands. The user will keep or change settings at will. And, believe me, there are some users who will do wild and crazy things and then ask you why the system is broken. As for something being "obviously not intuitive", that comes with the territory when you are dealing with something new. That is why there are help files and documentation. What you find intuitive is what you are used to. You had to learn CMS and XEDIT when they were new to you. They were not intuitive at first. You didn't just hatch with a priori knowledge of how they work. Regards, Richard Schuh (Not religious as some have suggested, but a strong advocate of Rule #1, "Know what you are doing.") > > Look at the problem that Mike originally posed. It was for > inputting Linux parms. Most of the new workload is Linux. > It was obviously not intuitive to those people that it was > going to be translated. Let's not sacrifice everything on > the altar of backwards compatibility. > Didn't we just have this discussion about command compatibility? > Maybe this is another one that needs to be fixed. > > >Regards, > >Richard Schuh > > /ahw >
