> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Jim Mulder > Sent: Thursday, September 12, 2013 1:13 AM > To: [email protected] > Subject: Re: PDS/E, Shared Dasd, and COBOL V5 > > > I cracked open a (metaphorical) history book, and I discovered that > > IBM introduced PDSEs in 1989 -- about 24 years ago as I write this. > > > > I agree with John Gilmore. A 2013 PDSE prerequisite for Enterprise > > COBOL > > 5.1 is not too soon. > > Some customers have already stated in this discussion that they have > program library PDS data sets which they share across sysplex boundaries. > Unless such a data set is never updated from one sysplex without re-IPLing all > of the systems in other sysplexes which might access that data set (or at > least > restarting the PDSE1 address space, if you use that), then you cannot convert > these PDS data sets to PDSEs without exposing yourself to PDSE issues which > do not occur in the same way for PDS data sets. > This is due to caching which is done at a system level for PDSE, but not PDS. > PDSE also does space reclamation differently from PDS, and some customers > may have operational procedures which depend on the PDS property that > space is not reclaimed until an explicit compress operation is executed.
Is there any thought of a command or procedure to refresh the PDS/E system level cache? Perhaps with caveats similar to LLA,REFRESH and ACTIVATE? > > So in some cases, a PDSE is not a plug compatible replacement for a PDS. > > What is your proposed solution for customers who currently share COBOL > PDS libraries across sysplex boundaries? > > >You can also get acquainted with PDSEs > > and their impacts. (Did I actually just write that? :-)) > > You did indeed write that, and it would suggest that you may be less > acquainted with some of the impacts of PDSEs than the experienced z/OS > systems programmers on IBM-MAIN. > > PDSE certainly does have significant advantages over PDS in many > environments, but there do remain some situations in which the lack of > caching and the more primitive space reclamation characteristics of PDS can > be advantageous. > > And while it is certainly reasonable for COBOL to exploit program object > functionality which is not available with load modules, the fact remains that > MVS made a decision long ago to tie program objects to PDSE, and thus for > some customer environments, moving to COBOL 5.1 may involve operational > changes which are more complex than simply converting COBOL program > libraries from PDS to PDSE. > > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
