On Wed, 23 Sep 2020 11:58:02 +0200, R.S. wrote: >This is clou (the point). Many users, a lot o JCL jobs, people are >unaware of the JCL, they can only change volser... >Excuse me, but it looks like kindergarten with no teachers on board. For >45 years. >It is not technical issue, this is strong organizational problem. And >this should be fixed. Yes, people could be unhappy. >BTW: even in this kindergarten it is feasible to identify all the job >libraries and change JCL code. > +1
>W dniu 23.09.2020 o 10:42, Brian Westerman pisze: >> Unfortunately, after about 45 years of doing it "this way", the users have a >> lot of their own JCL, it would not be economical or feasible to train or >> expect thousands of them to change or even know how to change their JCL. >> Many of them (most) don't even know what they are editing, they just replace >> a VOLSER with the one from the listing they have and submit the job. In a >> nice little environment where you can control these things, you are probably >> correct, but that is not the case in this instance. >> "thousands"!? But if you make your imagined change to unique catalogued DSNs those users must be educated to change their process to replace not only VOLSER but also/instead DSN and UNIT. Worse, some may be relying on handwritten logs in which they record only VOLSER, not DSN. Is there any possible dependency on serialization by EXC ENQ on hlq.FICHE.TAPE? What's the likelihood of a collision of generated DSNs during the next 45 years? How would you resolve it? How would you test that solution? The Amish have driven horses and carriages for longer than 45 years They see nothing that needs to be fixed on that account. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
