Re: COBOL V5+

Thank you for your quick response Mr. Ross. The answer to your question is that we no longer have DEBUG TOOL, and the replacement vendor doesn't support the DWARF protocol/format.  I chose NOTEST(DWARF) because the documentation indicated that LE CEEDUMP was able to access/process the

Re: Cobol V5/V6

On 2016-08-31 02:53, Timothy Sipples wrote: Sharon Lopez wrote: >My concern is that IBM will announce EOS for Enterprise Cobol 4.2 >and we will not be ready. That's a healthy concern... Please put your reply on the Cobol V5/V6 thread, not the RD/z thread. Thank you. -- Regards, Gord

Re: Cobol V5/V6

Sharon Lopez wrote: >My concern is that IBM will announce EOS for Enterprise Cobol 4.2 >and we will not be ready. That's a healthy concern, in my view. Try to move to the current Enterprise COBOL release as soon as you reasonably can. Leaving aside support periods, there are some terrific

Re: Cobol V5/V6

l out. > > I hope this helps > > Lizette > > > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Lopez, Sharon >> Sent: Tuesday, August 30, 2016 7:12 AM >> To: IBM-MAIN@LISTSER

Re: Cobol V5/V6

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lopez, Sharon > Sent: Tuesday, August 30, 2016 7:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cobol V5/V6 > > My concern is that IBM will announce EOS for Ent

Re: Cobol V5/V6

Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, August 30, 2016 11:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol V5/V6 I have no statistical evidence, but my impression is

Re: Cobol V5/V6

: Tuesday, August 30, 2016 8:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Cobol V5/V6 On Tue, 30 Aug 2016 06:28:35 -0700, Lizette Koehler wrote: >We are not planning to upgrade to Cobol V5/6 until after z/OS V2.2 is >installed because that is the only level where IEFOPZxx is ava

Re: Cobol V5/V6

On Tue, 30 Aug 2016 06:28:35 -0700, Lizette Koehler wrote: >We are not planning to upgrade to Cobol V5/6 until after z/OS V2.2 is installed >because that is the only level where IEFOPZxx is available. > >Once that is available we will use the concatenation function in this parm to >use a PDSE

Re: Cobol V5/V6

Subject: Re: Cobol V5/V6 Sorry, the announcement is for 2015 not 2016. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Tuesday, August 30, 2016 6:29 AM > To: IBM-MAIN@LISTSERV.UA.ED

Re: Cobol V5/V6

Sorry, the announcement is for 2015 not 2016. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Tuesday, August 30, 2016 6:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C

Re: Cobol V5/V6

We are not planning to upgrade to Cobol V5/6 until after z/OS V2.2 is installed because that is the only level where IEFOPZxx is available. Once that is available we will use the concatenation function in this parm to use a PDSE dataset prior to a PDS dataset in our Production batch. z/OS 2.2

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

Radoslaw Skorupka wrote: >It's IMHO very obvious that offline RACFdb can be copied as regular dataset, >Actually I did mean copy of live RACF db with the tools like IEBGENER or >ADRDSSU (in monoplex) with no ill effects. So my *very limited* experience >says it is not so easy to get

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

:Tue, 16 Feb 2016 21:48:37 +0100 From:"R.S." <r.skoru...@bremultibank.com.pl> Subject: Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) W dniu 2016-02-15 o 12:48, Robert S. Hansel (RSH) pisze: I wholeheartedly agree with Joel's recommendation for having a backup copy of t

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

t;R.S." <r.skoru...@bremultibank.com.pl> Subject: Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) W dniu 2016-02-15 o 12:48, Robert S. Hansel (RSH) pisze: > I wholeheartedly agree with Joel's recommendation for having a backup copy of > the RACF database readily available for

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

W dniu 2016-02-15 o 12:48, Robert S. Hansel (RSH) pisze: I wholeheartedly agree with Joel's recommendation for having a backup copy of the RACF database readily available for recovery. I just want to add that it is crucial to use RACF utilities to create the backup and to allocate it with the

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

