Re: PDS/E, Shared Dasd, and COBOL V5
I think the doc is insufficient. What I believe that it should have said is something like: If a job has multiple steps, all of which use program contained in the same, non-linklist/lpalist, data set(s), then using JOBLIB is simpler than using multiple STEPLIBs. However, if the steps within a job are a mixture of programs on the linklist/lpalib or distinch libraries, then using a STEPLIB only on the steps which require a STEPLIB and which only contains those libraries which are necessary, will result in more efficient program fetch. This is due to the fact that in a job with a JOBLIB, each step must search the specified libraries, in order, for the program on the EXEC PGM= and also those dynamically loaded using system services such as LINK or LOAD. Yeah, that isn't phrased all that well, either. I'm not a tech writer. My example. Suppose the job 10 steps and all the programs are in a given library. Then use a JOBLIB. But if your job is going to do 5 IDCAMS steps, 2 IEBGENERs, and 3 user programs, then use a STEPLIB. Or if the job is going to use 7 different programs which completely reside in 7 different libraries (i.e. any dynamic programs live in the same library), then use a unique STEPLIB in each step. On Fri, Oct 25, 2013 at 10:56 PM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 10/23/2013 5:13 PM, Frank Swarbrick wrote: I just read something interesting: http://publib.boulder.ibm.com/**infocenter/zos/basics/index.** jsp?topic=/com.ibm.zos.zjcl/**zjclc_jclEXECsearch.htmhttp://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zjcl/zjclc_jclEXECsearch.htm For a multi-step job, using the JOBLIB DD statement is most efficient when most of the programs reside in private libraries. For a multi-step job, using the STEPLIB DD statement is most efficient when most of the programs reside in system, rather than private, libraries. I find this surprising. AFAIK, there is no substantive difference between JOBLIB and STEPLIB. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.**com/ http://www.phoenixsoftware.com/ --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
And if all job steps would otherwise require the same STEPLIB, it would obviously be not only simpler but more efficient as well to use one JOBLIB, so the datasets associated with the *LIB DD would only be allocated once rather than repeatedly for each job step. Other's mileage may vary, but it always seemed that most multi-step jobs in our shop had many job steps that either didn't need a STEPLIB or that required a unique STEPLIB, so we generally discouraged use of JOBLIB as a matter of efficiency except for the rare cases where it did make sense. Back in the old days with PDS libraries on real DASD and relatively small or non-existent DASD cache, having many job steps needlessly spinning through irrelevant PDS directories on repeated program fetches just because it was simpler to use a JOBLIB could not only degrade program fetch but could raise DASD device and channel usage, possibly to the point other useful I/O would be degraded. One would expect any overhead or contention effects associated with an inappropriate JOBLIB to be less significant with today's hardware and with PDSE libraries, whose directories may be cached in main memory. Joel C Ewing On 10/26/2013 07:37 AM, John McKown wrote: I think the doc is insufficient. What I believe that it should have said is something like: If a job has multiple steps, all of which use program contained in the same, non-linklist/lpalist, data set(s), then using JOBLIB is simpler than using multiple STEPLIBs. However, if the steps within a job are a mixture of programs on the linklist/lpalib or distinch libraries, then using a STEPLIB only on the steps which require a STEPLIB and which only contains those libraries which are necessary, will result in more efficient program fetch. This is due to the fact that in a job with a JOBLIB, each step must search the specified libraries, in order, for the program on the EXEC PGM= and also those dynamically loaded using system services such as LINK or LOAD. Yeah, that isn't phrased all that well, either. I'm not a tech writer. My example. Suppose the job 10 steps and all the programs are in a given library. Then use a JOBLIB. But if your job is going to do 5 IDCAMS steps, 2 IEBGENERs, and 3 user programs, then use a STEPLIB. Or if the job is going to use 7 different programs which completely reside in 7 different libraries (i.e. any dynamic programs live in the same library), then use a unique STEPLIB in each step. On Fri, Oct 25, 2013 at 10:56 PM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 10/23/2013 5:13 PM, Frank Swarbrick wrote: I just read something interesting: http://publib.boulder.ibm.com/**infocenter/zos/basics/index.** jsp?topic=/com.ibm.zos.zjcl/**zjclc_jclEXECsearch.htmhttp://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zjcl/zjclc_jclEXECsearch.htm For a multi-step job, using the JOBLIB DD statement is most efficient when most of the programs reside in private libraries. For a multi-step job, using the STEPLIB DD statement is most efficient when most of the programs reside in system, rather than private, libraries. I find this surprising. AFAIK, there is no substantive difference between JOBLIB and STEPLIB. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.**com/ http://www.phoenixsoftware.com/ -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Almost all of these comments/conjectures are reasonable, commonsensical ones. My impression is, however, much like EJ's. Apart from silly configurations, e.g., a JOBLIB comprised of n concatenated libraries, a different one for each of n job steps, I have not noticed significant differences among configurations, even ugly ones. Anecdotage is never really very helpful in these situations. What are needed are some systematic, carefully designed, replicated measurements, separate ones for PDS- and PDSE-resident libraries. Any volunteers? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
John: In all the installations I have worked in most are COBOL. None of the COBOL installations use dynam and so all(most all) the cobol subroutines are loaded at the initial step initiation time. From my not so all encompassing experience I would say JOBLIB is the way to go. If on the other hand there are assembler programs that use the fancy options of MVS then indeed steplib might be better. I would say as always it is installation dependent. Ed On Oct 26, 2013, at 9:58 AM, John Gilmore wrote: Almost all of these comments/conjectures are reasonable, commonsensical ones. My impression is, however, much like EJ's. Apart from silly configurations, e.g., a JOBLIB comprised of n concatenated libraries, a different one for each of n job steps, I have not noticed significant differences among configurations, even ugly ones. Anecdotage is never really very helpful in these situations. What are needed are some systematic, carefully designed, replicated measurements, separate ones for PDS- and PDSE-resident libraries. Any volunteers? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Ed [Gould], The COBOL shops---chiefly in insurance, banking, and communications---that I know well instead do use DYNAM heavily, often when there is no clear rationale for doing so. Even within a single shop, however, batch jobs are likely to differ significantly in 1) j how much they use execution-time load libraries and 2) which, if any, of these libraries they use. My plea was for measurements that would make better decisions among the available alternatives possible. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
John. The companies I have worked (except for one) were all COBOL. They learned early on that when one of the COBOL subroutines abended (started with the ILC modules if memory serves me)) at 0030 in the AM someone got rolled out of bed to fix it. COBOL programmers that I have worked for are risk adverse and did not want things like this to happen. They wanted an environment that once tested it worked *FOREVER* which was likely not to happen with DYNAM. Forget load module size they wanted write once run forever. They would much rather have a S0C4 in the daytime hours to debug than at 0030 . I have worked in banking (granted 40 years years ago) and the few COBOL programs that I was exposed to were linked statically and thus was standard. I personally have been rolled out at 0100 many times because of a S0CX in one of the cobol subroutines (I didn't write it the main program) since it was an IBM module I got called and had to hand hold the programmer to get it it running again. It was *usually* a combination of relinking a cross release of ILC programs that were were not friendly. Statically linked programs were also at risk but usually not to badly and were not fun to track down as a result, so there are no universal rules). It was simple to just recompile and relink all the programs in question. Assembler programmers were less likely to have issues as they were well aware of foreign changes and were not likes to point the finger at IBM software. I would have to disagree (to a point) about measurements for loadlibs because at several places I had QCM and it would publish numbers at step termination time about I/O times about JOBLIB/STEPLIB times and you could actually tell how how much time fetch took for each library. Granted QCM is no longer sold but we did use it to its full use when it was available. Ed On Oct 26, 2013, at 2:04 PM, John Gilmore wrote: Ed [Gould], The COBOL shops---chiefly in insurance, banking, and communications---that I know well instead do use DYNAM heavily, often when there is no clear rationale for doing so. Even within a single shop, however, batch jobs are likely to differ significantly in 1) j how much they use execution-time load libraries and 2) which, if any, of these libraries they use. My plea was for measurements that would make better decisions among the available alternatives possible. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In 526b3d6f.4060...@phoenixsoftware.com, on 10/25/2013 at 08:56 PM, Ed Jaffe edja...@phoenixsoftware.com said: I find this surprising. AFAIK, there is no substantive difference between JOBLIB and STEPLIB. The substantive difference is that STEPLIB affects only the one step. A BLDL against the linklist will be faster if there is no [JOB|STEP|TASK]LIB. There's a tradeoff between the overhead of steps with an unnecessary JOBLIB versus the overhead of multiple STEPLIB allocations. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Replying to a message from a few weeks ago; something just made me thing of it again. What are the performance implications that you refer to here? And what is your recommended alternative? A STEPLIB for every job step? I just read something interesting: http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zjcl/zjclc_jclEXECsearch.htm For a multi-step job, using the JOBLIB DD statement is most efficient when most of the programs reside in private libraries. For a multi-step job, using the STEPLIB DD statement is most efficient when most of the programs reside in system, rather than private, libraries. Frank From: Thomas Conley pinnc...@rochester.rr.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, September 24, 2013 10:35 AM Subject: Re: PDS/E, Shared Dasd, and COBOL V5 On 9/24/2013 12:31 PM, Frank Swarbrick wrote: These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our load library concatenation. We have the following member named 'PROD.APPLIB.INCLUDE(JOBLIB)': //JOBLIB DD DSN=EMER.APPLIB.LOAD,DISP=SHR // DD DSN=EMER.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.UTILLIB.LOAD,DISP=SHR // DD DSN=SYS6.IMP1.SDFSRESL,DISP=SHR // DD DSN=SYS6.IMP1.DYNLIB.BTCH,DISP=SHR // DD DSN=SYS3.DSN910.SDSNEXIT,DISP=SHR // DD DSN=SYS3.DSN910.SDSNLOAD,DISP=SHR // DD DSN=SYS3.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR // DD DSN=PROD.VISAEP4.RULES.LOAD,DISP=SHR // DD DSN=PROD.VISAEP4.LOAD,DISP=SHR In the JES2PARM member we have this: JOBLIBing everything has performance implications. We were also bit by this when they included an old SORT steplib in the concatenation and then SORT bombed on us. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In cae1xxdgic9qqvqanuhfogwd0a1id76qbj9tmznoxdcxkxwn...@mail.gmail.com, on 10/14/2013 at 10:25 PM, John Gilmore jwgli...@gmail.com said: As usual, Shmuel is making at once literalistic and sophomoric debater's points. PKB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In cae1xxdh_-+dmwfscc5e3pmclbs3mub7ttsaxi8pe3fuycve...@mail.gmail.com, on 10/13/2013 at 03:37 PM, John Gilmore jwgli...@gmail.com said: Does BSAM also adjust the zero-origin address offsets in that load module to reflect its 'load address'? Does BSAM look up a pay grade in order to determine a pay rate? Its function is to read records; what to do with those records is up to the program using it. That applies to reading load modules as much as to reading payroll files. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In CAE1XxDFeYeqAej1CsYx5TajONSTssa7kLi-iDMUf6=buzsc...@mail.gmail.com, on 10/13/2013 at 11:44 AM, John Gilmore jwgli...@gmail.com said: As he often does, he is here employing an irrelevance Is is often the case, you are confusing a crucial point with an irrelevance. Analogously, Shmuel uses IBM-MAIN not to contribute and learn but to find text in others' posts that he can use to score debaters' points. Well, one of us does. I have, e.g., provided sample code and quotes from manuals on occasion. What does, however, need to be said about his posts is that they are not, finally, seriös. You are entitled to your delusions. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 10/12/2013 3:04 PM, R.S. wrote: Special does not mean new or innovative. PDSE is 20+ yo, but still under construction, and still undocumented (I mean free documentation). My whisky is also 20+ yo, but *it works*. ;-))) We have used PDSE almost exclusively since the mid-1990s. If a PDS is restored from a backup, it is still a PDS. But, if a PDS is allocated new, it is automatically allocated as DSNTYPE=LIBRARY. Now and then, we run into some utility or another that doesn't work well (or at all) with PDSE. In such cases, we use DSNTYPE=PDS to force the allocation to PDS. Otherwise, very few issues. We had some ongoing problems that chronically affected our largest PDSEs and so we thought PDSE was to blame for many months but, in the end, those problems turned out to be associated with EAV and ADRDSSU CONSOLIDATE processing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
As usual, Shmuel is making at once literalistic and sophomoric debater's points. As my earlier posts emphasized, load modules contain a mixture of text and control information (not necessarily in alternating blocks). Justice Holmes famously observed that freedom of thought is freedom for the thought that we hate. Equally, it is freedom for the thought that we judge ridiculous. Shmuel thus is and should be free to make himself ridiculous here. Still, it is melancholy that someone who has done good work should have been reduced to such posturing. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In cae1xxdg+wpq27ohberb7yrwtkp4ehr3tsxkjrwifkgmqn6y...@mail.gmail.com, on 10/12/2013 at 08:42 AM, John Gilmore jwgli...@gmail.com said: A load-module image is not simply relocated in memory with ADCONs appropriately incremented. Very complex processing of a mixture of text and control information is performed. Nonsense; the only real complexity is in scatter load. The complexity in fetch is due to attempts to improve performance. and neither BSAM nor QSAM can make any sense of either a load-module PDS member BSAM and QSAM read load modules just fine, TYVM. I've been using them for decades. but it is not really very responsive. I notice that you didn't provide any details either, presumably for the same reason; you would have had to include a lot of background that would have been TMI. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I don't know about OGET or OPUT, but cp and mv will invoke the binder 'under the covers' to move a program object in a Unix File System to a PDSE. Date: Sat, 12 Oct 2013 14:26:19 -0400 From: John Gilmore jwgli...@gmail.com Subject: Re: PDS/E, Shared Dasd, and COBOL V5 I omitted in my last post to answer the question Is there an IBM utility that is smart enough to make a UNIX executable into a program object in a PDSE? There is|are. The z/OS UNIX System Services commands cp and mv and the TSO commands OGET and OPUT can do the necessary conversions in both directions. ---jg -- Tom Russell “Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear “... and remember to leave good news alone.” — Gracie HeavyHand -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In 52596efe.2070...@bremultibank.com.pl, on 10/12/2013 at 05:47 PM, R.S. r.skoru...@bremultibank.com.pl said: What I'm sure is other operating systems use neither PDSE nor PDS and are quite happy. Those other systems use equivalents of Unix file systems, not record oriented file systems, to provide the equivalent of program objects. Bind your programs into z/OS Unix files and z/OS will be quite happy as well. Last, but not least: despite of black-magic format and features of PDSE is just some set of bytes resining on disk, nothing more. ROTF,LMAO! -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In 52594dde.3030...@phoenixsoftware.com, on 10/12/2013 at 06:25 AM, Ed Jaffe edja...@phoenixsoftware.com said: This is one of the big benefits of COBOL V5's use of program objects and PDSE. A COBOL V5 program's debugging information is packaged with the program object member alongside its object code, but is not loaded into virtual memory unless or until requested by a debugger or dump analyzer. The same is true of debug information in a load module, although the interface for program objects is cleaner. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In 545411607-1381595947-cardhu_decombobulator_blackberry.rim.net-1481781966-@b4.c1.bise6.blackberry, on 10/12/2013 at 04:39 PM, Ted MacNEIL eamacn...@yahoo.ca said: PDSE is over 20 years old! What makes it 'special' after all this time? What makes it a sports car? Who called it special? The point is not that it is special, but that it is different in a way that makes some things easier. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In 013801cec761$5e79f890$1b6de9b0$@mcn.org, on 10/12/2013 at 08:40 AM, Charles Mills charl...@mcn.org said: Is there any reason that a PDS, RECFM=U or Vxx with half-track or 4K or whatever records or blocks, could not store *exactly* the same stream of bytes as a UNIX file, and with no reliance on any special directory structure? No, but that's the wrong question. The correct question is whether doing so would accomplish what you want, and the answer is a resounding no. I am too lazy to do the experiment, but I'll bet you could take a COBOL 5 or other program object in a UNIX file, copy with some ignorant of any special details program from UNIX to a PDS member such as I describe above, copy it back to a UNIX file, and have it be indistinguishable from the original program object -- including being executable? Yes, assumong that you make it executable. If so, does it not prove that there is no technological reason that a program object could not reside in a PDS? No, unless it was FBS. More precisely, the performance would be grossly unacceptable. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In 4155755931776698.wa.paulgboulderaim@listserv.ua.edu, on 10/12/2013 at 11:43 AM, Paul Gilmartin paulgboul...@aim.com said: Shmuel may distrust IEBGENER to that extent; Or he may not. Is there anything in any message that I have ever posted to suggest that I don't trust IEBGENER to make an accurate copy of a flat file? Now you might find some old messages referring to the way that IEBGENER handles DCB attributes, or what it does if SYSUT2 specifies a PDS without a member name, but neither of those is remotely similar to the issue of a simple copy. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Sun, 13 Oct 2013 11:59:41 -0400, John Gilmore wrote: Tom Russell is of course right about this. The work that cp and mv and OGET and OPUT too appear to be doing is all done under the covers by the Binder. (Add IEBCOPY and/or whatever ISPF uses) I wonder, though, do these explictly ATTACH the Binder, or do they use the Program Management API (as I suspect AMBLIST and AMASPZAP do nowadays) to manipulate program objects). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 10/13/2013 11:44 AM, John Gilmore wrote: The substance of what he says is a reminder that BSAM and QSAM can read RECFM=U records. This is certainly true, just as it is true that the earth is an oblate spheroid. As he often does, he is here employing an irrelevance to suggest that he has caught a poster, me in this case, in a blunder. Since we are picking nits, it is commonly accepted that the Earth is pear shaped, rather than an oblate spheroid. His second assertion, that he has been using 'them', BSAM and QSAM, for decades, is certainly true too. Sequential I/O can scarcely be avoided. It too, however, is irrelevant. He has not been using them to bring load modules or program objects into storage for execution because they cannot be used for this purpose. While I haven't kept up with what he's doing lately, I have a subroutine (cbt file 860, SUBFETCH) that uses BSAM to bring a load module into storage and execute it. I originally wrote it to test whether a module in storage was altered by loading a second copy, but using the first's relocation factor. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Gerhard Postpischil wrote begin exctract While I haven't kept up with what he's doing lately, I have a subroutine (cbt file 860, SUBFETCH) that uses BSAM to bring a load module into storage and execute it. I originally wrote it to test whether a module in storage was altered by loading a second copy, but using the first's relocation factor. end extract/ Does BSAM also adjust the zero-origin address offsets in that load module to reflect its 'load address'? Since BSAM reads one block at a time, does it also arrange successive blocks, appropriately aligned, in storage? Und so weiter . . . I can imagine using BSAM to read a RECFM=U member of a PDS[E]. I can imagine the further processing that would be required to make it executable too, and the second is a good deal more onerous than the first. My geodesist colleagues teach their students that the earth is a [very slightly] oblate spheroid. By switching axes it can also of course be described as a prolate ellipsoid, The NGS Geodetic Glossary of 2009 also describes the earth as an oblate spheroid The conjecture that the earth is pear shaped, in the jargon a Poincaré piriform body, is not, I am told, really valid, although it would be if the gravitational field in which the earth moves were somewhat different. Googling 'pear shaped earth' does, however, suggest that there are people who think that the earth is indeed pear-shaped; but thisa is not so helpful as it might be: there are others out there, more of them, who think it is flat. I will consult the three geodesy/geodetics specialists I know and report a consensus here if there is one. These things said, Gerhard's defense of his quondam colleague is at once ingenious and morally admirable. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Sunday, October 13, 2013 12:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 W dniu 2013-10-12 18:39, Ted MacNEIL pisze: PDSE is over 20 years old! What makes it 'special' after all this time? Welcome to the 1990-s! Special does not mean new or innovative. PDSE is 20+ yo, but still under construction, and still undocumented (I mean free documentation). My whisky is also 20+ yo, but *it works*. ;-))) Have you done a double blind test ? ;) Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 10/13/2013 3:37 PM, John Gilmore wrote: Does BSAM also adjust the zero-origin address offsets in that load module to reflect its 'load address'? Since BSAM reads one block at a time, does it also arrange successive blocks, appropriately aligned, in storage? Und so weiter . . . Your statement was It too, however, is irrelevant. He has not been using them to bring load modules or program objects into storage for execution because they cannot be used for this purpose. This is false by demonstration. If you meant that BSAM alone, without additional code, cannot be used, then we are in agreement. But by the same token IEWFETCH does not use EXCP alone to load. I can imagine using BSAM to read a RECFM=U member of a PDS[E]. I can imagine the further processing that would be required to make it executable too, and the second is a good deal more onerous than the first. For a module not overlay or scatter-load the code is near trivial. My geodesist colleagues teach their students that the earth is a [very slightly] oblate spheroid. By switching axes it can also of course be described as a prolate ellipsoid, The NGS Geodetic Glossary of 2009 also describes the earth as an oblate spheroid A quick search turns up that the north pole is about 45 meters farther from the center than the south pole. This makes absolutely no difference to anyone not engaged in hair-splitting arguments. And it's completely unrelated to Poincaré's piriform conjecture that has not been taken seriously for a couple of centuries. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
'Piriform' means pear shaped, as I suspect you know. I have clearly made you very angry, so angry that you are incoherent. No failure to take a conjecture of Henri Poincaré, 1854-1912, seriously two centuries ago would have been possible without preternatural prescience of a ,kind neither of us believes in. Let's stop (after any rebuttal you judge necessary). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In a18c3cda-9db5-41e9-9df6-bcead854e...@aim.com, on 10/10/2013 at 07:57 PM, Paul Gilmartin paulgboul...@aim.com said: Bits is bits. A UNIX file is simply a flat linear file; A PDS member is not a flat linear file. Why couldn't the same information be stored in a PDS? Because a PDS member doesn't have the right structure. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
We need some distinctions here. A PDS member containing a source program or an object module is not different internally from a 'flat file' containing the same card images. Such a member can be read by BSAM or QSAM A PDS member containing a load module has a very different, hybrid makeup comprised of an unholy mixture of text for loading and channel-program fragments used in loading this text into and initializing other blocks of storage within an in-storage load module. A load-module image is not simply relocated in memory with ADCONs appropriately incremented. Very complex processing of a mixture of text and control information is performed. A PDSE member containing a program object has a very different, and very sketchily documented, mixed internal structure. Moreover, the loading of some of its text elements may be deferred until they are required|requested. BPAM, which reads both with different expectations for each, is not equipped to read flat files; and neither BSAM nor QSAM can make any sense of either a load-module PDS member or a very differently organized program-object PDSE member. Paul Gilmartin's question, | Why couldn't the same information [a program | object] be stored in a PDS? thus misses the mark. Shmuel Metz's response to that question, | Because a PDS member doesn'y have the | right structure. is of course correct or so nearly so as makes no difference, but it is not really very responsive. I am reminded of Moliere's physician who, asked how sleeping draughts functioned, replied that their effectiveness was due to their dormitive powers. That said, I can feel considerable sympathy for Shmuel's response if he judged, as I do, that Paul's question was at least in part tendentious. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 10/12/2013 5:42 AM, John Gilmore wrote: A PDSE member containing a program object has a very different, and very sketchily documented, mixed internal structure. Moreover, the loading of some of its text elements may be deferred until they are required|requested. This is one of the big benefits of COBOL V5's use of program objects and PDSE. A COBOL V5 program's debugging information is packaged with the program object member alongside its object code, but is not loaded into virtual memory unless or until requested by a debugger or dump analyzer. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Is there any reason that a PDS, RECFM=U or Vxx with half-track or 4K or whatever records or blocks, could not store *exactly* the same stream of bytes as a UNIX file, and with no reliance on any special directory structure? I am too lazy to do the experiment, but I'll bet you could take a COBOL 5 or other program object in a UNIX file, copy with some ignorant of any special details program from UNIX to a PDS member such as I describe above, copy it back to a UNIX file, and have it be indistinguishable from the original program object -- including being executable? If so, does it not prove that there is no technological reason that a program object could not reside in a PDS? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Friday, October 11, 2013 8:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 In a18c3cda-9db5-41e9-9df6-bcead854e...@aim.com, on 10/10/2013 at 07:57 PM, Paul Gilmartin paulgboul...@aim.com said: Bits is bits. A UNIX file is simply a flat linear file; A PDS member is not a flat linear file. Why couldn't the same information be stored in a PDS? Because a PDS member doesn't have the right structure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
W dniu 2013-10-12 17:40, Charles Mills pisze: Is there any reason that a PDS, RECFM=U or Vxx with half-track or 4K or whatever records or blocks, could not store *exactly* the same stream of bytes as a UNIX file, and with no reliance on any special directory structure? I am too lazy to do the experiment, but I'll bet you could take a COBOL 5 or other program object in a UNIX file, copy with some ignorant of any special details program from UNIX to a PDS member such as I describe above, copy it back to a UNIX file, and have it be indistinguishable from the original program object -- including being executable? If so, does it not prove that there is no technological reason that a program object could not reside in a PDS? What I'm sure is other operating systems use neither PDSE nor PDS and are quite happy. They also have various program formats, debugging information, etc. etc. Last, but not least: despite of black-magic format and features of PDSE is just some set of bytes resining on disk, nothing more. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
PDSE is over 20 years old! What makes it 'special' after all this time? Welcome to the 1990-s! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Charles Mills charl...@mcn.org Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Sat, 12 Oct 2013 08:40:24 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Is there any reason that a PDS, RECFM=U or Vxx with half-track or 4K or whatever records or blocks, could not store *exactly* the same stream of bytes as a UNIX file, and with no reliance on any special directory structure? I am too lazy to do the experiment, but I'll bet you could take a COBOL 5 or other program object in a UNIX file, copy with some ignorant of any special details program from UNIX to a PDS member such as I describe above, copy it back to a UNIX file, and have it be indistinguishable from the original program object -- including being executable? If so, does it not prove that there is no technological reason that a program object could not reside in a PDS? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Friday, October 11, 2013 8:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 In a18c3cda-9db5-41e9-9df6-bcead854e...@aim.com, on 10/10/2013 at 07:57 PM, Paul Gilmartin paulgboul...@aim.com said: Bits is bits. A UNIX file is simply a flat linear file; A PDS member is not a flat linear file. Why couldn't the same information be stored in a PDS? Because a PDS member doesn't have the right structure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Sat, 12 Oct 2013 08:42:02 -0400, John Gilmore wrote: A PDSE member containing a program object has a very different, and very sketchily documented, mixed internal structure. Moreover, the loading of some of its text elements may be deferred until they are required|requested. sketchily documented by intent. At SHARE Denver, John E. practically boasted that IBM would not make the same mistake with program objects, of docmenting that structure and allowing customers and ISVs to come to rely on it, making it impossible for IBM to change the specification. BPAM, which reads both with different expectations for each, is not equipped to read flat files; and neither BSAM nor QSAM can make any No. BPAM is capable of reading (but not writing) base members of UNIX directories. I hope we can agree that those members (though not the directories) are flat files. sense of either a load-module PDS member or a very differently organized program-object PDSE member. Paul Gilmartin's question, | Why couldn't the same information [a program | object] be stored in a PDS? thus misses the mark. Shmuel Metz's response to that question, | Because a PDS member doesn'y have the | right structure. is of course correct or so nearly so as makes no difference, but it is not really very responsive. I am reminded of Moliere's physician who, asked how sleeping draughts functioned, replied that their effectiveness was due to their dormitive powers. That said, I can feel considerable sympathy for Shmuel's response if he judged, as I do, that Paul's question was at least in part tendentious. No. The experiment that R.S. hinted at, and Charles lacked the stamina to do: //GEN1 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=(,) //SYSIN DD * //SYSUT2DD DISP=(,PASS),UNIT=SYSDA,SPACE=(1000,(1000,,5)), // DSNTYPE=PDS,DSN=amp;FLAT(TEMP) //SYSUT1DD PATHOPTS=ORDONLY,PATH='XDIR/tiny', // RECFM=VB,LRECL=1000,BLKSIZE=32760 //* //GEN2 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=(,) //SYSIN DD * //SYSUT2DD PATHOPTS=(ORDWR,OTRUNC,OCREAT), // PATHMODE=SIRWXU,PATH='XDIR/tiny2' //SYSUT1DD DISP=(OLD,PASS),DSN=amp;FLAT(TEMP) //* //UNIX EXEC PGM=BPXBATCH, // PARM='SH cd XDIR; cksum tiny tiny2; ./tiny2 amp;amp; echo ∎' //* PARM='SH cd XDIR; cksum tiny tiny2; ./tiny2 amp;amp; echo ∎' //STDIN DD PATHOPTS=ORDONLY,PATH='/dev/./null' //STDOUT DD SYSOUT=(,) //STDERR DD SYSOUT=(,) // ... produces in STDOUT: pgilmart@brm3:198$ cat 106.STDOUT.txt 3496628668 86016 tiny 3496628668 86016 tiny2 Hello, world! ∎ I suppose you might insist that IEBGENER in the second step somehow reconstituted the black-magic format of a program object that had (temporarily) resided as a flat file in a PDS Shmuel may distrust IEBGENER to that extent; I don't. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Paul, While I am NOT a fan of PDSE's, I believe that there are entries in the PDSE directory (ie entries GT 9 bytes) that cannot be contained in a normal PDS directory. Or there are items that cannot be contained in a PDS directory. Such items as an entry point in c++ (or any other program) might be entry_for_my_pgm_named_gil (or some such name). Ed On Oct 12, 2013, at 11:43 AM, Paul Gilmartin wrote: On Sat, 12 Oct 2013 08:42:02 -0400, John Gilmore wrote: A PDSE member containing a program object has a very different, and very sketchily documented, mixed internal structure. Moreover, the loading of some of its text elements may be deferred until they are required|requested. sketchily documented by intent. At SHARE Denver, John E. practically boasted that IBM would not make the same mistake with program objects, of docmenting that structure and allowing customers and ISVs to come to rely on it, making it impossible for IBM to change the specification. BPAM, which reads both with different expectations for each, is not equipped to read flat files; and neither BSAM nor QSAM can make any No. BPAM is capable of reading (but not writing) base members of UNIX directories. I hope we can agree that those members (though not the directories) are flat files. sense of either a load-module PDS member or a very differently organized program-object PDSE member. Paul Gilmartin's question, | Why couldn't the same information [a program | object] be stored in a PDS? thus misses the mark. Shmuel Metz's response to that question, | Because a PDS member doesn'y have the | right structure. is of course correct or so nearly so as makes no difference, but it is not really very responsive. I am reminded of Moliere's physician who, asked how sleeping draughts functioned, replied that their effectiveness was due to their dormitive powers. That said, I can feel considerable sympathy for Shmuel's response if he judged, as I do, that Paul's question was at least in part tendentious. No. The experiment that R.S. hinted at, and Charles lacked the stamina to do: //GEN1 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=(,) //SYSIN DD * //SYSUT2DD DISP=(,PASS),UNIT=SYSDA,SPACE=(1000,(1000,,5)), // DSNTYPE=PDS,DSN=amp;FLAT(TEMP) //SYSUT1DD PATHOPTS=ORDONLY,PATH='XDIR/tiny', // RECFM=VB,LRECL=1000,BLKSIZE=32760 //* //GEN2 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=(,) //SYSIN DD * //SYSUT2DD PATHOPTS=(ORDWR,OTRUNC,OCREAT), // PATHMODE=SIRWXU,PATH='XDIR/tiny2' //SYSUT1DD DISP=(OLD,PASS),DSN=amp;FLAT(TEMP) //* //UNIX EXEC PGM=BPXBATCH, // PARM='SH cd XDIR; cksum tiny tiny2; ./tiny2 amp;amp; echo ∎' //* PARM='SH cd XDIR; cksum tiny tiny2; ./tiny2 amp;amp; echo ∎' //STDIN DD PATHOPTS=ORDONLY,PATH='/dev/./null' //STDOUT DD SYSOUT=(,) //STDERR DD SYSOUT=(,) // ... produces in STDOUT: pgilmart@brm3:198$ cat 106.STDOUT.txt 3496628668 86016 tiny 3496628668 86016 tiny2 Hello, world! ∎ I suppose you might insist that IEBGENER in the second step somehow reconstituted the black-magic format of a program object that had (temporarily) resided as a flat file in a PDS Shmuel may distrust IEBGENER to that extent; I don't. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Right, of course. But the point is that that magic could just as easily be contained in the body of any file, as it is in a UNIX file, even if that file were a PDS member (or, for that matter, a non-PDS QSAM/BSAM dataset). Okay, the next pointless experiment I am too lazy to do: You could make a wrapper PROC that would give the illusion of executing a program object from a PDS by copying it to a UNIX file first. Hmmm, I guess you can only run UNIX files from the shell, not EXEC PGM=, so the experiment is really pointless. Is there an IBM utility that is smart enough to make a UNIX executable into a program object in a PDSE? If so, then you could do it: //STEP1 EXEC OBJEXEC,EXECPGM=MYPROG //STEPLIB DD MY.BASIC.PDS,DISP=SHR Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Saturday, October 12, 2013 10:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Paul, While I am NOT a fan of PDSE's, I believe that there are entries in the PDSE directory (ie entries GT 9 bytes) that cannot be contained in a normal PDS directory. Or there are items that cannot be contained in a PDS directory. Such items as an entry point in c++ (or any other program) might be entry_for_my_pgm_named_gil (or some such name). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I have just read Paul's most recent post. I find that I do not agree with even one of his contentions. Worse, I discover that I lack the patience to attempt another detailed exposition of what I take to be his misapprehensions. Exit jg. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 10/12/2013 12:39 PM, Ted MacNEIL wrote: PDSE is over 20 years old! What makes it 'special' after all this time? Welcome to the 1990-s! People are funny that way. Note that a bridge built in the fourteenth century is still called Newbridge: http://en.wikipedia.org/wiki/Newbridge,_Oxfordshire) Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I omitted in my last post to answer the question Is there an IBM utility that is smart enough to make a UNIX executable into a program object in a PDSE? There is|are. The z/OS UNIX System Services commands cp and mv and the TSO commands OGET and OPUT can do the necessary conversions in both directions. ---jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Sat, 12 Oct 2013 14:26:19 -0400, John Gilmore wrote: There is|are. The z/OS UNIX System Services commands cp and mv and the TSO commands OGET and OPUT can do the necessary conversions in both directions. And, of course Binder, which I suspect all the others (along with IEBCOPY) invoke internally. But once it's in a UNIX file, the exec() facility and its brethren can bring it directly into storage for execution (even they could invoke Program Management internally). On Sat, 12 Oct 2013 14:13:46 -0400, John Gilmore wrote: I have just read Paul's most recent post. I find that I do not agree with even one of his contentions. Not even that I submitted the JCL I appended and that it produced the output that I appended? ... Exit jg. Nyah! Nyah! Nyah! I can't hear you! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I said 'his contentions'. I did not suggest and do not think that your example was inaccurate. I could produce abundant counter examples, and we should then be reduced to arguing about their essential and inessential features. A slip path does not establish a generality, although it does in some sense establish the existence of at least one black swan. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
W dniu 2013-10-12 18:39, Ted MacNEIL pisze: PDSE is over 20 years old! What makes it 'special' after all this time? Welcome to the 1990-s! Special does not mean new or innovative. PDSE is 20+ yo, but still under construction, and still undocumented (I mean free documentation). My whisky is also 20+ yo, but *it works*. ;-))) -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 2013-10-10, at 18:19, Shmuel Metz (Seymour J.) wrote: Actually, I don't believe program objects are required to reside in PDSEs, They may be allowed in a Unix file, but they are not allowed in a PDS, not do I see how they could be allowed. Bits is bits. A UNIX file is simply a flat linear file; a program object there has no dependencies on extended attributes. Why couldn't the same information be stored in a PDS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Tue, 24 Sep 2013 08:47:24 -0400, Farley, Peter x23353 wrote: Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Actually, I don't believe program objects are required to reside in PDSEs, or does COBOL impose this as an additional requirement? (Of course there's a drawback: program objects not in PDSes are not readily accessible to LOAD/LINK/ATTACH/XCTL facilities.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 10/9/2013 2:19 PM, Paul Gilmartin wrote: On Tue, 24 Sep 2013 08:47:24 -0400, Farley, Peter x23353 wrote: Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Actually, I don't believe program objects are required to reside in PDSEs, or does COBOL impose this as an additional requirement? Program objects may reside in z/OS UNIX files. (Of course there's a drawback: program objects not in PDSes are not readily accessible to LOAD/LINK/ATTACH/XCTL facilities.) -- gil However, COBOL calling programs could use the BPX1LOD service to LOAD an executable stored as a z/OS UNIX file (COBOL can't ATTACH or XCTL anyway). Then COBOL 'CALL data-item' can invoke the loaded module. How to do this is covered in our three day course Developing Applications for z/OS UNIX. See http://www.trainersfriend.com/UNIX_and_Web_courses/u520descr.htm for details on the course. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * We are going out of business effective 30 December, 2013 * To purchase a set of our training materials at terrific prices, check out our Going Out Of Business Sale: http://www.trainersfriend.com/SpecialSale -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Wed, 9 Oct 2013 15:01:16 -0600, Steve Comstock wrote: However, COBOL calling programs could use the BPX1LOD service to LOAD an executable stored as a z/OS UNIX file (COBOL can't ATTACH or XCTL anyway). Then COBOL 'CALL data-item' can invoke the loaded module. I wonder why the initiator doesn't do similarly on finding a UNIX executable in the STEPLIB concatenation. Oops! Another glitch! Works OK when the entry point offset is 0; gets S0C1 when entry point offset != 0. How to do this is covered in our three day course Developing Applications for z/OS UNIX. See http://www.trainersfriend.com/UNIX_and_Web_courses/u520descr.htm for details on the course. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I you don't know/have control of which jobs/JCLs that are submitted/run on your systems, would not a logging function in a JES2 exit be a point ? I don't know the technical feasibility of this or if such a function already exist (at CBTTAPE or commercial) but wouldn't that be a great help generally ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, September 24, 2013 7:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 That is a well designed system, but IIRC you had the luxury to do it right the first time when you migrated from z/VSE to z/OS. Shops that have been MVS / z/OS since the dawn of time have literally decades of old JCL written to now-obsolete standards to contend with, much of which runs unchanged because it still just works. I am not saying this conversion cannot be done, even on a job-by-job basis within particular business applications, but the investment in the SCLM changes is not trivial either, and those changes must support the old compiler as well as the new one so that emergency oh-dark-30 fixes to unconverted code can be made in a timely manner without using the new compiler processes and libraries. I suspect that many large shops will be paying for two compiler versions for quite a long time. Good for IBM, not so good for their customers. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, September 24, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our load library concatenation. Details snipped My point here being that if we needed to add a new application load library to our environment all we need to do is modify 'PROD.APPLIB.INCLUDE(JOBLIB)' and 'PGMR.APPLIB.INCLUDE(JOBLIB)' to add the new library. Frank From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, September 24, 2013 6:47 AM Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, to use the process you describe there are literally hundreds of thousands of JCL's to be changed, and tens of thousands of PROC's, and that is just one large shop. The only zones are QA and Production, shared by all applications. Where do you start such a project? The cost of regression testing alone is huge, especially in already CPU- constrained testing environments. New business lines, new regulatory issues, new clients: All these will take precedence over any kind of maintenance project, whatever the eventual ROI might be. Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Will-we-nil-we, I suppose we will eventually get there, but it's not going to be quick or easy, and far, far from cheap. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, September 24, 2013 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Monday, September 23, 2013 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 If you set up new PDS/E program libraries for only V5 program code, then any time maintenance on a COBOL program is done the maintainer must be aware whether this is the first time this program has compiled with V5 and if so, be sure any related production JCL gets changed to reference the new library in sync with the program installation and be sure the obsolete load module in some PDS gets purged at the same time to prevent possible execution of obsolete code. How about if shops start changing COBOL build processes today to use PDSE datasets for COBOL V4 (or COBOL 3) programs? Step 1 would be to allocate new PDSE
Re: PDS/E, Shared Dasd, and COBOL V5
Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Monday, September 23, 2013 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 If you set up new PDS/E program libraries for only V5 program code, then any time maintenance on a COBOL program is done the maintainer must be aware whether this is the first time this program has compiled with V5 and if so, be sure any related production JCL gets changed to reference the new library in sync with the program installation and be sure the obsolete load module in some PDS gets purged at the same time to prevent possible execution of obsolete code. How about if shops start changing COBOL build processes today to use PDSE datasets for COBOL V4 (or COBOL 3) programs? Step 1 would be to allocate new PDSE datasets for each zone of load libraries Step 2 would be to add the new PDSE dataset(s) to load library concatenations where needed. If put first it would guarantee access to new programs. Step 3 would be to change build processes to link old COBOL programs into PDSEs. Step 4 would be to make sure this works for all systems and that old (unreachable) programs get deleted from PDS datasets Step 5 from time to time, move needed load modules from PDSs to PDSEs until all are moved. Step 6 when all code has been moved, the only programs in PDS should be unused, and the PDS datasets could be deleted If this plan was used, the COBOL V5 PDSE requirement would not be disruptive. My question, is it do-able? Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Tom, to use the process you describe there are literally hundreds of thousands of JCL's to be changed, and tens of thousands of PROC's, and that is just one large shop. The only zones are QA and Production, shared by all applications. Where do you start such a project? The cost of regression testing alone is huge, especially in already CPU-constrained testing environments. New business lines, new regulatory issues, new clients: All these will take precedence over any kind of maintenance project, whatever the eventual ROI might be. Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Will-we-nil-we, I suppose we will eventually get there, but it's not going to be quick or easy, and far, far from cheap. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, September 24, 2013 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Monday, September 23, 2013 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 If you set up new PDS/E program libraries for only V5 program code, then any time maintenance on a COBOL program is done the maintainer must be aware whether this is the first time this program has compiled with V5 and if so, be sure any related production JCL gets changed to reference the new library in sync with the program installation and be sure the obsolete load module in some PDS gets purged at the same time to prevent possible execution of obsolete code. How about if shops start changing COBOL build processes today to use PDSE datasets for COBOL V4 (or COBOL 3) programs? Step 1 would be to allocate new PDSE datasets for each zone of load libraries Step 2 would be to add the new PDSE dataset(s) to load library concatenations where needed. If put first it would guarantee access to new programs. Step 3 would be to change build processes to link old COBOL programs into PDSEs. Step 4 would be to make sure this works for all systems and that old (unreachable) programs get deleted from PDS datasets Step 5 from time to time, move needed load modules from PDSs to PDSEs until all are moved. Step 6 when all code has been moved, the only programs in PDS should be unused, and the PDS datasets could be deleted If this plan was used, the COBOL V5 PDSE requirement would not be disruptive. My question, is it do-able? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Peter, In reality it is just time. Converting the libraries from PDS to PDSE can proceduralized to some extent. Probably north of 90% of the libraries can be hit an an appropriate time, and the remaining hard to get ones will take some special actions to get them when they are free. One of the biggies for us is not just the conversion, but how much space to add to the datasets to accommodate over time the larger load module sizes for the debug information. Additional heartburn for us is all the new AMODE/RMODE restrictions that is going to force quite a bit of analysis and research. We won't do a recompile everything approach, that is too high risk. And I am sure we have some amount of the stuff that incompatible according to the migration guide. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, September 24, 2013 8:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, to use the process you describe there are literally hundreds of thousands of JCL's to be changed, and tens of thousands of PROC's, and that is just one large shop. The only zones are QA and Production, shared by all applications. Where do you start such a project? The cost of regression testing alone is huge, especially in already CPU-constrained testing environments. New business lines, new regulatory issues, new clients: All these will take precedence over any kind of maintenance project, whatever the eventual ROI might be. Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Will-we-nil-we, I suppose we will eventually get there, but it's not going to be quick or easy, and far, far from cheap. Peter This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
JCL includes? snip For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Not sure what your question is. Converting the libraries in place won't affect JCL includes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Tuesday, September 24, 2013 9:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 JCL includes? snip For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
If the procs/jobs etc were to include the joblibs/steplibs via the JCL INCLUDE statement, instead of explicit coding, there would be only 1 item to change (per application silo), the included member containing the joblib/steplib concatenation. 'Sorry for the confusion. snip Not sure what your question is. Converting the libraries in place won't affect JCL includes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Tuesday, September 24, 2013 9:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 JCL includes? snip For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. /snip /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Ah, gotcha. Yes you are right. In our case, we have JCL coming from multiple places, including submits from within CICS. Not even sure we could track down all the source JCL easily. That's why for us converting the datasets in place is the only option. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Tuesday, September 24, 2013 10:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 If the procs/jobs etc were to include the joblibs/steplibs via the JCL INCLUDE statement, instead of explicit coding, there would be only 1 item to change (per application silo), the included member containing the joblib/steplib concatenation. 'Sorry for the confusion. snip Not sure what your question is. Converting the libraries in place won't affect JCL includes. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Tuesday, September 24, 2013 9:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 JCL includes? snip For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. /snip /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Tue, 24 Sep 2013 12:55:45 +, Jousma, David wrote: ... new AMODE/RMODE restrictions ... I hadn't noticed. What do you mean? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
See Ch16 of the migration guide. I don’t think there is a lot of this, but there could be some. I had opened a PMR with IBM with questions about all of this, and one of my questions was whether or not these restrictions were new to COBOL V5 or if the same restrictions were in place as part of the migration to ENT COB V4. I was told these are all new restrictions. Here is a snippet: Link-editing restriction: You can not mix Enterprise COBOL V 5.1 programs with: v OS/VS COBOL programs. You must migrate to Enterprise COBOL. To find any OS/VS COBOL programs you can: – use the LMA tool of Debug Tool to scan load libraries for OS/VS COBOL programs – use the Edge Portfolio Analyzer to scan load libraries for OS/VS COBOL programs – install the fix for APAR PM86742 to your Language Environment and look for a Warning message about detected OS/VS COBOL programs at run time v VS COBOL II NORES programs. You must migrate to Enterprise COBOL. AMODE restrictions with Enterprise COBOL Version 5 programs: v AMODE 24 execution of programs compiled with Enterprise COBOL V5 is no longer supported. v Enterprise COBOL V5 program objects must have AMODE 31. v Enterprise COBOL V5 entry points will be assigned attribute AMODE 31 by the binder by default. Explicit binder override to AMODE 24 or AMODE ANY is not supported. v Enterprise COBOL V5 object programs cannot be link-edited together with and statically CALL to or from AMODE 24 object programs. RMODE restrictions with Enterprise COBOL Version 5 programs: v Reentrant programs may be RMODE 24 or RMODE ANY v Non-reentrant programs must be RMODE 24. Enterprise COBOL V5 programs continue to support dynamic CALL to or from AMODE 24 programs. For example: v Enterprise COBOL V5 programs may dynamically CALL AMODE 24 programs created by prior versions of Enterprise COBOL. v AMODE 24 COBOL programs created by prior versions of Enterprise COBOL may dynamically CALL Enterprise COBOL V5 programs. v Enterprise COBOL V5 programs may dynamically CALL AMODE 24 assembler language programs. AMODE and RMODE considerations Static calls between AMODE 24 and AMODE 31 programs are not supported with Enterprise COBOL V5. In addition, NORENT programs can no longer reside above the line. The following diagram shows the types of calls that can be dynamic or static and those that can only be dynamic. It also shows configurations of data and program location with respect to the 16 GB line. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Tuesday, September 24, 2013 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 On Tue, 24 Sep 2013 12:55:45 +, Jousma, David wrote: ... new AMODE/RMODE restrictions ... I hadn't noticed. What do you mean? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our load library concatenation. We have the following member named 'PROD.APPLIB.INCLUDE(JOBLIB)': //JOBLIB DD DSN=EMER.APPLIB.LOAD,DISP=SHR // DD DSN=EMER.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.UTILLIB.LOAD,DISP=SHR // DD DSN=SYS6.IMP1.SDFSRESL,DISP=SHR // DD DSN=SYS6.IMP1.DYNLIB.BTCH,DISP=SHR // DD DSN=SYS3.DSN910.SDSNEXIT,DISP=SHR // DD DSN=SYS3.DSN910.SDSNLOAD,DISP=SHR // DD DSN=SYS3.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR // DD DSN=PROD.VISAEP4.RULES.LOAD,DISP=SHR // DD DSN=PROD.VISAEP4.LOAD,DISP=SHR In the JES2PARM member we have this: PROCLIB(APPL) DD(1)=(DSNAME=EMER.APPLIB.PROC), DD(2)=(DSNAME=EMER.PEPLIB.PROC), DD(3)=(DSNAME=PROD.APPLIB.INCLUDE), DD(4)=(DSNAME=PROD.APPLIB.PROC), DD(5)=(DSNAME=PROD.PEPLIB.PROC),UNCOND And our jobs look something like this: //DDAR04 JOB ,'DDAR04' //*--* /*JOBPARM PROCLIB=APPL // SET LOADENV=PROD // INCLUDE MEMBER=JOBLIB //PROC01 EXEC PROC=DDAR04, // DSNENV=PROD, DATASET HLQ // XMTENV=PROD, XMIT DATASET HLQ // IMSENV=PROD, IMS DB HLQ // RDATE=PROD.APPL RUNDATE HLQ // This is for production. For test/qa we have 'PGMR.APPLIB.INCLUDE(JOBLIB)': //JOBLIB DD DSN=LOADENV..APPLIB.LOAD,DISP=SHR // DD DSN=PGMR.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.UTILLIB.LOAD,DISP=SHR // DD DSN=SYS3.IVORYHUB.V511.LOADLIB,DISP=SHR // DD DSN=SYS3.BMC.IMS.IMLIB,DISP=SHR // DD DSN=SYS3.BMC.IMS.BMCPSWD,DISP=SHR // DD DSN=SYS6.IMD1.SDFSRESL,DISP=SHR // DD DSN=SYS6.IMD1.DYNLIB.BATCH,DISP=SHR //* DD DSN=SYS3.DSN910.SDSNEXIT,DISP=SHR //* DD DSN=SYS3.DSN910.SDSNLOAD,DISP=SHR // DD DSN=SYS3.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR // DD DSN=PROD.VISAEP4.RULES.LOAD,DISP=SHR // DD DSN=PROD.VISAEP4.LOAD,DISP=SHR PROCLIB(APPL) DD(1)=(DSNAME=PGMR.APPLIB.INCLUDE), DD(2)=(DSNAME=PROD.APPLIB.INCLUDE), DD(3)=(DSNAME=PGMR.APPLIB.PROC), DD(4)=(DSNAME=PROD.APPLIB.PROC), DD(5)=(DSNAME=PROD.PEPLIB.PROC),UNCOND To execute a test run from a library named DVFJS.APPLIB.LOAD I would have something like this: //DDAR04 JOB ,'DDAR04' //*--* /*JOBPARM PROCLIB=APPL // SET LOADENV=DVFJS // INCLUDE MEMBER=JOBLIB My point here being that if we needed to add a new application load library to our environment all we need to do is modify 'PROD.APPLIB.INCLUDE(JOBLIB)' and 'PGMR.APPLIB.INCLUDE(JOBLIB)' to add the new library. Frank From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, September 24, 2013 6:47 AM Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, to use the process you describe there are literally hundreds of thousands of JCL's to be changed, and tens of thousands of PROC's, and that is just one large shop. The only zones are QA and Production, shared by all applications. Where do you start such a project? The cost of regression testing alone is huge, especially in already CPU-constrained testing environments. New business lines, new regulatory issues, new clients: All these will take precedence over any kind of maintenance project, whatever the eventual ROI might be. Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Will-we-nil-we, I suppose we will eventually get there, but it's not going to be quick or easy, and far, far from cheap. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, September 24, 2013 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message
Re: PDS/E, Shared Dasd, and COBOL V5
On 9/24/2013 12:31 PM, Frank Swarbrick wrote: These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our load library concatenation. We have the following member named 'PROD.APPLIB.INCLUDE(JOBLIB)': //JOBLIB DD DSN=EMER.APPLIB.LOAD,DISP=SHR // DD DSN=EMER.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.APPLIB.LOAD,DISP=SHR // DD DSN=PROD.PEPLIB.LOAD,DISP=SHR // DD DSN=PROD.UTILLIB.LOAD,DISP=SHR // DD DSN=SYS6.IMP1.SDFSRESL,DISP=SHR // DD DSN=SYS6.IMP1.DYNLIB.BTCH,DISP=SHR // DD DSN=SYS3.DSN910.SDSNEXIT,DISP=SHR // DD DSN=SYS3.DSN910.SDSNLOAD,DISP=SHR // DD DSN=SYS3.MBC.LOAD,DISP=SHR // DD DSN=CICS.SDFHEXCI,DISP=SHR // DD DSN=PROD.VISAEP4.RULES.LOAD,DISP=SHR // DD DSN=PROD.VISAEP4.LOAD,DISP=SHR In the JES2PARM member we have this: JOBLIBing everything has performance implications. We were also bit by this when they included an old SORT steplib in the concatenation and then SORT bombed on us. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
For that, 1. Create HLQ.COBLIB.PDSE, 2. Copy everything from HLQ.COBLIB (PDS), 3. Compiles should link edit into both libraries. 4. Test with the new library. 5. Verify HLQ.COBLIB and HLQ.COBLIB.PDSE have the same members and contents (date time stamp). 5. Shutdown everything. 6. Rename HLQ.COBLIB to HLQ.COBLIB.PDS 7. Rename HLQ.COBLIB.PDSE to HLQ.COBLIB. 8. IPL (or just restart applications). 9. Compiles should stop linkediting into both libraries. 10. Migrate HLQ.COBLIB.PDS. On Tue, Sep 24, 2013 at 6:35 AM, Jousma, David david.jou...@53.com wrote: Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _ Dave Jousma -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
That is a well designed system, but IIRC you had the luxury to do it right the first time when you migrated from z/VSE to z/OS. Shops that have been MVS / z/OS since the dawn of time have literally decades of old JCL written to now-obsolete standards to contend with, much of which runs unchanged because it still just works. I am not saying this conversion cannot be done, even on a job-by-job basis within particular business applications, but the investment in the SCLM changes is not trivial either, and those changes must support the old compiler as well as the new one so that emergency oh-dark-30 fixes to unconverted code can be made in a timely manner without using the new compiler processes and libraries. I suspect that many large shops will be paying for two compiler versions for quite a long time. Good for IBM, not so good for their customers. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, September 24, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our load library concatenation. Details snipped My point here being that if we needed to add a new application load library to our environment all we need to do is modify 'PROD.APPLIB.INCLUDE(JOBLIB)' and 'PGMR.APPLIB.INCLUDE(JOBLIB)' to add the new library. Frank From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, September 24, 2013 6:47 AM Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, to use the process you describe there are literally hundreds of thousands of JCL's to be changed, and tens of thousands of PROC's, and that is just one large shop. The only zones are QA and Production, shared by all applications. Where do you start such a project? The cost of regression testing alone is huge, especially in already CPU-constrained testing environments. New business lines, new regulatory issues, new clients: All these will take precedence over any kind of maintenance project, whatever the eventual ROI might be. Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Will-we-nil-we, I suppose we will eventually get there, but it's not going to be quick or easy, and far, far from cheap. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, September 24, 2013 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Monday, September 23, 2013 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 If you set up new PDS/E program libraries for only V5 program code, then any time maintenance on a COBOL program is done the maintainer must be aware whether this is the first time this program has compiled with V5 and if so, be sure any related production JCL gets changed to reference the new library in sync with the program installation and be sure the obsolete load module in some PDS gets purged at the same time to prevent possible execution of obsolete code. How about if shops start changing COBOL build processes today to use PDSE datasets for COBOL V4 (or COBOL 3) programs? Step 1 would be to allocate new PDSE datasets for each zone of load libraries Step 2 would be to add the new PDSE dataset(s) to load library concatenations where needed. If put first it would guarantee access to new programs. Step 3 would be to change build processes to link old COBOL programs into PDSEs. Step 4 would be to make sure this works for all systems and that old (unreachable) programs get deleted from PDS datasets Step 5 from time to time, move needed load modules from PDSs to PDSEs until all are moved. Step 6 when all code has been moved, the only programs in PDS should be unused, and the PDS datasets could be deleted If this plan was used, the COBOL V5 PDSE requirement would not be disruptive. My question, is it do-able? -- This message and any attachments are intended only for the use
Re: PDS/E, Shared Dasd, and COBOL V5
You are correct. Just thought I'd mention it! I definitely feel for you. I continue to wish for some sort of job class level load library concatenation that would sit between JOBLIB/STEPLIB and the system link list. I don't feel I know enough about MVS internals to make a good RFE for this. But if someone has thoughts... Frank From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, September 24, 2013 11:38 AM Subject: Re: PDS/E, Shared Dasd, and COBOL V5 That is a well designed system, but IIRC you had the luxury to do it right the first time when you migrated from z/VSE to z/OS. Shops that have been MVS / z/OS since the dawn of time have literally decades of old JCL written to now-obsolete standards to contend with, much of which runs unchanged because it still just works. I am not saying this conversion cannot be done, even on a job-by-job basis within particular business applications, but the investment in the SCLM changes is not trivial either, and those changes must support the old compiler as well as the new one so that emergency oh-dark-30 fixes to unconverted code can be made in a timely manner without using the new compiler processes and libraries. I suspect that many large shops will be paying for two compiler versions for quite a long time. Good for IBM, not so good for their customers. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, September 24, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 These discussions sure make me glad we implemented steps that allow us to use a single, shared include member for our load library concatenation. Details snipped My point here being that if we needed to add a new application load library to our environment all we need to do is modify 'PROD.APPLIB.INCLUDE(JOBLIB)' and 'PGMR.APPLIB.INCLUDE(JOBLIB)' to add the new library. Frank From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, September 24, 2013 6:47 AM Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, to use the process you describe there are literally hundreds of thousands of JCL's to be changed, and tens of thousands of PROC's, and that is just one large shop. The only zones are QA and Production, shared by all applications. Where do you start such a project? The cost of regression testing alone is huge, especially in already CPU-constrained testing environments. New business lines, new regulatory issues, new clients: All these will take precedence over any kind of maintenance project, whatever the eventual ROI might be. Programmers like me would desperately love to see the new compiler in action and get going on using the enhanced facilities -- but the procedural hurdles that IBM has thrown up with this PDSE requirement are going to be staggeringly expensive to cross over. Will-we-nil-we, I suppose we will eventually get there, but it's not going to be quick or easy, and far, far from cheap. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, September 24, 2013 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom, For us there will be no Step1 or Step2. We will Convert existing loadlibs from PDS to PDSE. There is way too much application JCL to change to think about changing the concatenation. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Monday, September 23, 2013 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 If you set up new PDS/E program libraries for only V5 program code, then any time maintenance on a COBOL program is done the maintainer must be aware whether this is the first time this program has compiled with V5 and if so, be sure any related production JCL gets changed to reference the new library in sync with the program installation and be sure the obsolete load module in some PDS gets purged at the same time to prevent possible execution of obsolete code. How about if shops start changing COBOL build processes today to use PDSE datasets for COBOL V4 (or COBOL 3) programs? Step 1 would be to allocate new PDSE datasets for each zone of load libraries Step 2 would be to add the new PDSE dataset(s) to load library concatenations where needed. If put first it would guarantee access to new programs. Step 3 would be to change build processes to link
Re: PDS/E, Shared Dasd, and COBOL V5
Tom, Here is my 2cents worth Yes it is do-able. However, here are the challenges 1) How many applications have unique LOADLIBs? 2) What STCs are those libraries tied to - DB2 Stored Procedures, MQ STC, DB2 STC, CICS STC, IMS STC. 3) How many loadlibs need to be replicated from PDS to PDS/E? 4) How many users have used hardcoded libraries rather than using the supplied Libraries? Mostly JCL not maintained by a source manager 5) What functions would require a cycle to implement the new loadlibs ahead of the the current ones? As you are aware some shops will have jobs running that might not be controlled by a source manager (Change Man or Endevor, etc...) or scheduling software. If you recall, IBM put in a fix to list VSAM files that had Replicate/Imbed created a Message to indicate what files had those attributes. This will be a little more interesting. Lizette -Original Message- From: Tom Ross tmr...@stlvm20.vnet.ibm.com Sent: Sep 23, 2013 12:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 If you set up new PDS/E program libraries for only V5 program code, then any time maintenance on a COBOL program is done the maintainer must be aware whether this is the first time this program has compiled with V5 and if so, be sure any related production JCL gets changed to reference the new library in sync with the program installation and be sure the obsolete load module in some PDS gets purged at the same time to prevent possible execution of obsolete code. How about if shops start changing COBOL build processes today to use PDSE datasets for COBOL V4 (or COBOL 3) programs? Step 1 would be to allocate new PDSE datasets for each zone of load libraries Step 2 would be to add the new PDSE dataset(s) to load library concatenations where needed. If put first it would guarantee access to new programs. Step 3 would be to change build processes to link old COBOL programs into PDSEs. Step 4 would be to make sure this works for all systems and that old (unreachable) programs get deleted from PDS datasets Step 5 from time to time, move needed load modules from PDSs to PDSEs until all are moved. Step 6 when all code has been moved, the only programs in PDS should be unused, and the PDS datasets could be deleted If this plan was used, the COBOL V5 PDSE requirement would not be disruptive. My question, is it do-able? Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Mon, 23 Sep 2013 12:17:20 -0700, Tom Ross wrote: ... Step 6 when all code has been moved, the only programs in PDS should be unused, and the PDS datasets could be deleted If this plan was used, the COBOL V5 PDSE requirement would not be disruptive. My question, is it do-able? I believe Timothy said you've had about 20 years to be working on this. When did you start? TomR COBOL is the Language of the Future! I'm waiting ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I followed this thread quietly for a long time, but now I'd like to ask
some questions
related to our site, if I'm allowed to do so:
- we are PL/1, not COBOL, but I believe that we will have this issue in
the not so
far future too, is this true?
- we have a home grown tool which does the transports of the binaries
into the
different zones mentioned below. In the moment this tool assumes that the
target libraries in all those zones are PDSes, and, more important, that
they
are all of the same type. So for us there is some investment, if they
have to
be converted to PDSEs and if they are different for the different zones
(during
migration time). So this is a project for us, and not a small one.
That's why
I am concerned about knowing early about such plans regarding PL/1.
Thanks,
kind regards
Bernd
Am 20.09.2013 05:37, schrieb Timothy Sipples:
I think that's a good summary, Joel, of some of the considerations in how
to go about adopting PDSEs. Thanks. Though I would point out that many/most
of those considerations are not necessarily *unique* to this particular
compiler upgrade. Juggling multiple libraries and changing build/test/run
processes can happen in lots of other circumstances. I also agree with your
point that change management tooling (and actually using it) is very
valuable. (That's not an advertisement: SCLM is part of base z/OS, as one
example.)
Each shop is probably going to be a little different. To elaborate on some
points you raised, most shops tend to have application/functional zones
of one sort or another. As examples, there are runtime zones (batch, CICS,
IMS, DB2 stored procedures, etc.), line of business zones (credit card,
core banking, inventory, ordering, customer service, etc.), LPAR
separations, development sub-teams, and so on. What I'm calling a zone is
some specific vector of COBOL program separations, e.g. Zone ABC1 could
be { LPAR MVSA, batch, customer service, account inquiry applications,
Kansas development team }. Some zones are big, and others are small,
but the point is there's some logical separation in practically every shop.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Tim, I have to disagree in part with the statement you made below that ... it couldn't be avoided. It most certainly *could* have been avoided. It may have been a ... reasonable, responsible technical choice from IBM's more-than-occasionally myopic point of view, but not necessarily the best choice, either technically or politically. A better choice, IMHO, would have been to use the XL C/C++ back end which supports not only load-module output but also supports architectures back to before the G1 series (the XL C/C++ documentation for ARCH(0) says: Produces code that is executable on all models.). All the benefits of newer-architecture instructions and advanced optimization algorithms would have been made available without *requiring* program-object output and thus PDSE storage. As well, the choice to implement debugging information in DWARF2 format in no-load program-object segments should NOT have meant that output object code was *necessarily* program-object-only output. When compiler option NOTEST is in effect there should be no reason whatsoever to force the compiler to produce a program object. And again, the XL C/C++ back end would have been ideal in this case, able to produce either load-module-compatible or program-object-required output, UNDER THE CONTROL OF THE END USER PROGRAMMER and their management, and depending technically on whether any program-object-only COBOL features were used in the source code. For instance, writing OO COBOL source code that uses classes and methods, etc., would have been a very reasonable cause to force program-object output. A COBOL source program that uses no OO features and is compiled with NOTEST should be able to generate a load-module-compatible output executable. And debugging software available from several ISV's would have supported debugging without using the IBM DWARF2 information at all, as they do now, and let the best debugger in the market win the hearts and minds of the users and their management. Competition is good. Obviously we are not going to get that choice, but it is one that IBM *could* have given us. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Thursday, September 19, 2013 11:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Snip I am not thrilled that there's a PDSE prerequisite for Enterprise COBOL 5.1. I don't like any prerequisites whatsoever if they can be avoided. In this case, it couldn't be avoided. This path was the reasonable, responsible technical choice in order to deliver to you, our great customers (and to new customers) wonderful COBOL innovations, both immediately and continuing over the long term. Compilers are both hard to do and critically important, especially as microprocessor-related physics keep getting more challenging. This new backend puts COBOL firmly back on the development path it deserves as one of (if not the) preeminent enterprise programming languages. I couldn't be more thrilled about that. /Snip -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Bernd, IBM C/C++ and PL/I are scheduled to use the same backend machinery, and it would be my guess that they will do so at about the same time; but the actual dates associated with these scheduling decisions have not been announced. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 20 September 2013 09:28, Farley, Peter x23353 peter.far...@broadridge.com wrote: Tim, I have to disagree in part with the statement you made below that ... it couldn't be avoided. It most certainly *could* have been avoided. It may have been a ... reasonable, responsible technical choice from IBM's more-than-occasionally myopic point of view, but not necessarily the best choice, either technically or politically. A better choice, IMHO, would have been to use the XL C/C++ back end which supports not only load-module output but also supports architectures back to before the G1 series (the XL C/C++ documentation for ARCH(0) says: Produces code that is executable on all models.). All the benefits of newer-architecture instructions and advanced optimization algorithms would have been made available without *requiring* program-object output and thus PDSE storage. At risk of going off on a bit of a tangent, I've been wondering quite a bit about this choice. And more fundamentally, why there are two current code generator back-ends in IBM with obviously overlapping function. And I think they even come from the same lab in Toronto. I had imagined the key feature of a Java back end to be Just In Time compiling, because in general JVM classes cannot be pre compiled, but need to be translated on the fly, often in small chunks yet with good performance, so that a tiny function doesn't have a big startup cost when called, yet its performance can improve with experience. A COBOL back-end - like one for C or PL/I or FORTRAN or any traditional language - would presumably want to generate the best possible code with the luxuries of lots of available compile-time resources, cross-procedure/module optimization, and so on. Now these goals are obviously not incompatible, indeed they overlap hugely, but I wonder if this is just the latest in a decades-long series of IBM internal competitions where both products are allowed to get out the door before one is eventually killed off. And if the Java one is winning the new business, as it were, is the C one going to be kicked out of C and PL/I in due time? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Tony, The 'Java' backend has has almost certainly prevailed. Its use in the new COBOL compiler was obviously long meditated, and it is now all but irreversible. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
My read from previous remarks in this thread is that IBM's long-term
direction is toward program objects and PDSEs for all compilers, because
that sounds like the only easy way to provide new features and also
provide a common run-time environment and debugging capability across
multiple source languages. Even if it were a while before PL/I forces
the issue like COBOL V5, you might hit some future installation need to
inter-operate with C or COBOL code that might force the issue earlier
than the PL/I compiler; so I would be giving thought to what it would
take to adapt.
We also had home-grown tools, built with compiled REXX, to control
compile job generation, source, compile listings, DBRM, and binary
management; but it either used ISPF functions or standard IBM utilities
for transport between libraries, so adapting it to support a PDSE in
specific cases required some adjustment but was not a major code
re-write. If your physical transport of members between libraries is
currently handled by installation code, you have a more difficult
re-write, since my understanding is you pretty much have to invoke the
Binder to create a program object in a PDSE.
While I agree with Timothy that the concept and usage of separate
zones is no doubt common and familiar to most installations, that
still doesn't mean that a purturbation to existing design would be
trivial to implement. We had around 15 distinct application development
areas, each supporting maintenance of existing code plus code
development for new functionality; each with test, production, and
backup zones; and in-house tools that enforce the proper usage of
those zone libraries and member naming standards for the application
areas. An approach that requires adding a program library for each zone
may seem reasonable when only two or three zones are involved, but looks
much less reasonable when 45 zones are involved. Our TechSys
application area is one case that might require some significant
redesign: it has a load module PDS library currently containing mostly
non-COBOL but some COBOL code. Occasionally some of those modules are
manually moved to PDS LPA libraries or to 3rd-party-vendor PDS
libraries, which sounds like a problem if the application load module
library were forced to become a PDSE. I'm sure there are ways to deal
with that, but the best approach in the context of our existing tools is
not obvious without further study.
Joel C Ewing
On 09/20/2013 04:23 AM, Bernd Oppolzer wrote:
I followed this thread quietly for a long time, but now I'd like to ask
some questions
related to our site, if I'm allowed to do so:
- we are PL/1, not COBOL, but I believe that we will have this issue in
the not so
far future too, is this true?
- we have a home grown tool which does the transports of the binaries
into the
different zones mentioned below. In the moment this tool assumes that the
target libraries in all those zones are PDSes, and, more important, that
they
are all of the same type. So for us there is some investment, if they
have to
be converted to PDSEs and if they are different for the different zones
(during
migration time). So this is a project for us, and not a small one.
That's why
I am concerned about knowing early about such plans regarding PL/1.
Thanks,
kind regards
Bernd
Am 20.09.2013 05:37, schrieb Timothy Sipples:
I think that's a good summary, Joel, of some of the considerations in how
to go about adopting PDSEs. Thanks. Though I would point out that
many/most
of those considerations are not necessarily *unique* to this particular
compiler upgrade. Juggling multiple libraries and changing build/test/run
processes can happen in lots of other circumstances. I also agree with
your
point that change management tooling (and actually using it) is very
valuable. (That's not an advertisement: SCLM is part of base z/OS, as one
example.)
Each shop is probably going to be a little different. To elaborate on
some
points you raised, most shops tend to have application/functional zones
of one sort or another. As examples, there are runtime zones (batch,
CICS,
IMS, DB2 stored procedures, etc.), line of business zones (credit card,
core banking, inventory, ordering, customer service, etc.), LPAR
separations, development sub-teams, and so on. What I'm calling a
zone is
some specific vector of COBOL program separations, e.g. Zone ABC1 could
be { LPAR MVSA, batch, customer service, account inquiry applications,
Kansas development team }. Some zones are big, and others are small,
but the point is there's some logical separation in practically every
shop.
--
Joel C. Ewing,Bentonville, AR jcew...@acm.org
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Ted MacNeil wrote: You're an enthusiastic prosletisor of the panacea you believe in! If Mr MacNeil is going to be pretentious he has an obligation to get his pretentions right. The word 'prosletisor' is not one. Someone who proselytises|proselytizes is a proselytiser|proselytizer. Moreover, while Shakespeare did of course get alliteration right in Sonnet XXX, the unlettered should avoid it. They are all but certain to produce only doggerel, as here, when they attempt it. I suppose that I should be grateful that our American near monopoly on the use of subliterate constructs has been broken, but I am not. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I think that's a good summary, Joel, of some of the considerations in how
to go about adopting PDSEs. Thanks. Though I would point out that many/most
of those considerations are not necessarily *unique* to this particular
compiler upgrade. Juggling multiple libraries and changing build/test/run
processes can happen in lots of other circumstances. I also agree with your
point that change management tooling (and actually using it) is very
valuable. (That's not an advertisement: SCLM is part of base z/OS, as one
example.)
Each shop is probably going to be a little different. To elaborate on some
points you raised, most shops tend to have application/functional zones
of one sort or another. As examples, there are runtime zones (batch, CICS,
IMS, DB2 stored procedures, etc.), line of business zones (credit card,
core banking, inventory, ordering, customer service, etc.), LPAR
separations, development sub-teams, and so on. What I'm calling a zone is
some specific vector of COBOL program separations, e.g. Zone ABC1 could
be { LPAR MVSA, batch, customer service, account inquiry applications,
Kansas development team }. Some zones are big, and others are small,
but the point is there's some logical separation in practically every shop.
One way to approach implementing PDSEs, then, is a hybrid approach. We've
already established that PDSEs are only required for holding COBOL binaries
compiled with Enterprise COBOL 5.1. Let's assume, for example, that in a
particular shop every COBOL program is today in PDSes, not PDSEs. One
upgrade approach might be to pick a zone, apply the new build/test/deploy
processes only to that zone, and stop there for a little while. Within the
zone PDSes would be converted to PDSEs, but outside the zone they wouldn't.
Presumably the first zone would be chosen by weighing a few criteria such
as whether the zone is small, its business criticality, that it
materially contributes to peak utilization, and/or that constraint relief
would be useful soonest.
I will insert here one advertisement. If you need some particular help
with this upgrade, ask IBM. There is a new offering called zEnterprise
Solution Edition for Application Development that may be relevant if, for
example, you would have new testing requirements that would require more
capacity.
I want to comment briefly on something Ted brought up. I am guilty (as
charged) of championing business-relevant innovation, including COBOL
innovations. In that particular way I agree with John Gilmore: this
community must neither fall into nor perpetuate a zero change policy. That
way lies death and despair, and I'm not a fan. The right answer is balance,
and zero is way out of balance. We all know about and regularly observe
businesses that never adapt and then perish (or at least wither). Do not
let that happen if you can possibly avoid it.
I am not thrilled that there's a PDSE prerequisite for Enterprise COBOL
5.1. I don't like any prerequisites whatsoever if they can be avoided. In
this case, it couldn't be avoided. This path was the reasonable,
responsible technical choice in order to deliver to you, our great
customers (and to new customers) wonderful COBOL innovations, both
immediately and continuing over the long term. Compilers are both hard to
do and critically important, especially as microprocessor-related physics
keep getting more challenging. This new backend puts COBOL firmly back on
the development path it deserves as one of (if not the) preeminent
enterprise programming languages. I couldn't be more thrilled about that.
Anyway, I'm going to be very focused on figuring out how to help customers
address this prerequisite and get it behind them as quickly and
cost-effectively as possible, and with minimum risk, so that they can start
enjoying Enterprise COBOL 5.1's benefits. If I can also help champion ways
to make this path even easier, I'll do that, too.
Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Tom Conley offers a nomination: Simple. With Java, we didn't have 40 years and thousands (millions?) of libraries to convert. That's what makes COBOL different, the conversion effort. Java had no code base to convert, so we could start new. OK, that's an interesting hypothesis for why z/OS customers running Java on z/OS might be different than z/OS customers running COBOL on z/OS. The problem is the hypothesis makes an assumption which is not correct. I thought another poster in this thread made it clear, but I'll explain the point again. Adopting Enterprise COBOL 5.1 does NOT require: 1. Recompiling every (or even any) COBOL program you already have; 2. Moving every (or even any) COBOL program you already have from PDS to PDSE; 3. (For the vast majority of programs) changing code if/when you do recompile. NONE of those steps are prerequisites for adopting Enterprise COBOL 5.1. Let's be very clear about the facts and not prone to hyperbole. You can keep older binaries, and you can keep them in PDSes. If your source code compiles in Enterprise COBOL 4.x then in the vast majority of cases it'll also compile unmodified in Enterprise COBOL 5.1 and behave exactly the same way (except more efficiently). The few exceptions will be if you have used a new reserve word. It has always been thus in every COBOL release upgrade, so by now you should be well familiar with that reserve word phenomenon and how to address it. (Ask if not.) The PDSE prerequisite is *only* for programs you compile with Enterprise COBOL 5.1. And this is why I'm asking the question and would like to hear some more constructive responses, because this is a very important point. I suspect that, in most COBOL shops with that 40 years and thousands (millions?) scenario you will be doing ONLY the following (at a high level) to adopt Enterprise COBOL 5.1: a. Allow running newly created and newly recompiled programs from PDSEs (if you haven't already); b. Keep existing unmodified COBOL binaries in PDSes forever; c. Make sure your development, testing, and runtime environments behave as you intend across PDSes and PDSEs. That would be the typical upgrade scenario at a high level, I would imagine. That is *exactly* what z/OS customers adopting Java on z/OS did (and do). Most of them also have large portfolios of COBOL (and/or PL/I and/or Assembler, etc.) applications that they write, test, deploy, and maintain. Java (their new compiler) requires PDSEs. So they implemented PDSEs if they didn't have them already. New and newly recompiled (Java) code goes into the PDSEs, and they run, successfully. Existing code stays put unless and until they have a compelling reason to touch it. This path worked and works. It's the same darn path except even simpler, isn't it? In this case there's no second programming language (all is COBOL), no new runtime environment (s) (unless you wish), and Enterprise COBOL 5.1-compiled programs interact directly with previously compiled COBOL programs even more easily -- no JNI, for example -- and just as you would expect. OK, let's summarize again I. IBM faced a *technical* decision (as Frank posted earlier -- thanks Frank). To adopt the (fabulous and continually getting more fabulous) Java backend for the next generation Enterprise COBOL compiler also required accepting Java backend prerequisites, and that means PDSEs, a technology IBM first introduced in 1989. The other choice was not to use the Java backend technology, in which case I'd/we'd be reading at least another decade worth of complaints here about how IBM is not delivering COBOL improvements. Yes, IBM looked really carefully at all alternatives, even some crazy ones. I think IBM really, really made the right fundamental technical decision here -- absolutely the right decision to promote a vibrant and growing future for COBOL. II. The PDSE prerequisite is *only* for COBOL programs that you compile specifically with Enterprise COBOL 5.1. Most of you will not and should not do anything with any previously compiled COBOL program in a PDS, especially if it is not particularly relevant to peak utilization, unless and until a developer needs to change the older program and recompile it. This is innovation via evolution, not revolution. III. IBM is not forcing you to do anything, including start your single version charge (SVC) period for Enterprise COBOL 5.1 until you've had a chance to trial it. However, the rest of the world often forces change. (Darn those pesky smartphones! Now get off my lawn. :-)) Again, how much is XX% code efficiency improvement worth? How much is constraint relief worth? There are many customers enjoying the benefits of Enterprise COBOL 5.1 now, and many more will follow. Some of them might be your competitors. But even within your own organizations, business users are going to seek ways to get their jobs done, with or without you. (Cue John Gilmore here.) Innovate (or at least improve), or die. I know IBM understands that. My
Re: PDS/E, Shared Dasd, and COBOL V5
-SNIP-- The problem is the hypothesis makes an assumption which is not correct. I thought another poster in this thread made it clear, but I'll explain the point again. Adopting Enterprise COBOL 5.1 does NOT require: 1. Recompiling every (or even any) COBOL program you already have; That was clear from day one. 2. Moving every (or even any) COBOL program you already have from PDS to PDSE; That is a BIG issue. And not allowing sharing across plexes is another big issue 3. (For the vast majority of programs) changing code if/when you do recompile. NONE of those steps are prerequisites for adopting Enterprise COBOL 5.1. Let's be very clear about the facts and not prone to hyperbole. You can keep older binaries, and you can keep them in PDSes. If your source code compiles in Enterprise COBOL 4.x then in the vast majority of cases it'll also compile unmodified in Enterprise COBOL 5.1 and behave exactly the same way (except more efficiently). The few exceptions will be if you have used a new reserve word. It has always been thus in every COBOL release upgrade, so by now you should be well familiar with that reserve word phenomenon and how to address it. (Ask if not.) I can't WAIT for the first PMR. How about compiling into a PDSe do we have a better idea what is going on. I had a problem where they wanted to change the compiler (maybe a bug in the compiler) and now all of a sudden there is a PDSe requirement in addition to just recompiling. Also I think either you (or IBM) is in for a big surprise as not many companies keep their COBOL (or for that matter any language) in an PDSe library. We never had issues with them (OEM libraries) just PDSe's. Ed The PDSE prerequisite is *only* for programs you compile with Enterprise COBOL 5.1. And this is why I'm asking the question and would like to hear some more constructive responses, because this is a very important point. I suspect that, in most COBOL shops with that 40 years and thousands (millions?) scenario you will be doing ONLY the following (at a high level) to adopt Enterprise COBOL 5.1: a. Allow running newly created and newly recompiled programs from PDSEs (if you haven't already); b. Keep existing unmodified COBOL binaries in PDSes forever; c. Make sure your development, testing, and runtime environments behave as you intend across PDSes and PDSEs. That would be the typical upgrade scenario at a high level, I would imagine. That is *exactly* what z/OS customers adopting Java on z/OS did (and do). Most of them also have large portfolios of COBOL (and/or PL/I and/or Assembler, etc.) applications that they write, test, deploy, and maintain. Java (their new compiler) requires PDSEs. So they implemented PDSEs if they didn't have them already. New and newly recompiled (Java) code goes into the PDSEs, and they run, successfully. Existing code stays put unless and until they have a compelling reason to touch it. This path worked and works. It's the same darn path except even simpler, isn't it? In this case there's no second programming language (all is COBOL), no new runtime environment (s) (unless you wish), and Enterprise COBOL 5.1-compiled programs interact directly with previously compiled COBOL programs even more easily -- no JNI, for example -- and just as you would expect. OK, let's summarize again I. IBM faced a *technical* decision (as Frank posted earlier -- thanks Frank). To adopt the (fabulous and continually getting more fabulous) Java backend for the next generation Enterprise COBOL compiler also required accepting Java backend prerequisites, and that means PDSEs, a technology IBM first introduced in 1989. The other choice was not to use the Java backend technology, in which case I'd/we'd be reading at least another decade worth of complaints here about how IBM is not delivering COBOL improvements. Yes, IBM looked really carefully at all alternatives, even some crazy ones. I think IBM really, really made the right fundamental technical decision here -- absolutely the right decision to promote a vibrant and growing future for COBOL. II. The PDSE prerequisite is *only* for COBOL programs that you compile specifically with Enterprise COBOL 5.1. Most of you will not and should not do anything with any previously compiled COBOL program in a PDS, especially if it is not particularly relevant to peak utilization, unless and until a developer needs to change the older program and recompile it. This is innovation via evolution, not revolution. III. IBM is not forcing you to do anything, including start your single version charge (SVC) period for Enterprise COBOL 5.1 until you've had a chance to trial it. However, the rest of the world often forces change. (Darn those pesky smartphones! Now get off my lawn. :-)) Again, how much is XX% code efficiency improvement worth? How much is constraint
Re: PDS/E, Shared Dasd, and COBOL V5
You're an enthusiastic prosletisor of the panacea you believe in! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Timothy Sipples sipp...@sg.ibm.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 19 Sep 2013 11:52:35 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom Conley offers a nomination: Simple. With Java, we didn't have 40 years and thousands (millions?) of libraries to convert. That's what makes COBOL different, the conversion effort. Java had no code base to convert, so we could start new. OK, that's an interesting hypothesis for why z/OS customers running Java on z/OS might be different than z/OS customers running COBOL on z/OS. The problem is the hypothesis makes an assumption which is not correct. I thought another poster in this thread made it clear, but I'll explain the point again. Adopting Enterprise COBOL 5.1 does NOT require: 1. Recompiling every (or even any) COBOL program you already have; 2. Moving every (or even any) COBOL program you already have from PDS to PDSE; 3. (For the vast majority of programs) changing code if/when you do recompile. NONE of those steps are prerequisites for adopting Enterprise COBOL 5.1. Let's be very clear about the facts and not prone to hyperbole. You can keep older binaries, and you can keep them in PDSes. If your source code compiles in Enterprise COBOL 4.x then in the vast majority of cases it'll also compile unmodified in Enterprise COBOL 5.1 and behave exactly the same way (except more efficiently). The few exceptions will be if you have used a new reserve word. It has always been thus in every COBOL release upgrade, so by now you should be well familiar with that reserve word phenomenon and how to address it. (Ask if not.) The PDSE prerequisite is *only* for programs you compile with Enterprise COBOL 5.1. And this is why I'm asking the question and would like to hear some more constructive responses, because this is a very important point. I suspect that, in most COBOL shops with that 40 years and thousands (millions?) scenario you will be doing ONLY the following (at a high level) to adopt Enterprise COBOL 5.1: a. Allow running newly created and newly recompiled programs from PDSEs (if you haven't already); b. Keep existing unmodified COBOL binaries in PDSes forever; c. Make sure your development, testing, and runtime environments behave as you intend across PDSes and PDSEs. That would be the typical upgrade scenario at a high level, I would imagine. That is *exactly* what z/OS customers adopting Java on z/OS did (and do). Most of them also have large portfolios of COBOL (and/or PL/I and/or Assembler, etc.) applications that they write, test, deploy, and maintain. Java (their new compiler) requires PDSEs. So they implemented PDSEs if they didn't have them already. New and newly recompiled (Java) code goes into the PDSEs, and they run, successfully. Existing code stays put unless and until they have a compelling reason to touch it. This path worked and works. It's the same darn path except even simpler, isn't it? In this case there's no second programming language (all is COBOL), no new runtime environment (s) (unless you wish), and Enterprise COBOL 5.1-compiled programs interact directly with previously compiled COBOL programs even more easily -- no JNI, for example -- and just as you would expect. OK, let's summarize again I. IBM faced a *technical* decision (as Frank posted earlier -- thanks Frank). To adopt the (fabulous and continually getting more fabulous) Java backend for the next generation Enterprise COBOL compiler also required accepting Java backend prerequisites, and that means PDSEs, a technology IBM first introduced in 1989. The other choice was not to use the Java backend technology, in which case I'd/we'd be reading at least another decade worth of complaints here about how IBM is not delivering COBOL improvements. Yes, IBM looked really carefully at all alternatives, even some crazy ones. I think IBM really, really made the right fundamental technical decision here -- absolutely the right decision to promote a vibrant and growing future for COBOL. II. The PDSE prerequisite is *only* for COBOL programs that you compile specifically with Enterprise COBOL 5.1. Most of you will not and should not do anything with any previously compiled COBOL program in a PDS, especially if it is not particularly relevant to peak utilization, unless and until a developer needs to change the older program and recompile it. This is innovation via evolution, not revolution. III. IBM is not forcing you to do anything, including start your single version charge (SVC) period for Enterprise COBOL 5.1 until you've had a chance to trial it. However, the rest of the world often forces change. (Darn those pesky smartphones! Now get off my lawn. :-)) Again, how
Re: PDS/E, Shared Dasd, and COBOL V5
Ed Gould writes: The 90 day trial program (to me) sounds like a shady car dealer from the wrong side of town. The term test drive has its etymology in the vehicle buying process, new and used, as I understand it. Trial is not so often applied to that process. (Would you like to trial the new Fiat 500? That's at least much less common usage of the word trial.) Simply put, we *DON'T* have such animals [Java programs on z/OS]. Nor will we in the foreseeable future. There are no possible business justifications that would lead to implementing Java programs on z/OS? No matter what the benefits, no matter what the business requirements your users and customers have, as long as you're around it'll never happen. Am I understanding you correctly, or am I misinterpreting you? Relatedly, prophetically, is John Gilmore correct? :-) But that wasn't actually the point I was trying to make. I'll try again. Whether *you* have Java programs running on z/OS or not, the fact is that *all* z/OS customers running Java programs on z/OS have no particular issues creating, testing, deploying, and managing their applications with the PDSE prerequisite. And that's been going on for many years. COBOL and Java are programming languages, both excellent. What makes COBOL so different in this respect? Why are all the z/OS customers running Java programs getting their jobs done with PDSEs? What makes them different and special? What's the secret to their successes, and why wouldn't their PDSE experiences apply equally to COBOL? *EVEN* if we did have need for them [PDSEs] currently the issue of cross system use would be a major stumbling block (as others have noted). Yes, duly noted, many times. PDSEs are different, stipulated. (Helpfully IBM added the E.) So how would you surmount this major stumbling block, and how would you advise others to do the same? Assume that do nothing is off the table, and PDSEs will get implemented -- fantasize if that's required. What are the best ways to go about it? I'll give you another stumbling block. Enterprise COBOL 5.1 does not support z900/z800 (and prior) model generations and does not support z/OS releases prior to 1.13. What if you don't satisfy those prerequisites? You can't run Enterprise COBOL 5.1. What's the solution? Upgrade at least to a minimum supported model and z/OS release to satisfy the prerequisites. But doesn't upgrading require doing something? Yup. Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In ofac2bcdd2.10885753-on85257be8.005f3349-85257be8.005fc...@uscmail.uscourts.gov, on 09/16/2013 at 01:26 PM, Steve Conway steve_con...@ao.uscourts.gov said: Limited use is exactly what is under discussion, based on the original point of LPA not allowing PDSE data sets All the PARMLIB member needs to do is provide a list of PDSE datasets to be loaded into LPA. Why not state the requirement as automatic deferred LPA loading from PDSE and give exits and parmlib as possible implementations? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Tue, Sep 17, 2013 at 1:39 AM, Timothy Sipples sipp...@sg.ibm.com wrote: Simply put, we *DON'T* have such animals [Java programs on z/OS]. Nor will we in the foreseeable future. There are no possible business justifications that would lead to implementing Java programs on z/OS? No matter what the benefits, no matter what the business requirements your users and customers have, as long as you're around it'll never happen. Am I understanding you correctly, or am I misinterpreting you? Perhaps Ed is just stating what _is_ at his shop. There are a lot of shops out there, ours included, which are basically functionally stabilized. A few years ago, we had some IT management which started a Linux push. Part of which was using Java instead of .NET on the Windows boxen and in addition to COBOL on z/OS. They were promptly replaced. Java, in truth or not, is perceived around here as dead technology. It is also expensive in CPU resources compared to most COBOL programs. Now, one could argue that with a zIIP and zAAP on zIIP processing, that Java is actually cheaper to run. But then there is the upgrade cost to add a zIIP processor. Oh, and we're stuck on a z9BC due to lack of money to go to current technology. But I'm not arguing against PDSE usage. Most of our application libraries are PDSEs. Mainly because we're too lazy to do a compress grin/. I wish that I really knew why COBOL 5.1 uses them. I read it had something to do with embedded debugging information. But I guess that I'm out of date on what can be done with a PDSE (user loadable classes?). I need to delve into the books more. But that leads to frustration because I know that I will _never_ see this. For good or ill, this is my final job. Not because I am ready (personally or financially) to retire. But because no company would hire me due to my age and health. I'm not real sick, but I'm not as healthy as I was when I was 30. With health care costs going into low Earth orbit, I (like the z itself) am simply too expensive for all the the largest of companies. Thanks for the knife in the back, Mr. President. Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
In CAAJSdji5fA+mi5FPQ0dZ_AD3tkKAAe0gSs=whoizsotn2j-...@mail.gmail.com, on 09/16/2013 at 09:17 PM, John McKown john.archie.mck...@gmail.com said: Personally, unless I am doing an internal email, I use the ISO date format. Where? That's fine for human-readable text, but for anything that is parsed by software you need to use what the software expects. There should be no chance of accidental misunderstanding. If you use anything but day month year in, e.g., the Date: header field, misunderstanding is guarantied. RFC 2322 does not support the ISO date format. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
In 5237891d.2090...@phoenixsoftware.com, on 09/16/2013 at 03:41 PM, Ed Jaffe edja...@phoenixsoftware.com said: I'm pretty sure the support is intended to access ordinary FBA disk files and has nothing whatsoever to do with tape. I'm pretty sure that the support is intended to allow a server address space to access the FBA device, not to allow allocation to an unprivileged job. Is there even such a thing as FBA tape? There was; I don't know of any still in use. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
The problem can be much worse when two or more groups, e.g., anglophone and francophone Canadians, share the use of a facility. Usually, the issues are formally linguistic ones, but they may really be cultural or ethnic. When my wife and I shop in Hoboken, NJ, which has a large Barese/Molfetani population, we do it in Italian, which entails buying cheese, cold meats and the like in multiples of the etto, one-tenth of a kilo[gram]. Asking for 'due etti' of prosciutto or sorpressata is, as a practical matter, only very marginally different from asking for a half pound; but the Italian formulation is wiser in that environment. Or again, when I buy Wurste in German at Schaller und Weber in Manhattan, I perforce buy them paarweise. This limits me to buying 2, 4, 6, . . . ; and, while I am sure that it would be possible to buy, say, 1, 3, or 5, it is not the convention to do so. We live in a world that is still full of such conflicting conventions; and I, for one, relish this diversity. Still, there are contexts in which disambiguation is necessary; and that is what standards are for. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 9/17/2013 4:59 AM, Shmuel Metz (Seymour J.) wrote: In 5237891d.2090...@phoenixsoftware.com, on 09/16/2013 at 03:41 PM, Ed Jaffe edja...@phoenixsoftware.com said: I'm pretty sure the support is intended to access ordinary FBA disk files and has nothing whatsoever to do with tape. I'm pretty sure that the support is intended to allow a server address space to access the FBA device, not to allow allocation to an unprivileged job. Absolutely! An authorized server address space will be necessary to allow non-privileged programs to do FBA I/O. The requirements of the IOSFBA service are: *01* ENVIRONMENT: * Dispatchable unit mode: Task mode. * Minimum authorization: Supervisor state, PSW Key 0. * AMODE:31- or 64-bit. * ASC mode: Primary. * Cross Memory Mode: PASN=HASN=SASN. * Interrupt status: Enabled for I/O and external interrupts. * Locks:No locks held. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
Sounds like it is almost made-to-order for a UNIX filesystem colony address space to allow a z/OS UNIX filesystem on an FBA device. On Tue, Sep 17, 2013 at 9:12 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 9/17/2013 4:59 AM, Shmuel Metz (Seymour J.) wrote: In 5237891D.2090001@**phoenixsoftware.com5237891d.2090...@phoenixsoftware.com, on 09/16/2013 at 03:41 PM, Ed Jaffe edja...@phoenixsoftware.com said: I'm pretty sure the support is intended to access ordinary FBA disk files and has nothing whatsoever to do with tape. I'm pretty sure that the support is intended to allow a server address space to access the FBA device, not to allow allocation to an unprivileged job. Absolutely! An authorized server address space will be necessary to allow non-privileged programs to do FBA I/O. The requirements of the IOSFBA service are: *01* ENVIRONMENT: * Dispatchable unit mode: Task mode. * Minimum authorization: Supervisor state, PSW Key 0. * AMODE:31- or 64-bit. * ASC mode: Primary. * Cross Memory Mode: PASN=HASN=SASN. * Interrupt status: Enabled for I/O and external interrupts. * Locks:No locks held. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.**com/ http://www.phoenixsoftware.com/ --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Sep 17, 2013, at 1:39 AM, Timothy Sipples wrote: Ed Gould writes: The 90 day trial program (to me) sounds like a shady car dealer from the wrong side of town. The term test drive has its etymology in the vehicle buying process, new and used, as I understand it. Trial is not so often applied to that process. (Would you like to trial the new Fiat 500? That's at least much less common usage of the word trial.) Simply put, we *DON'T* have such animals [Java programs on z/OS]. Nor will we in the foreseeable future. There are no possible business justifications that would lead to implementing Java programs on z/OS? No matter what the benefits, no matter what the business requirements your users and customers have, as long as you're around it'll never happen. Am I understanding you correctly, or am I misinterpreting you? Zero, nada... we don't use JAVA and don't have people that speak/ write/understand it and no foreseeable need of it. Relatedly, prophetically, is John Gilmore correct? :-) But that wasn't actually the point I was trying to make. I'll try again. Whether *you* have Java programs running on z/OS or not, the fact is that *all* z/OS customers running Java programs on z/OS have no particular issues creating, testing, deploying, and managing their applications with the PDSE prerequisite. And that's been going on for many years. COBOL and Java are programming languages, both excellent. What makes COBOL so different in this respect? Why are all the z/OS customers running Java programs getting their jobs done with PDSEs? What makes them different and special? What's the secret to their successes, and why wouldn't their PDSE experiences apply equally to COBOL? So you are essentially saying screw 80 percent of the user base. *EVEN* if we did have need for them [PDSEs] currently the issue of cross system use would be a major stumbling block (as others have noted). Yes, duly noted, many times. PDSEs are different, stipulated. (Helpfully IBM added the E.) So how would you surmount this major stumbling block, and how would you advise others to do the same? Assume that do nothing is off the table, and PDSEs will get implemented -- fantasize if that's required. What are the best ways to go about it? I'll give you another stumbling block. Enterprise COBOL 5.1 does not support z900/z800 (and prior) model generations and does not support z/OS releases prior to 1.13. What if you don't satisfy those prerequisites? You can't run Enterprise COBOL 5.1. What's the solution? Upgrade at least to a minimum supported model and z/OS release to satisfy the prerequisites. But doesn't upgrading require doing something? Yup. So why upgrade.. essentially for one minor item that is not needed.. Sounds like a sales pitch given by the devil. Buy it or else. Since there is no compelling reason we won't buy it. It also smacks of IBM dictating that everyone must buy. Its one thng to say the OS needs it but one minor player its going to be triple the bother of yet another upgrade just to keep ahead of the Jones. 1 small feature does not a sale make. Ed -- -- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On Tue, 17 Sep 2013 01:57:55 -0400, Gerhard Postpischil wrote: On 9/16/2013 9:47 PM, John Gilmore wrote: I meant something a little more restrictive, to wit the regions that used to be [and in some measure still are] colo[u]red pink on world maps. The problem is worse than just regional. My last time in Halifax, we shopped at a mall for books, candy, and jewelry, and noticed that the receipts had three different date formats. Ah, but where were the various cash registers manufactured, or their embedded software written? Consequences of globalization. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Sep 17, 2013, at 5:04 AM, Elardus Engelbrecht wrote: Ed Gould wrote: The 90 day trial program (to me) sounds like a shady car dealer from the wrong side of town. Here in Sunny South Africa, there are no 'wrong' side of town. ;-) You get shady car dealers anywhere... ;-D Sorry to hear, I am assuming MB is still on the up and up. Go foreign:) Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 16 Sep 2013 15:41:34 -0700, in bit.listserv.ibm-main you wrote: On 9/16/2013 3:04 PM, Mike Schwab wrote: That sounds like Virtual Tape Libraries and not AIX or Linux disk file systems. I'm pretty sure the support is intended to access ordinary FBA disk files and has nothing whatsoever to do with tape. Is there even such a thing as FBA tape? I believe that the RCA Spectra 70 had FBA tape. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PDSE at IPL was Re: PDS/E, Shared Dasd, and COBOL V5
On 15 Sep 2013 22:24:32 -0700, in bit.listserv.ibm-main you wrote: much snipped I agree with Tom Marchant by the way. All operating systems bootstrap, and all of them must. Mac OS X 10.7, for example, introduced so-called full disk encryption (FileVault 2). That's nice, except it's not full: Macs still need a readable (i.e. unencrypted) skinny boot partition to get everything going. Maybe someday Apple will shove that unencrypted boot partition completely into firmware, but no matter where it comes from it's still the same boot sequence. If there's a useful reason PDSEs (or DB2 as another example) ought to be available earlier in the z/OS IPL sequence, let IBM know through the appropriate channels. Enterprise COBOL 5.1 isn't one of those reasons as far as I can see. The reason for PDSE at IPL is brutally simple and has been stated here. It is the ability to eliminate PDSs and then with upgrades for ESDS data sets so that there is a GDG capability and the ability to concatenate data sets, the ability for a shop to migrate to FBA devices. Clark Morris My views are my own here. My views sometimes change upon consideration of new evidence. They are not necessarily those of my employer or my dentist. If I happen not to repeat this reminder, it still applies. Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 16 September 2013 19:48, John McKown john.archie.mck...@gmail.com wrote: HFS UNIX filesystems are supported in the OMVS address space itself. zFS filesystems are supported in a colony address space called ZFS. In passing, there is no strong connection between running a filesystem in the UNIX kernel address space or in a colony address space. Most file systems can run in the kernel, and all can run in a colony, unchanged (as the book says). Only those that use a particular colony thread service cannot run in the kernel. There are pros and cons to each environment. Why not support another filesystem type, allocated on the unit record FBA device, in another colony address space? Perhaps even a z/Linux formatted filesystem such as ext4 or btrfs. In this case the single user only allocation is a moot point since all filesystem I/O would be done by the colony address space. Nothing technical stops you from writing one. You can certainly do it in C or assembler, and who knows - maybe in some other languages that don't have too much run-time baggage. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FBA Tape (Was: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5))
Given modern compression techniques used on tape, FBA is probably not practical for tape. Of course, the current drives have a concept of a BLOCKID that using the right CCW you can get to the block directly. I don't believe that is available for normal BSAM or QSAM processing. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Tuesday, September 17, 2013 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5) On 16 Sep 2013 15:41:34 -0700, in bit.listserv.ibm-main you wrote: On 9/16/2013 3:04 PM, Mike Schwab wrote: That sounds like Virtual Tape Libraries and not AIX or Linux disk file systems. I'm pretty sure the support is intended to access ordinary FBA disk files and has nothing whatsoever to do with tape. Is there even such a thing as FBA tape? I believe that the RCA Spectra 70 had FBA tape. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 9/17/2013 2:41 AM, Timothy Sipples wrote: Ed Gould writes: The 90 day trial program (to me) sounds like a shady car dealer from the wrong side of town. The term test drive has its etymology in the vehicle buying process, new and used, as I understand it. Trial is not so often applied to that process. (Would you like to trial the new Fiat 500? That's at least much less common usage of the word trial.) Simply put, we *DON'T* have such animals [Java programs on z/OS]. Nor will we in the foreseeable future. There are no possible business justifications that would lead to implementing Java programs on z/OS? No matter what the benefits, no matter what the business requirements your users and customers have, as long as you're around it'll never happen. Am I understanding you correctly, or am I misinterpreting you? Relatedly, prophetically, is John Gilmore correct? :-) But that wasn't actually the point I was trying to make. I'll try again. Whether *you* have Java programs running on z/OS or not, the fact is that *all* z/OS customers running Java programs on z/OS have no particular issues creating, testing, deploying, and managing their applications with the PDSE prerequisite. And that's been going on for many years. COBOL and Java are programming languages, both excellent. What makes COBOL so different in this respect? Why are all the z/OS customers running Java programs getting their jobs done with PDSEs? What makes them different and special? What's the secret to their successes, and why wouldn't their PDSE experiences apply equally to COBOL? Simple. With Java, we didn't have 40 years and thousands (millions?) of libraries to convert. That's what makes COBOL different, the conversion effort. Java had no code base to convert, so we could start new. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
http://allthingsd.com/20130916/google-acquires-bump-for-at-least-30m/ What's your RACF profile for this? In a message dated 09/17/13 14:03:08 Central Daylight Time, pinnc...@rochester.rr.com writes: That's what makes COBOL different, the conversion effort. Java had no code base to convert, so we could start new. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 9/15/2013 10:22 PM, Timothy Sipples wrote: If there's a useful reason PDSEs ... ought to be available earlier in the z/OS IPL sequence, let IBM know through the appropriate channels. This is a well-known requirement. It is embarrassingly restrictive that LPALSTxx cannot reference a PDSE. The workaround for those that must load program obejcts into LPA--suggested by IBM in this very forum--is to write a small HLASM bootstrap program that issues CSVDYLPA to load the necessary program object(s) into LPA and take steps to somehow ensure it executes early enough e.g., as a system exit, subsystem initialization routine, etc. (Note: Some products might be able to get away with SETPROG LPA,ADD commands specified through COMMNDxx.) z/OS developers should not have to write such bootstrap programs to have LPA-resident program objects. At the very least, there should be a parmlib member with a list of data sets, analogous to LPALSTxx (LPADYNxx?), that the system will use to automatically populate dynamic LPA during system initialization at the earliest possible opportunity after PDSE support becomes active. At least this would do away with the need for every developer to roll his/her own solution. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 9/16/2013 2:19 AM, Ed Jaffe wrote: At least this would do away with the need for every developer to roll his/her own solution. While NIP processing has changed a bit since OS/360, there always has been a LINK to IEEVIPL. We've hijacked that to initialize local security (pre-RACF) and accounting code, ensure correct volume attributes (for packs not in VATLST), and other shenanigans. Perhaps IBM could be persuaded to add a formal link (or ATTACH) to a user exit - at this point most services are available. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
While Gerhard's suggestion of an exit has the merit of being (probably) easier to get IBM to implement, I much prefer Ed's suggestion of a PARMLIB member. That is much easier to review, implement and maintain down here in the trenches. Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: Gerhard Postpischil gerh...@valley.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/16/2013 03:07 AM Subject:Re: PDS/E, Shared Dasd, and COBOL V5 Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On 9/16/2013 2:19 AM, Ed Jaffe wrote: At least this would do away with the need for every developer to roll his/her own solution. While NIP processing has changed a bit since OS/360, there always has been a LINK to IEEVIPL. We've hijacked that to initialize local security (pre-RACF) and accounting code, ensure correct volume attributes (for packs not in VATLST), and other shenanigans. Perhaps IBM could be persuaded to add a formal link (or ATTACH) to a user exit - at this point most services are available. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 2013-09-14 10:37, Paul Gilmartin wrote: What access methods and DSORGs can we expect to see supported? Again all new? Or considerable compatibility with existing art? UNIX filesystems? PDSE? What release target? -- gil FBA Services are intended to allow a FBA device to be updated by both z/OS and other platforms. The API (IOSFBA) is all new, and is in no way related to the access methods we all know and love. Forget all about data sets, VTOCs, cylinders, and so on. It's in z/OS 2.1. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 9/16/2013 9:17 AM, Gord Tomlin wrote: FBA Services are intended to allow a FBA device to be updated by both z/OS and other platforms. The API (IOSFBA) is all new, and is in no way related to the access methods we all know and love. Forget all about data sets, VTOCs, cylinders, and so on. It's in z/OS 2.1. As I posted earlier, the function is being delivered via OA41040 as service against z/OS 2.1 with roll back to z/OS 1.13: PTF List: Release 78H : PTF not available yet Release 780 : PTF not available yet Release 790 : PTF not available yet -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On Mon, 16 Sep 2013 12:17:33 -0400, Gord Tomlin wrote: FBA Services are intended to allow a FBA device to be updated by both z/OS and other platforms. The API (IOSFBA) is all new, and is in no way related to the access methods we all know and love. Forget all about data sets, VTOCs, cylinders, and so on. It's in z/OS 2.1. From reading this list, I suss out that not entirely all know and 'love' UNIX. So is it possible that UNIX filesystems will be supported via IOSFBA? (Of course, if UNIX files are supported a programmer might use DD PATH=..., then QSAM, BSAM, or (read-only) BPAM.) OS/360, much lauded for vertical compatibility, has never been very good at horizontal compatibility. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 9/16/2013 10:11 AM, Steve Conway wrote: While Gerhard's suggestion of an exit has the merit of being (probably) easier to get IBM to implement, I much prefer Ed's suggestion of a PARMLIB member. That is much easier to review, implement and maintain down here in the trenches. Unless the PARMLIB member provides for an exit name, it would be of limited use. I see PARMLIB as the equivalent of reading a book - it may be interesting, but the capabilities are limited to what the author provides. An exit is closer to writing your own book, where (almost) anything goes. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 9/16/2013 10:37 AM, Paul Gilmartin wrote: Where I see such as: create new devices of TYPE=FBA attached to this control unit. Given that these devices are defined as Unit Record devices, they cannot be shared among users on a single system. Right. There is no such thing as a DISP=SHR sharing protocol for FBA files. All processing must be serialized using protocols similar to DISP=NEW/OLD/MOD. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 9/16/2013 11:01 AM, Peter Relson wrote: I guess Ed was asleep during that TDM session in Poughkeepsie grin z/OS 1.11 provided support for what I called deferred LPA. This was possibly not documented until 1.12. But it's definitely in the z/OS 1.11 CSVDYLPA. This is dynamic LPA done at the tail end of IPL using the LPA statements of the IPL-time PROGxx specification, such as LPA ADD DSN(my.pdse) MASK(*) /* Add all members of my.pdse to LPA*/ Prior to this support, LPA statements within the IPL-time PROGxx were ignored/rejected. Wow! I TOTALLY missed this Peter! :-[ Thanks for posting (and thanks even more for providing this function)... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
At the very least, there should be a parmlib member with a list of data sets, analogous to LPALSTxx (LPADYNxx?), that the system will use to automatically populate dynamic LPA during system initialization at the earliest possible opportunity after PDSE support becomes active. At least this would do away with the need for every developer to roll his/her own solution. I guess Ed was asleep during that TDM session in Poughkeepsie grin z/OS 1.11 provided support for what I called deferred LPA. This was possibly not documented until 1.12. But it's definitely in the z/OS 1.11 CSVDYLPA. This is dynamic LPA done at the tail end of IPL using the LPA statements of the IPL-time PROGxx specification, such as LPA ADD DSN(my.pdse) MASK(*) /* Add all members of my.pdse to LPA*/ Prior to this support, LPA statements within the IPL-time PROGxx were ignored/rejected. BUT rather than bring the IPL back from multiple CPUs to a single CPU at this point to process all of this stuff and not proceed until it's done (and thus defer the completion of IPL for work that does not care about this), this processing is done in parallel with all the things like IEACMD00 and COMMNDxx. Applications are given an interface by which they can wait for the completion of this processing (which in all likelihood, but cannot be guaranteed, will occur before they even start) if they have a need to do so. That is a programmatic interface (CSDYLPA REQUEST=DEFLPAWAIT along with CSVDYLPA REQUEST=QUERYDEFLPA) as well as utility program CSVDLPAW (EXEC PGM=CSVDLPAW or LINK EP=CSVDLPAW) as an early part of a job that needs to make sure that something in deferred LPA is indeed in before the job proceeds. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
