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

COBOL V5+

l will be the same in COBOL V5/V6 as in earlier COBOL versions, so it is not a migration problem in general, it is only a problem when the subprogram s over-writes storage beyond the end of WORKING-STORAGE. >Removing them one at a time, compiling, new copying, and testing in the >CICS reg

COBOL V5+

We are in the process of migrating from COBOL V4.2 to V6.2.  We are using most if not all of the options that relate to testing (e.g. PC, RULES, NC, SSR, etc.) when compiling for test environments.  Additionally we have NOTEST(DWARF) set for both testing and production compile options. 

Re: ABO Automatic Binary Optimizer/COBOL V5/V6 Migration

me of the=20 >optimization provided by the new hardware. I know this was a while ago, but I wanted to comment on the reference to 'convert your source to V6'. In general, all programs compile cleanly with COBOL V5 and COBOL V6. If there are problems, and about 25% of customers have had some, they are ca

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

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

At one point there was a trail version for both COBOL V5 and V6 that you could download. If that is still around that would be a way to try out COBOL V5 or V6 with some of your favorite "bad" programs to see what happens before the clock starts ticking. Thanks.. Paul Feller AGT

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

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

Cobol V5/V6

Have a lot of shops migrated to COBOL V5/V6? Does anyone have a project plan they would like to share with me? Is the IEFOPZxx member only available in z/OS 2.2? Thanks to everyone in advance. Email correspondence to and from this address may be subject

New Enterprise COBOL V5/V6 Migration Assistant, and Binary Optimizer Trial

IBM just introduced a new, Web-based, interactive COBOL Migration Assistant that augments the Enterprise COBOL V5 and V6 Migration Guides. The online Enterprise COBOL V5/V6 Migration Assistant is available here: https://cobol-migration-assistant.mybluemix.net And/or, as a reminder, if you'd like

Re: A couple of interesting COBOL V5 fixes

I see the Linkage "Problem" as one that should continue to work as it did in V4. After all, many languages use a simple pointer to refer back to the real storage in the calling program. Other things, such as overrunning an array's subscript, which was a favourite trick of mine in my

Re: A couple of interesting COBOL V5 fixes

On Behalf Of Frank Swarbrick > Sent: Monday, May 23, 2016 1:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] A couple of interesting COBOL V5 fixes > > Very interesting stuff, Bill. Thanks for pointing them out! > > Just goes to show that some shops did "

Re: A couple of interesting COBOL V5 fixes

ring (and why would they) how shops might have "abused" unintended/undefined behaviors, it also shows that shops often do depend on these unintended/undefined behaviors. Frank > Date: Sun, 22 May 2016 04:00:37 -0500 > From: bill.wood...@gmail.com > Subject: A couple of in

A couple of interesting COBOL V5 fixes

> We have lots of COBOL that does exactly this. I voiced our concerns to Tom > Ross (aka Captain COBOL) on a GSE COBOL WorkGroup meeting in January. Tom was > there and gave presentations about COBOL v5 and ABO. Very interesting to meet > him and hear him speak. At that ti

Re: A couple of interesting COBOL V5 fixes

y using a PIC X(1) linkage section data- > item and then reading or writing beyond the bounds of that array. This APAR > will add this type of support to COBOL V5 to make the behavior consistent > with COBOL V4. > > LINKAGE Example: > > WORKING-STORAGE SECTION. > 01 wr

A couple of interesting COBOL V5 fixes

data-item and then reading or writing beyond the bounds of that array. This APAR will add this type of support to COBOL V5 to make the behavior consistent with COBOL V4. LINKAGE Example: WORKING-STORAGE SECTION. 01 wrk-len PIC s9(08) binary. LINKAGE SECTION. 01 L-St

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)

don't have access, ask for access to class FIELD, profile USER.TSO.* or ask for output from a fresh IRRDBU00 + ICETOOL job. >This difference alone has inhibited conversion in some shops. How so? What conversion? Can you give examples? I may have missed something, but I did not fully followed t

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: UADS vs TSO Segment [was: COBOL v5]

On 01/30/2016 01:05 PM, Ed Gould wrote: > 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

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: Binder (was: COBOL v5)

On 26 January 2016 at 13:59, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > We had a problem, appearing only fairly recently I believe, where a customer > using non-IBM software on non-IBM hardware found load modules produced > by Binder failing. Regressing to Linkage