-715-0595 Mobile > >> jo.skip.robin...@att.net > >> > >> > >> -Original Message- > >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >>> On Behalf Of Ed Jaffe > >>> Sent: Sunday, Februa

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

Program Co-Manager >> 323-715-0595 Mobile >> jo.skip.robin...@att.net >> >> >> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >>> On Behalf Of Ed Jaffe >>> Sent: Sunday, February 14,

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Sunday, February 14, 2016 07:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) On 2/13/2016 8:04 PM, Skip Robinson wrote

Re: UADS (was Re: [Bulk] Re: COBOL v5)

... On 01-Feb-2016 9:57 PM, "John Eells" wrote: > I hadn't really thought about (or researched) the display capabilities of > RACF. An RFE couldn't hurt if you find them lacking. > > Once one's TSO/E administrative routines have been converted to use the > TSO segment, though,

Re: UADS (was Re: [Bulk] Re: COBOL v5)

.. On 01-Feb-2016 9:57 PM, "John Eells" wrote: > I hadn't really thought about (or researched) the display capabilities of > RACF. An RFE couldn't hurt if you find them lacking. > > Once one's TSO/E administrative routines have been converted to use the > TSO segment, though,

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

un, 14 Feb 2016 15:53:07 -0600 From:"Joel C. Ewing" <jcew...@acm.org> Subject: Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) But the only way to "fix"an unusable RACF database is to have a fairly recent backup copy of the RACF data base that can

Re: [Bulk] Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

On Sun, 14 Feb 2016 16:25:03 -0800, Ed Jaffe wrote: >On 2/14/2016 2:50 PM, Skip Robinson wrote: >> As I said earlier, we still use UADS in production. Only a handful of TSOE >> segments in order to support features that cannot be achieved otherwise, >> such as

Re: [Bulk] Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

On 2/14/2016 2:50 PM, Skip Robinson wrote: As I said earlier, we still use UADS in production. Only a handful of TSOE segments in order to support features that cannot be achieved otherwise, such as CONSOLE. CONSOLE can't be achieved via RACF? -- Edward E Jaffe Phoenix Software

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Ed Jaffe >> Sent: Sunday, February 14, 2016 07:37 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) >> >> On 2/13/2016 8:04 PM, Skip Robi

Re: [Bulk] Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

nframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Joel C. Ewing > Sent: Sunday, February 14, 2016 01:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) > > But the only way to "fix"an unusable

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

M-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ed Jaffe > Sent: Sunday, February 14, 2016 07:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) > > On 2/13/2016 8:04 PM, Skip Robinson wrote: > > This opinion is based on (thankful

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

On 2/13/2016 8:04 PM, Skip Robinson wrote: This opinion is based on (thankfully) limited experience. If you are forced to IPL without a usable RACF data base, you are totally scr*wed. During IPL, operator will be prompted to allow even READ access to *every* data set opened by *every* task

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

al Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Monday, February 1, 2016 08:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) I hadn't really thought about (or researched) the display capabilitie

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

ussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of John Eells > Sent: Monday, February 1, 2016 08:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) > > I hadn't really thought about (or researched) the display capabilities of RACF

Re: UADS (was Re: [Bulk] Re: COBOL v5)

] Re: UADS (was Re: [Bulk] Re: COBOL v5) Just curious: why one want to know acctnum of given person? More general: what are acctnums used for nowadays? Teaching RACF and z/OS I always recommend to set profile CL (ACCTNUM) * UACC(R) and forget. Only one shop's employes had some rules on acctnum

Re: UADS (was Re: [Bulk] Re: COBOL v5)

ion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, February 1, 2016 08:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [Bulk] Re: UADS (was Re: [Bulk] Re: COBOL v5) John Eells wrote: I hadn't really thought about (or researched) the display capabilities of RA

Re: UADS (was Re: [Bulk] Re: COBOL v5)

