On 2 Aug 2005 16:01:51 -0700, in bit.listserv.ibm-main you wrote: >"Tom Schmidt" <[EMAIL PROTECTED]> wrote in message >news:<[EMAIL PROTECTED]>... >> On Tue, 2 Aug 2005 18:16:40 -0300, Clark Morris wrote: >> > >> >>Just a question out of sheer curiosity: what do you mean by "GDG type >> >>naming capabilities?" Are you talking about being able to have >date/time >> >>as part of the generation name or some such? >> > >> >There is no equivalent of PROD.FILE(+1) for an ESDS. The current >> >implementation of changing (+1) to GnnnnVnn could be replaced by a >> >different naming convention that accomplishes the same thing >> >Gnnnnnnn.Vnnnnnn and more sophistication in specification of relative >> >generation numbers. I just don't want to have to change JCL data set >> >names for each instance of an ESDS. >> >> If you want IBM to take your ESDS-GDG requirement seriously, you might >want >> to beef up that business case a wee bit. >> >> "I just don't want to" doesn't have a whole lot of weight (unless, >perhaps, >> you are Warren Buffet or Bill Gates). > >Not likely to happen. VSAM files have totally different format in the >catalog than GDS records. The incompatibilities would make it extremely >difficult to handle GDS files. Also, there would be problems in a user >creating a ESDS, then a non-VSAM, etc, and attempting to read them using >relative generation numbers. Generic VSAM files have other problems, such >as associations - AIXes and PATH names, and the truenames for those AIX and >PATh records would cause problems when the base VSAM rolled off the GDG
In terms of justification for the facility, the SHARE/Guide Language Futures Task Force Report among other things asks for the capability for a program not to care what the actual organization of a file is so long as the logical access is possible for the file. Thus sequential access would be available for all types of organization while keyed access would be restricted to VSAM KSDS type files and properly set up views. This was accepted by IBM in the mid 1980's. The current GDG setup is almost as old as OS360 and may date back to its origins. The 44 character name is also very old. A new GDG structure might take advantage of a more major restructuring which allows Unicode data set names and longer ones. We probably need more than 9999 concurrent generations. If it is worthwhile for IBM and its customer base to make major upgrades to z/OS and its structures as opposed to moving z/OS capabilities to Unix and whatever OS400 is these days, then an enhancement of the GDG function will be needed. I have used and sworn at both OS390 and HP-UX. I have not used z/OS. I have seen Oracle used for all keyed file structures and assume you could do the same with DB2. My experience as a COBOL application programmer on HP-UX was an eye opener in that I was modifying and debugging programs with not a clue as to what the instruction set was (is). The version of SYNCSORT on HP-UX made the z/OS version look archaic. And this was at a shop that had moved from the mainframe, lock stock and barrel to HP-UX and I don't think was taking full advantage of the capabilities of the platform. I don't think their reliability suffered because of the move. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
