COBOL subroutines replacing Assembler was Re: GOFF
On 21 Aug 2012 14:52:42 -0700, in bit.listserv.ibm-main you wrote: Ah, I see what you mean. Some of the routines could indeed be done now in COBOL. One routine gets the address of a working-storage area. There's also a date conversion routine that most likely could use LE services, if not be done in COBOL itself. The date conversion routine definitely can be done in COBOL Nonetheless, there are hundreds of programs that call these routines, and I have no intention of changing them! :-) Frank From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, August 21, 2012 9:54 AM Subject: Re: GOFF On 20 Aug 2012 16:20:17 -0700, in bit.listserv.ibm-main you wrote: Upgrades. Why do you ask? If they are upgrades, review them to see if the latest and greatest COBOL can do the job. This can ease future maintenance. INSPECT CONVERTING and some of the other things in the 1985 standard eliminated the need for some routines. Also routines written in COBOL can be included as sub-programs saving inter-module overhead. Clark Morris From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, August 20, 2012 5:05 PM Subject: Re: GOFF On 20 Aug 2012 15:13:03 -0700, in bit.listserv.ibm-main you wrote: I am converting to assembler subroutines, which are called by (Enterprise) COBOL programs to do various things, to make them re-entrant. Is there any reason I should not change my assembler options to specify GOFF? Are these brand new routines as opposed to upgrades of existing routines? Clark Morris -- 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
Is a PDSE with a RECFM=VB weird? I hope not because I use that format for my C/C++ source libraries that don't reside in the z/OS UNIX file system. Yes, that is weird. Check the archives for my woes with that format - both performance wise and corruption wise. In a large VB PDSE with many members, there is absolutely no caching from the PDSE address space(s), as that cache encompasses the full 4k page. And the cache is limited to ridiculously low values. So no effective directory caching last I looked. A 70.000 cyl PDSE with recfm=VB and about 1 members in ISPF 3.4 takes 90 seconds to open, and the time is spent doing I/O to DASD (I/O response time between 4-6ms - I traced that). Basically one I/O is done per member, often more than one. And those large PDSEs are prone to (undetected) corruption - several times since 2004, when we started using them. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
Can PDSE be in the linklist yes, for the last 25 years or so. or lpalist? no (and not too likely ever to be, any more than certain system data sets, such as SYS1.NUCLEUS, can be a PDSE). Dynamic LPA can be used to get modules from a PDSE into LPA. Is PDSE a reliable access method now yes. Various IBM products and elements of z/OS deliver modules via PDSE. with no greater error rate than PDS? I do not know. None of the GOFF object modules produced by the HLASM in recent weeks from my own code could, for example, be included in one. Many do not find the restrictions to be within constructs that they use. Obviously, as was mentioned, if you use external labels longer than 8 characters you are not part of that many. 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
PDSE (was RE: GOFF)
I am fairly risk adverse. Given the environment here with pain points associated with incidents such as abends, corrupted data, and so on, it only makes sense. But I prefer PDSE to PDS. I used to keep all my personal data in PDSEs. I now keep the majority of my data in z/OS UNIX files, where such is use reasonable to me. That is, basically, where I used to use PDSE libraries. The only thing I really don't keep in UNIX files are compiled non-UNIX programs. Mainly because I can't put a UNIX subdirectory in my STEPLIB. There are some good, to me, reason for my use of UNIX files instead of legacy libraries. 1) People here are reactionary and don't use new facilities often. So they don't look for my stuff in UNIX. So I don't need to explain why I have stuff and why I don't let them look at it. (all my data sets are UACC(NONE) with only select groups in the access list). 2) I like many of the UNIX utilities. Even as poorly as they are implemented by IBM vs. the GNU versions. I especially like grep, awk, and sed for text manipulation. For more difficult manipulation, I like Perl. And I've had the arguments with another that TSO/ISPF/REXX can, as they put it, do the same things and do it more easily. I disagree, but to each his own. I will admit that I really don't like vi very much. The PDF editor is much better. But I can use it to edit UNIX files, so there's no reason to avoid them. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Wednesday, August 22, 2012 8:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GOFF Like everyone else I had some early troubles with PDSEs, but I expected them, and I now find PDSEs less problematic (for the usual reasons) than PDSs. Long experience and its attendant decrepitude confer some [very] few advantages, one of which is the expectation that problems can and will be resolved. The classical deficiencies of PDSs are not much talked about by those who avoid PDSEs. They are accustomed to the deficiencies of the old and they want the new to behave much like the old, perhaps with a fillip or two of---but not too much---innovation. I have almost no sympathy with these notions and less with the rhetorical device of waving the bloody shirt; but I do recognize that my differences with reactionary, risk-averse people are visceral, not moral. 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: GOFF
Moreover, GOFF wots not of PDSs or load modules. Its use requires program objects resident in PDSEs. I do not believe this is correct. GOFF objects can be built into a load module. 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
Re: GOFF
I do have some programs which require GOFF to assemble and cannot reside in a PDS. But they are weird in that they are LE enabled DLLs written in HLASM. The program objects actually reside in a z/OS UNIX file, not a PDSE data set. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Jaffe Sent: Tuesday, August 21, 2012 10:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GOFF On 8/21/2012 7:49 AM, John Gilmore wrote: I discovered by making a sequence of experiments that Peter Relson is literally correct. My phrase wots not of was ill chosen. That conceded, the GOFF and XOBJ object modules that can be included in load modules bythe Binder must be denatured ones, shorn of their interesting properties. These restrictions are many, and I will not rehearse all of them here. Interested readers can scan z/OS MVS Program Management: User's Guide and Reference, SA22-7643-11 using the search argument GOFF. They are in fact so many that it is fair to say that GOFF [and XOBJ] object modules cannot IN GENERAL be included in load modules. None of the GOFF object modules produced by the HLASM in recent weeks from my own code could, for example, be included in one. There are indeed many restrictions, but few of them matter. All of our HLASM products on z/OS are currently built using GOFF. None of them yet require or are delivered via PDSE. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
On 20 Aug 2012 16:20:17 -0700, in bit.listserv.ibm-main you wrote: Upgrades. Why do you ask? If they are upgrades, review them to see if the latest and greatest COBOL can do the job. This can ease future maintenance. INSPECT CONVERTING and some of the other things in the 1985 standard eliminated the need for some routines. Also routines written in COBOL can be included as sub-programs saving inter-module overhead. Clark Morris From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, August 20, 2012 5:05 PM Subject: Re: GOFF On 20 Aug 2012 15:13:03 -0700, in bit.listserv.ibm-main you wrote: I am converting to assembler subroutines, which are called by (Enterprise) COBOL programs to do various things, to make them re-entrant. Is there any reason I should not change my assembler options to specify GOFF? Are these brand new routines as opposed to upgrades of existing routines? Clark Morris -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
We have reached the usual substantive and linguistic impasse. EJ writes that | There are indeed many restrictions, but few of them matter. My view is different. I, for example, find longer-than-8-character names very convenient, indeed essential in table-generation macros that generate a great many RSECTs. Moreover, while I do not wish to confound this issue with others, the continued use of load modules where program objects can be used instead seems to be to be at best unfortunate and at worst yet another example of retrograde technology clung to for the usual 'laudator temporis acti' reasons. À chacun son goût. 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: GOFF
Do customers of ISVs generally welcome products that require PDSE? I have encountered push-back on this issue. Not recently, but perhaps because I have learned to stop asking the question. EVERYONE has a story about a PDSE that failed on them in 1995. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, August 21, 2012 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GOFF On Tue, 21 Aug 2012 12:20:29 -0400, John Gilmore wrote: EJ writes that | There are indeed many restrictions, but few of them matter. My view is different. I, for example, find longer-than-8-character names very convenient, indeed essential in table-generation macros that generate a great many RSECTs. Also modern programming languages. Alas, our laboratory configuration precludes practical use of PDSE (too many systems at too broad a span of releases (some EOS) for Sysplex). Alas, alas, UNIX directories, a possible alternative, are not supported in STEPLIB concatenation. Feels like material for a Requirement. Do customers of ISVs generally welcome products that require PDSE? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
Several times in that era. On Tue, Aug 21, 2012 at 1:44 PM, Charles Mills charl...@mcn.org wrote: Do customers of ISVs generally welcome products that require PDSE? I have encountered push-back on this issue. Not recently, but perhaps because I have learned to stop asking the question. EVERYONE has a story about a PDSE that failed on them in 1995. Charles -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
Ah, I see what you mean. Some of the routines could indeed be done now in COBOL. One routine gets the address of a working-storage area. There's also a date conversion routine that most likely could use LE services, if not be done in COBOL itself. Nonetheless, there are hundreds of programs that call these routines, and I have no intention of changing them! :-) Frank From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, August 21, 2012 9:54 AM Subject: Re: GOFF On 20 Aug 2012 16:20:17 -0700, in bit.listserv.ibm-main you wrote: Upgrades. Why do you ask? If they are upgrades, review them to see if the latest and greatest COBOL can do the job. This can ease future maintenance. INSPECT CONVERTING and some of the other things in the 1985 standard eliminated the need for some routines. Also routines written in COBOL can be included as sub-programs saving inter-module overhead. Clark Morris From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, August 20, 2012 5:05 PM Subject: Re: GOFF On 20 Aug 2012 15:13:03 -0700, in bit.listserv.ibm-main you wrote: I am converting to assembler subroutines, which are called by (Enterprise) COBOL programs to do various things, to make them re-entrant. Is there any reason I should not change my assembler options to specify GOFF? Are these brand new routines as opposed to upgrades of existing routines? Clark Morris -- 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 -- 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: GOFF
On 21 Aug 2012 09:21:21 -0700, in bit.listserv.ibm-main you wrote: We have reached the usual substantive and linguistic impasse. EJ writes that | There are indeed many restrictions, but few of them matter. My view is different. I, for example, find longer-than-8-character names very convenient, indeed essential in table-generation macros that generate a great many RSECTs. Moreover, while I do not wish to confound this issue with others, the continued use of load modules where program objects can be used instead seems to be to be at best unfortunate and at worst yet another example of retrograde technology clung to for the usual 'laudator temporis acti' reasons. Can PDSE be in the linklist or lpalist? If not, this is like IBM not having a way for SNA channel attached 3270s as console devices because VTAM was set up as a started task. If PDSE is a basic access method, somehow having it as a started task seems weird to me. Is PDSE a reliable access method now with no greater error rate than PDS? Clark Morris À chacun son goût. 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: GOFF
A zero-PDS system? On Tue, 21 Aug 2012 18:54:00 -0300, Clark Morris wrote: Can PDSE be in the linklist or lpalist? If not, this is like IBM not having a way for SNA channel attached 3270s as console devices because VTAM was set up as a started task. If PDSE is a basic access method, somehow having it as a started task seems weird to me. Is PDSE a reliable access method now with no greater error rate than PDS? In contrast, in a Galaxy Far, Far Away, I was amazed to see OpenSolaris boot from ZFS (very different from zFS; GIYF). I mentioned this to a Solaris developer who said, Oh, sure; it just takes about a quarter megabyte support code in the boot record. If IBM had a similar level of commitment to PDSE it would be possible to IPL a system with _no_ PDS; only PDSE (or even only zFS (that one)). But it all depends on proper layering; it would require that very early in Nucleus Initialization components begin using access methods, not STARTIO nor RYO channel programs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
EVERYONE has a story about a PDSE that failed on them in 1995. 1995? As recent as 2009 in our case, IIRC. Thankfully not load module libraries in linklist. Admittedly 'weird' PDSEs with recfm=VB. Response by IBM when reported as a problem: You didn't have the ptf on when the corruption occured. (Name your favourite ptf that was applied half a year ago). Why do you think IBM now ships the integrity tool with the product (that used to get given out by level2)? Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
On 22/08/2012 1:48 PM, ibmmain wrote:VERYONE has a story about a PDSE that failed on them in 1995. 1995? As recent as 2009 in our case, IIRC. Thankfully not load module libraries in linklist. Admittedly 'weird' PDSEs with recfm=VB. Response by IBM when reported as a problem: You didn't have the ptf on when the corruption occured. (Name your favourite ptf that was applied half a year ago). Why do you think IBM now ships the integrity tool with the product (that used to get given out by level2)? Is a PDSE with a RECFM=VB weird? I hope not because I use that format for my C/C++ source libraries that don't reside in the z/OS UNIX file system. Barbara Nitz -- 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: GOFF
On 8/20/2012 3:11 PM, Frank Swarbrick wrote: I am converting to assembler subroutines, which are called by (Enterprise) COBOL programs to do various things, to make them re-entrant. Is there any reason I should not change my assembler options to specify GOFF? GOFF is only a problem if you need to link on a severely back-level binder or linkage editor or on a non-z/OS system. Otherwise, it's great! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@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
Re: GOFF
GOFF could, I suppose, be described as a problem, perhaps even a severe one, for the Linkage Editor. The Linkage Editor does not support GOFF at all. For it you must use the Binder. Moreover, GOFF wots not of PDSs or load modules. Its use requires program objects resident in PDSEs. Adjust what you are doing accordingly, and feel free to use the long[er] names that will be available to you. John Gilmore. Ashland, MA 01721 - USA On 8/20/12, Frank Swarbrick frank.swarbr...@yahoo.com wrote: Upgrades. Why do you ask? From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, August 20, 2012 5:05 PM Subject: Re: GOFF On 20 Aug 2012 15:13:03 -0700, in bit.listserv.ibm-main you wrote: I am converting to assembler subroutines, which are called by (Enterprise) COBOL programs to do various things, to make them re-entrant. Is there any reason I should not change my assembler options to specify GOFF? Are these brand new routines as opposed to upgrades of existing routines? Clark Morris -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