ary 1, 2016 08:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [Bulk] Re: UADS (was Re: [Bulk] Re: COBOL v5) John Eells wrote: I hadn't really thought about (or researched) the display capabilities of RACF. An RFE couldn't hurt if you find them lacking. I don't think there is any problem with the

Re: UADS (was Re: [Bulk] Re: COBOL v5)

age- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of R.S. > Sent: Tuesday, February 2, 2016 02:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: UADS (was Re: [Bulk] Re: COBOL v5) > > Just curious: why one want to know acctnum

Re: UADS (was Re: [Bulk] Re: COBOL v5)

UA.EDU] > On Behalf Of Elardus Engelbrecht > Sent: Monday, February 1, 2016 08:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: UADS (was Re: [Bulk] Re: COBOL v5) > > John Eells wrote: > > >I hadn't really thought about (or researched) the display capabilities of >

UADS (was Re: [Bulk] Re: COBOL v5)

I hadn't really thought about (or researched) the display capabilities of RACF. An RFE couldn't hurt if you find them lacking. Once one's TSO/E administrative routines have been converted to use the TSO segment, though, I think another good use of UADS is for recovery, including DR. It's the

Re: UADS (was Re: [Bulk] Re: COBOL v5)

John Eells wrote: >I hadn't really thought about (or researched) the display capabilities of >RACF. An RFE couldn't hurt if you find them lacking. I don't think there is any problem with the display capabilities. Actually, you use a RACF command or utility (RACF panels for example) to ask

Re: UADS (was Re: [Bulk] Re: COBOL v5)

On 02/01/2016 10:27 AM, John Eells wrote: > I hadn't really thought about (or researched) the display capabilities > of RACF. An RFE couldn't hurt if you find them lacking. > > Once one's TSO/E administrative routines have been converted to use > the TSO segment, though, I think another good use

Re: COBOL v5

Skip Robinson wrote: We ran an inherited ISAM application in the 80s, a true dog. Then we learned of a VSAM conversion aid that was at the time built in to whatever then passed for DFSMS. It was magical. Simply convert files from ISAM to VSAM and point the application to them. The system

Re: [Bulk] Re: COBOL v5

Benefits of move to UADS? Should be: Benefits of move *FROM* UADS? -- 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

Re: [Bulk] Re: COBOL v5

nframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ed Gould > Sent: Saturday, January 30, 2016 11:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: [Bulk] Re: COBOL v5 > > On Jan 30, 2016, at 11:11 AM, Skip Robinson wrote: > > > Ah, UADS. A p

Re: [Bulk] Re: COBOL v5

With all respect, I think there was enough time to move RYO tools to RACF segment. Proclib - ITYM logon procedue - I see no problem with that. More important: I see no problem to authorize users to all procedures, since it is method of customization, not resource access control Not to mention I

Re: [Bulk] Re: COBOL v5

lf Of R.S. > Sent: Friday, January 29, 2016 02:49 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: COBOL v5 > > W dniu 2016-01-29 o 19:17, Skip Robinson pisze: > > We ran an inherited ISAM application in the 80s, a true dog. Then we > > learned of a VSAM conve

Re: [Bulk] Re: COBOL v5

On Jan 30, 2016, at 11:11 AM, Skip Robinson wrote: Ah, UADS. A prime example of archaic mechanism. Defensible technically? Probably not, although a security administrator who needs to know which account numbers or which proclibs a user is authorized to use might tell a different story.

Re: Modern vs Legacy [was: RE: COBOL v5]

to this rule. Mike Wawiorko   -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: 29 January 2016 00:01 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Modern vs Legacy [was: RE: COBOL v5] Is it Friday yet? Well, just

Re: Modern vs Legacy [was: RE: COBOL v5]

​Myself, personally, stay "current" (as current as I can, at least). But for production I stay at "n-1", or maybe about a year in the past. I don't want to debug IBM's code.​ There is fundamental difference between being "n-1" and being obsolete. N-1 is conscious, prudent decision. One is aware