Re: COBOL v5

d job, the Prelinker has several > > drawbacks, such as the inability to incrementally rebind a module > > so created (read "csect replacement"). The prelinker does not > > handle GOFF object modules such as produced by C/C++ with XPLINK > > and COBOL V

Re: COBOL v5

ile it does the intended job, the Prelinker has several drawbacks, such > > as the inability to incrementally rebind a module so created (read "csect > > replacement"). The prelinker does not handle GOFF object modules such as > > produced by C/C++ with XPLINK

Re: Binder (was: COBOL v5)

http://www.fujitsu.com/global/products/computing/servers/mainframe/globalserver/ On Thu, Jan 28, 2016 at 10:39 AM, Tony Harminc wrote: > On 26 January 2016 at 13:59, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: >> We had a problem, appearing only

COBOL v5

Does anyone watch YouTube? https://www.youtube.com/watch?v=JLMqkuou2-s That seems to exhibit commitment for the future of COBOL on IBM Mainframes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: Binder (was: COBOL v5)

ssage- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, January 28, 2016 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Binder (was: COBOL v5) http://www.fujitsu.com/global/products/computing/servers/ma

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: Binder (was: COBOL v5)

On Thu, 28 Jan 2016 03:57:53 -0600, Yong Yin wrote: >Hi Gil: >This is Yong (Ian) Yin of binder team. >Would you please provided more information about this problem? Such as JCL, >JES output. >Thanks. > Thank you for your interest. As I said, Linkage Editor continues to work for us. I talked

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: Binder (was: COBOL v5)

Hi Gil: This is Yong (Ian) Yin of binder team. Would you please provided more information about this problem? Such as JCL, JES output. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

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

On 25 Jan 2016 10:24:42 -0800, in bit.listserv.ibm-main you wrote: >A bigger question than whether COBOL V5 requires PDSE load library--yes it >does--is why that requirement causes so much consternation in the customer >community. Based on discussions at SHARE, I think there are seve

COBOL v5

placement"). The prelinker does not handle GOFF object modules such as > produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define > characteristics of a program which cannot be represented in a load module. > > Note that the binder has been producing program obje

Future shock (Was: COBOL v5)

On Wed, 27 Jan 2016 10:59:52 -0800, Ed Jaffe wrote: > >If old-school OBJ modules now support quad-word alignment, why does >HLASM warn for NOGOFF with SECTALGN(16)? > >** ASMA216W Quad-word alignment in NOGOFF object text > Perhaps as an early warning to any programmer suspected of having

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

external symbol names. While it does the intended job, the Prelinker has several drawbacks, such as the inability to incrementally rebind a module so created (read "csect replacement"). The prelinker does not handle GOFF object modules such as produced by C/C++ with XPLINK and COBOL

Quadword Alignment in OBJ Modules (Was: COBOL v5)

On 1/27/2016 9: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 object module and load module formats. Some important things have been added such as AMODE 64 and quad-word

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: Quadword Alignment in OBJ Modules (Was: COBOL v5)

Ed Jaffe wrote: On 1/27/2016 9: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 object module and load module formats. Some important things have been added such as AMODE 64

Re: COBOL v5

OFF object modules such as produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define characteristics of a program which cannot be represented in a load module. Note that the binder has been producing program objects for over 25 years. It is difficult to make significant en

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

I guess I have to disagree with that assessment as well. What is COBOL V5 but a pathway into the future for COBOL? With the new shared code generation back-end, getting to AMODE64 COBOL is a SMOP for Tom Ross and the COBOL team at IBM. Some of us may have to be dragged kicking and screaming

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

COBOL v5

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 post on the list itself... I don't think the Binary

Re: COBOL v5

er is IBM's solution to "recompiling is out of the question -- we have no idea whether we have source and/or whether it is current." Actually, if I recall correctly, the IEFOPZxx function was originally built solely with the optimizer in mind. The realization that it had value for

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

Regards, Steve Thompson On 01/25/2016 03:00 PM, Mullen, Patrick wrote: http://www-01.ibm.com/support/docview.wss?uid=swg27041176 gives a bit of detail, following the statement: "IBM has investigated the possibility of changing COBOL V5 to support Load Modules and PDS load lib

  1   2   3   4   >