> At first I was pretty much in favor of the changes Alan was > suggesting, but Mike brought out an excellent point. I > realize, or suspect, that IBM Endicott and perhaps a lot of > other shops may run with RSCS as the standard userid for the > RSCS machine, but in 2 out of the 3 companies for which I > have worked in my professional career, we didn't.
I think we're discussing two things here: 1) what the default for new installs should be 2) what the logic for listing possibilities and selecting the RSCSid should be For #1, I don't see much reason to vary from Alan's proposal. A majority of the people who are doing new VM installs have no reason (or sufficient knowledge of how) to change the RSCS userid, and those who do, can do so without any additional pain that isn't present now. Implementing Alan's suggested solution breaks nothing that works now, and fixes things that don't work properly now if the system RSCSid is not set correctly (LPR (ASYNC and PPS as examples). There are lots of historical reasons to change the RSCS id, but none apply to new installs, and the old methods to do so still work without change. #2 doesn't depend on #1. Yes, it would be nice if the logic worked differently or permitted different selections, but unless we go back to telling people how to properly configure SYSTEM NETID as part of the install, I say the default needs to serve the majority case, and allow people to change it if they need to, which doesn't *require* any additional change to the logic. The two are separate and distinct issues. > Changing the system rscs (note small > letters) id to RSCS is not a trivial task given the tendency > to imbed the id in execs. Leaving the default or undefined > as "*" has a lot of merit. It at least causes an error that > is noticeable and can easily be fixed in one place rather > than having errors drag out until all of the execs that will > be run get used and cause an error. I guess I don't see how this is any different than any other case of hard-coding constant values in programs. I see the following possibilities: If 'RSCS','VNET' etc. is hard-coded in an exec and that's not the system RSCSid, you're going to lose and the default value returned by IDENTIFY isn't gonna matter in the slightest, because the exec isn't paying any attention to it in the first place. Response: fix exec to check output of IDENTIFY. If the exec checks the output of IDENTIFY, it should get the correct RSCSid, unless you forgot to update SYSTEM NETID, and I don't see how IBM can be expected to read our minds (at least not until the z9-ICan'tBelieveItsNotAMD with optional Virtual Brain Stems becomes available) and know that it's supposed to use RSCSVNET instead of the default. Computer does what we tell it, and a default of '*' or 'RSCS' are equally wrong in this case. Response: fix SYSTEM NETID. If you change the system RSCS to some other id, don't update SYSTEM NETID and leave the default RSCS userid in place, then the spool files end up in spool for user RSCS, which will generate the same phone call as having it end up in the user's rdr when what they expected to happen with the output doesn't happen. No data is lost, and if the user didn't notice a problem with the output not appearing, they're pretty unlikely to find the files in their rdr and have any clue what to do with them there. Response: fix SYSTEM NETID, fix exec to check output of IDENTIFY if needed. If you change the system RSCS to some other id, don't update SYSTEM NETID, and remove the default RSCS userid (common practice these days to be required to remove unused system userids as part of policy), then you get a big bang when someone tries to generate output to RSCS, and it generates the same phone call with the same response: fix SYSTEM NETID, fix exec to check output of IDENTIFY if needed. I don't see where this is taking away any flexibility that exists now, and it's a change that doesn't impose a lot of work on IBM to 'just get it right the first time' for 90 plus percent of modern VM systems.
