You keep telling us about an annoying limitation which is not a defect. I agree that at times, it is annoying but it has also proved to be very useful. Also as it age's the user's of the system is changing the pattern of usage.
As z/OS ages, the typical end user doesn't know or care what a dataset is. (E.g. SaaS, CICS and IMS). How often do we have end users working with datasets or in TSO? As time goes on, exposure to DSN is more often programmer types who can learn these restrictions. These limitations has forced companies to form naming conventions that are specific, concise and easy to understand. Everyone is working on the same page. These limitations allow security admin to easily secure data as needed. These limitations allow dasd admins to control how storage is used. Extending DSN size would be expensive to implement. If this were truly impacting customers, someone would have built a method to allow extended DSN's. So back to the original question. What is the defect or requirement that will make z/OS far more useful so that its value will exceed it's cost and it's use will be widely adopted? Remember that customers will need to review and implement security changes. They will need to determine how they are affected by the change and QA the changes. Vendors will need to change their products. UNIX utilities will need to be implemented that manage uncontrolled files (e.g. grep and reg expressions for DSN search). DSN limitations are unlikely to change because it's impact outweighs it's advantage. Jon Perryman. >________________________________ > From: Ze'ev Atlas <[email protected]> > > > >>Ze'ev appears to me to want to graft what are essentially interactive, >>conversational facilities onto JCL, which is a batch facility. This >>may well be possible, but doing it will require careful thought and >>much experimentation/evolutionary operation. > >I already concluded that the z/OS side may be hopeless because the limitations >of file name are too entrenched in the OS. The Unix side (especially Linux >that is open source) is a better candidate. No, I do not envision batch >oriented only features. Once the file is committed in the traditional way >(conversational or batch), its location would be known, so when you say in the >shell (AND THIS IS ONLY ONE EXAMPLE): > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