Re: COBOL v5

Well, let's see: a) 'Upgrade' to z/VSE (I know at least one such shop.) b) Stay on z/OS Tony Thigpen z/VSE Bigot R.S. wrote on 01/28/2016 05:28 PM: W dniu 2016-01-28 o 19:44, Charles Mills pisze: I cannot speak for IBM, but IMHO they may have felt that way at one time, but EC 5.2 is clearly

Re: Modern vs Legacy [was: RE: COBOL v5]

On Thu, Jan 28, 2016 at 6:01 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Is it Friday yet? Well, just a bit early. > > I remember those ISAM days all too well. Our solution to large ISAM > insert jobs was "update in reverse", i.e., sort the input in descending > ISAM key

Re: COBOL v5

@LISTSERV.UA.EDU Subject: Re: COBOL v5 I'm not sure about the ISAM part. I HATED ISAM. If you enjoy watching your jobs grind away seemingly foreverthen you liked ISAM. I've always loved VSAMmaybe because I hated ISAM so much. Ever have ISAM job that did an Update in Place (not file

Re: COBOL v5

LISTSERV.UA.EDU > Subject: [Bulk] Re: COBOL v5 > > Remember one of those from the early 70s when one of our monthly ISAM > update jobs would run for almost 24 hours. One of the smarter guys around at > the time looked at it and sorted the update file, which was mainly inserts, >

Re: COBOL v5

W dniu 2016-01-29 o 19:17, Skip Robinson pisze: We ran an inherited ISAM application in the 80s, a true dog. Then we learned of a VSAM conversion aid that was at the time built in to whatever then passed for DFSMS. It was magical. Simply convert files from ISAM to VSAM and point the application

Re: COBOL v5

On Fri, 29 Jan 2016 10:17:40 -0800, Skip Robinson wrote: >We ran an inherited ISAM application in the 80s, a true dog. Then we learned >of a VSAM conversion aid that was at the time built in to whatever then >passed for DFSMS. It was magical. Simply convert files from ISAM to VSAM and >point the

Re: COBOL v5

Sorry if I've confused the matter. What I meant was that only a very few important and relatively simple changes to the definition of OBJ objects and load module programs are made (nothing that would require new constructs). AMODE 64 is an example of one of those. Other than those, new

Re: COBOL v5

Hi Bill, Point taken. But my point was that if your JCL uses a PDS rather than a PDSE, in some cases you'll get the binder error "IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT BE SAVED IN LOAD MODULE FORMAT." As the PL/I procs do (the ones with "P" in their

Re: COBOL v5

To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 W dniu 2016-01-28 o 19:44, Charles Mills pisze: > I cannot speak for IBM, but IMHO they may have felt that way at one > time, but EC 5.2 is clearly an investment on IBM's part and a > commitment to the future of COBOL. > > You can't

Re: COBOL v5

Hmmm. IIRC, IBM asked customers for input as to addressing needs of COBOL. I understood that 64bit addressing was heard loud and clear. Sent from iPhone - small keyboard fat fingers - expect spellinf errots. > > Since COBOL does not and will not in the foreseeable future need > amode 64 I

Re: COBOL v5

W dniu 2016-01-28 o 19:44, Charles Mills pisze: I cannot speak for IBM, but IMHO they may have felt that way at one time, but EC 5.2 is clearly an investment on IBM's part and a commitment to the future of COBOL. You can't make an omelet without breaking eggs. "Add new features" and "make it go

Re: COBOL v5

, Tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, January 28, 2016 5:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 W dniu 2016-01-28 o 19:44, Charles Mills pisze: > I cannot speak for IBM, but I

Re: COBOL v5

@LISTSERV.UA.EDU Subject: Re: COBOL v5 W dniu 2016-01-28 o 19:44, Charles Mills pisze: > I cannot speak for IBM, but IMHO they may have felt that way at one > time, but EC 5.2 is clearly an investment on IBM's part and a > commitment to the future of COBOL. > > You can't make an

Re: COBOL v5

On Jan 28, 2016, at 12:44 PM, Charles Mills wrote: I cannot speak for IBM, but IMHO they may have felt that way at one time, but EC 5.2 is clearly an investment on IBM's part and a commitment to the future of COBOL. You can't make an omelet without breaking eggs. "Add new features" and

Modern vs Legacy [was: RE: COBOL v5]

y, January 28, 2016 6:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 I'm not sure about the ISAM part. I HATED ISAM. If you enjoy watching your jobs grind away seemingly foreverthen you liked ISAM. I've always loved VSAMmaybe because I hated ISAM so much. Ever have ISAM job that did a

Re: COBOL v5

On Jan 28, 2016, at 4:24 PM, Stevet wrote: Hmmm. IIRC, IBM asked customers for input as to addressing needs of COBOL. I understood that 64bit addressing was heard loud and clear. Sent from iPhone - small keyboard fat fingers - expect spellinf errots. Stevet: Look at the archives on

Re: COBOL v5

ned load module" are potentially inconsistent requirements. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, January 27, 2016 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 Peter: I agree with you.

PDSE was Re: COBOL v5

mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Frank Swarbrick >> Sent: Monday, January 25, 2016 09:01 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [Bulk] Re: COBOL v5 >> >> The one reason I know of what a PDSE is required is because TEST/DEBUG >> informati

Re: COBOL v5

On Wed, 27 Jan 2016 16:31:17 -0500, Farley, Peter wrote: >Some of us may have to be dragged kicking and screaming into >that 64-bit future because of PDSE-fear, but it is coming nonetheless. There is another impediment, IMO. That is that XPLINK-64 cannot easily coexist with either XPLINK-31 or

Re: COBOL v5

In article <2525643717796095.wa.m42tomibmmainyahoo@listserv.ua.edu> you wrote: > On Wed, 27 Jan 2016 16:31:17 -0500, Farley, Peter wrote: > >Some of us may have to be dragged kicking and screaming into > >that 64-bit future because of PDSE-fear, but it is coming nonetheless. > There is

Re: COBOL v5

On Wed, 27 Jan 2016 18:36:02 -0500, Don Poitras wrote: >In article <2525643717796095.wa.m42tomibmmainyahoo@listserv.ua.edu> you >wrote: > >> There is another impediment, IMO. That is that XPLINK-64 cannot easily >> coexist with either XPLINK-31 or with standard linkage. So,

Re: COBOL v5

It's not the JCL per-se. The combination of XOBJ object modules and the Prelinker was a tactical solution to advancements in programs, originally created for C programs. XOBJ object modules addressed several deficiencies in OBJ object modules, such the ability to have long case-sensitive

Re: COBOL v5

If/when PL/1 supports 64-bit, the executable will have to live in a program object if compiled 64-bit. That's the same state of the C compiler today. It's not the 64-bit part that requires that, but XPLINK which is required to run 64-bit with IBM's compilers. In article

Re: COBOL v5

of main-storage data accessed by a program. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, January 27, 2016 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 On Jan 27, 2016, at 11:25 AM, Barry

Re: COBOL v5

On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote: It's not the JCL per-se. The combination of XOBJ object modules and the Prelinker was a tactical solution to advancements in programs, originally created for C programs. XOBJ object modules addressed several deficiencies in OBJ

Re: COBOL v5

f Ed Gould Sent: Wednesday, January 27, 2016 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote: Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ obj

Re: COBOL v5

into that 64-bit future because of PDSE-fear, but it is coming nonetheless. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, January 27, 2016 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5

Re: COBOL v5

On Wed, 27 Jan 2016 13:40:38 -0600, Ed Gould wrote: > >Since COBOL does not and will not in the foreseeable future need >amode 64 I find the argument un helpful. > I think the argument was intended to be taken as a frinstance. -- gil

Re: COBOL v5

Charles Mills wrote: I was going to post about this but could not remember whether it was still under NDA or not and was too busy to research. Yes! Customers told IBM what has been posted on this thread: "COBOL v5.2 is out of the question because we have existing load modules in (PDS)

Re: COBOL v5

On Jan 26, 2016, at 4:05 AM, Bill Woodger wrote: Thanks Peter Farley and Don Poitras. I last used listserv in about 1999. Wow I thought, they've got a gui now. Err, no. So I subscribed with the message in the subject. Hah. Nope. They've changed that bit. And making another attempt to get a

Re: COBOL v5

Well, the OPZ name would tend to support you on that ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Tuesday, January 26, 2016 4:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 Charles Mills

Re: COBOL v5

IIRC: At Share 2015 in Seattle, wasn't it stated that the COBOL 5 code generator is the one that PL/1, C/C++, and a few others are using or will (soon) be using? IOW: The "architecture aware" code generator was going to be common. That means it will be generating program objects. Regards,

Re: COBOL v5

On Tue, 26 Jan 2016 04:05:17 -0600, Bill Woodger wrote: >Thanks Peter Farley and Don Poitras. I last used listserv in about 1999. Wow I >thought, they've got a gui now. Err, no. So I subscribed with the message in >the subject. Hah. Nope. They've changed that bit. And making another attempt

Re: COBOL v5

In the PL/1 mailing list, Peter Elderon (IBM) explicitly stated that there are no plans to force the PL/1 users to PDSEs, so IMO this is not true for PL/1, at least. Kind regards Bernd Am 26.01.2016 um 15:10 schrieb Steve Thompson: IIRC: At Share 2015 in Seattle, wasn't it stated that the

Re: COBOL v5

On Tue, Jan 26, 2016 at 7:39 AM, Ed Gould wrote: > On Jan 26, 2016, at 4:05 AM, Bill Woodger wrote: > >> Yes, it does mention the PDS thing. No, it doesn't work on V5 programs. >> >> Enterprise COBOL generating Program Objects is not new with V5. It is new >> that all

Re: COBOL v5

Well, gee guys, you can't always have it both ways. "I want feature X but I don't want to be forced into prerequisite Y." Sometimes it does not work that way. Sometimes there is a "hard" reason -- feature X is truly built on top of Y -- and sometimes developers just do things a certain way. "I

Re: COBOL v5

I use Enterprise PLI V3 and it does require you to compile into a PDSE -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Tuesday, January 26, 2016 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5

Re: COBOL v5

On Tue, 26 Jan 2016 10:48:40 -0600, Bill Woodger wrote: >On Tuesday, 26 January 2016 16:22:32 UTC, Warren, Cliff wrote: >> I use Enterprise PLI V3 and it does require you to compile into a PDSE > >The PROC you are using is set up to use the Binder. Other PROCs are set >up to use the

Re: COBOL v5

@LISTSERV.UA.EDU Subject: Re: COBOL v5 On Tue, 26 Jan 2016 10:48:40 -0600, Bill Woodger wrote: >On Tuesday, 26 January 2016 16:22:32 UTC, Warren, Cliff wrote: >> I use Enterprise PLI V3 and it does require you to compile into a >> PDSE > >The PROC you are using is set up to use th

Re: COBOL v5

FALAICR listserv.ua.edu/archives/ibm-main.html In a message dated 1/26/2016 9:06:29 A.M. Central Standard Time, 000433f07816-dmarc-requ...@listserv.ua.edu writes: That worked. But try: https://listserv.ua.edu/cgi-bin/wa?A0=IBM-MAIN

Re: COBOL v5

You are not alone, but this request has not prevailed. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Monday, January 25, 2016 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 At 10:00

Re: COBOL v5

if it were based on fundamental technology. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Monday, January 25, 2016 11:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 At 15:55 -0700 on 01/23/201

Re: COBOL v5

016 10:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: COBOL v5 > > On 2016-01-25 11:24, Skip Robinson wrote: > > > > -- Here's a serious inhibitor for some shops. Despite decades of > > advice to the contrary, some shops still share application load > > li

Re: COBOL v5

the PDSE.DSN has all members, you can drop the PDS.DSN and rename. On Mon, Jan 25, 2016 at 1:14 PM, Robert A. Rosenberg <hal9...@panix.com> wrote: > At 10:00 -0700 on 01/25/2016, Frank Swarbrick wrote about Re: COBOL v5: > >> The one reason I know of what a PDSE is required is

Re: COBOL v5

. What V3 PO features are they? I do not know. > Date: Mon, 25 Jan 2016 11:55:51 -0600 > From: edgould1...@comcast.net > Subject: Re: COBOL v5 > To: IBM-MAIN@LISTSERV.UA.EDU > > That *assumes* you use those facilities. > > Ed > On Jan 25, 2016, at 11:00 AM, Frank Swar

Re: COBOL v5

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 25, 2016 1:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 Of course. I knew that when I wrote it. Nonetheless, it is true. Suppose IBM added a restriction that the output of the

Re: COBOL v5

We'll hide behind the chainsaws! In a message dated 1/25/2016 2:08:49 P.M. Central Standard Time, jo.skip.robin...@att.net writes: They may get out alive, but don't bet on it. -- For IBM-MAIN subscribe / signoff /

Re: COBOL v5

On Mon, 25 Jan 2016 11:41:50 -0700, Paul Gilmartin wrote: >Can COBOL v5 objects be bound into UNIX files? Yes. A program object can be stored in either a PDSE or a Unix file. -- Tom Marchant -- For IBM-MAIN subscribe /

Re: COBOL v5

NK requires PO and will be used for AMODE 64 " HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Monday, January 25, 2016 2:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 At 15:55 -0700 on

Re: COBOL v5

On 2016-01-25 12:28, Tom Marchant wrote: > On Mon, 25 Jan 2016 11:41:50 -0700, Paul Gilmartin wrote: > >> Can COBOL v5 objects be bound into UNIX files? > > Yes. A program object can be stored in either a PDSE or a Unix file. > Understood. I even believe that only Program Objects, not Load

Re: COBOL v5

On Mon, Jan 25, 2016 at 1:33 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On 2016-01-25 12:28, Tom Marchant wrote: > > On Mon, 25 Jan 2016 11:41:50 -0700, Paul Gilmartin wrote: > > > >> Can COBOL v5 objects be bound into UNIX files? > > > > Yes. A program object

Re: COBOL v5

At 15:55 -0700 on 01/23/2016, Lizette Koehler wrote about Re: COBOL v5: And, yes, what they said. IBM requires PDS/E due to Program Objects being created by Cobol V5. This is a Cop-Out answer/reason in my opinion. The real question is "What is Cobol V5 creating that needs the Program O

Re: COBOL v5

At 10:00 -0700 on 01/25/2016, Frank Swarbrick wrote about Re: COBOL v5: The one reason I know of what a PDSE is required is because TEST/DEBUG information is now stored in a DWARF NOLOAD segment, and those are only supported by PDSE (or UNIX directory). So have a compile time switch to put

Re: COBOL v5

The one reason I know of what a PDSE is required is because TEST/DEBUG information is now stored in a DWARF NOLOAD segment, and those are only supported by PDSE (or UNIX directory). > Date: Sat, 23 Jan 2016 14:55:31 -0800 > From: charl...@mcn.org > Subject: Re: COBOL v5 >

Re: COBOL v5

In article <53170c7c-8ea7-4a0d-bc3d-1891b98ec...@googlegroups.com> you wrote: > On Monday, 25 January 2016 17:00:42 UTC, Frank Swarbrick wrote: > > The one reason I know of what a PDSE is required is because TEST/DEBUG > > information is now stored in a DWARF NOLOAD segment, and those are only

  1   2   >