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 addition
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
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. Program
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, t
>My concern is that IBM will announce EOS for Enterprise Cobol 4.2 and we wi=
>ll not be ready.
We have sold hundreds of licenses of COBOL V5, and COBOL v6 is starting to go
fast as well. We have many customers who report more than 10,000 COBOL
programs compiled with COBOL V5 in production
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.
--
Re
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 improvem
le roll 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@L
> -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
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
Gilmartin
Sent: 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 I
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
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
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
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
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 to
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
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 FORTRAN
> 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 &quo
(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
> 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 time he
age by 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.
> 0
ction 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
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 inconsiste
riginal Message-
Date:Tue, 16 Feb 2016 21:48:37 +0100
From:"R.S."
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
"R.S."
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 recovery. I just want to add th
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
.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, 2016 07:37 AM
> >>> To: IBM-
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, 2016 07:37 AM
..@att.net
-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 wr
...
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, I think another go
..
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, I think another goo
Date:Sun, 14 Feb 2016 15:53:07 -0600
From:"Joel C. Ewing"
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 be restored. I would
c
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 CONSOLE.
>
>CONSOLE can't be achi
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 International
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
: 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
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 (thankfully)
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 except
Original 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 displa
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 capabiliti
Subject: [Bulk] 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 som
Message-
> 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 ac
half 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 RACF.
An RFE couldn't hurt if you find
-Original Message-
From: IBM Mainframe Discussion 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 thoug
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 o
st [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 resear
easy, just a LISTUSER TSO. If you 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 mis
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
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 automati
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 authori
essage-
> From: IBM Mainframe 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:
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 dost
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
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. With
SERV.UA.EDU]
> On Behalf 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
> > lear
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 t
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 a
MAIN@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,
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 o
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 ord
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 a
@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 (n
the exceptions 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
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 several
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 IBM
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 "m
)
Sent: Thursday, 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
!!
Thanks,
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
2: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 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.
&g
: 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
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
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 f
al Message-
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/serve
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 t
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
ashioned 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
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 fairly recently I beli
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 Ed
t; > 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
he 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
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 lis
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, if you have
>> an
eplacement"). 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
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 anot
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
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
aspirati
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
--
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
.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 Lichtenstein wrote:
Note that the binder has been producing program objects for over 25
years. It is difficult to make significant enhance
lti-GiB 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
dle 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 objects for over 25
years. It is difficult to make significant
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 an
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 alignm
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 <56a78e69.5010...@t-onli
itive 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
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
---
s the JCL which determines where the executable
program resides.
PL/I can create programs which do not require to be a Program Object. COBOL V5
cannot.
Aside 1: Without an "unless we feel like it" clause, I'm not buying a "we won't
do that" unless the Board are behi
On Tue, 26 Jan 2016 12:59:08 -0600, Paul Gilmartin wrote:
>On Tue, 26 Jan 2016 10:36:58 -0800, Charles Mills wrote:
>>
>>AFAIK, the Binder can do anything that the Linkage Editor can do. In
>>particular, the Binder is perfectly capable of producing a load module, which
>>is stored in a PDS, or a
On Tue, 26 Jan 2016 10:36:58 -0800, Charles Mills wrote:
>
>AFAIK, the Binder can do anything that the Linkage Editor can do. In
>particular, the Binder is perfectly capable of producing a load module, which
>is stored in a PDS, or a program object, stored in a PDSE or Unix file.
>
We had a prob
1 - 100 of 398 matches
Mail list logo
