We are going to eventually install 2.1 in the future.
Besides the OS we have to decide how handle the new COBOL 5.1 and it's
dependencies towards Fault Analyzer, Debug Tool and other productivity tools.
E g which version/release is required for a certain product to work with
another product.
An
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas Berg
Sent: Friday, September 06, 2013 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
We are going to eventually install 2.1 in the
> With COBOL 5.1, AFAIK, comes also the requirement of the load libraries to be
> PDSE. Which we DON'T have today, neither in production or test systems.
You have PDSEs on your Sysres. If you run DB2 you have PDSEs. PDSEs don't have
to be SMS-managed. The only problem you may have is that PDSE
53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Thomas Berg
Sent: Friday, September 06, 2013 5:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS 2.1
06, 2013 5:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
We are going to eventually install 2.1 in the future.
Besides the OS we have to decide how handle the new COBOL 5.1 and it's
Don't know for COBOL, but
we have some experience with PL/1 here, and as long as you
don't use some of the fancier new options like RENT, DLL etc.,
you don't need your output libraries to be PDSEs, because the
resulting load objects don't have the properties that need them to be
GOFFs or program
, David
Sent: Friday, September 06, 2013 5:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool,
etc.
A quick look in the ENT COB 5.1 migration guide does turn up this jewel...
Binding (link-editing) Enterprise COBOL programs
What is the
@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Friday, September 06, 2013 5:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool,
etc.
Dave,
I think this redbook may help
http://www.redbooks.ibm.com/redbooks/pdfs/sg246106.pdf
The binder
Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bob Shannon
> Sent: Friday, September 06, 2013 1:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug
> Tool, etc.
&g
UA.EDU
> Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug
> Tool, etc.
>
> What version of Cobol are you running now?
>
> I would also look at the migration guides for z/OS V2.1 and COBOL
>
> For cobol:http://publibfp.boulder.ibm.com/epubs/pdf/c147
nal Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Friday, September 06, 2013 1:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug
> Tool, etc.
>
Regarding PDSE, from migration guide:
Link edit/bind changes with Enterprise COBOL Version 5.1
There have been a number of changes to link editing or binding Enterprise COBOL
5.1 programs.
* The DFSMS Program Management Binder must be used to bind (link edit)
Enterprise COBOL V5 applications. T
Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side
file as was used previously.
COBOL V5 is the first of the compilers to convert to DRAWF (C already
supported it), this is part of IBM's change to have all the compilers share the
backend code generator ( same one us
(Publ)
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bohn, Dale
> Sent: Friday, September 06, 2013 3:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer,
Does anyone have an experience (= have used) with COBOL 5.1 and/or PD Tools
under z/OS 2.1 ?
Best Regards
Thomas Berg
___
Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ)
On Fri, 6 Sep 2013 05:34:19 -0700, Lizette Koehler wrote:
>The binder supports
>... an entirely new object module format, called GOFF.
GOFF is an enhanced form of an object module that HLASM has produced since
at least HLASM 1.3 in 1998. AFAIK, GOFF is necessary for the object module
(the out
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Thomas Berg
Sent: Friday, September 06, 2013 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Do you know if you could use PD
While the V12 FA, FM, DB support Enterprise COBOL V5, it will be supported in
the NEXT Version of APA (4Q13).
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the mess
M-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Friday, September 06, 2013 3:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug
> Tool, etc.
>
> We have all the PD tools at V12
f Of Bohn, Dale
> Sent: Friday, September 06, 2013 3:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug
> Tool, etc.
>
> While the V12 FA, FM, DB support Enterprise COBOL V5, it will be
> supported in
To those people who are suprised by the PDSE requirement for Enterprise COBOL
V5.
When was the last time you or someone from your shop went to SHARE?
IF so, why have so few come to the "Language Environment Futures Workshop"
session ?
They have been talking about "COBOL NEXT" (V5) changes for yea
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Thomas Berg
Sent: Friday, September 06, 2013 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Thanks. No problems when using them I suppose ?
Best Regards
frame Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas Berg
> Sent: Friday, September 06, 2013 9:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool,
> etc.
>
> Thanks.
Sorry about that. The last two paragraphs of my previous post should be
There is nothing analogous to the HLASM option alternatives
NOGOFF|GOFF available for COBOL 5.1. COBOL source libraries can
continue to be PDSs, but COBOL executables must be stored in PDSEs.
This should hold no terrors fo
>If I am reading this correctly, the BINDER would need to use a PDSE output
>file if there is JAVA, C/C++ type of programs. If you have native cobol,
>then you might be able to continue the LKED with BINDER to a non PDSE.
No, the COBOL Migration Guide is correct, all COBOL programs produce GOFF
o
.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tom Ross
Sent: Saturday, September 07, 2013 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool,
etc
>If I
Lizette,
You are not misunderstanding the situation. The documentation is
clear, and Tom Ross has removed the last vestige of ambiguity (if in
fact there was any).
Qua sysprog, I am sure thjat you are aware that PDSEs are problematic
early in an IPL process; but none of these problems obtains fo
On Sat, 7 Sep 2013 21:52:07 -0400, John Gilmore wrote:
>Qua sysprog, I am sure thjat you are aware that PDSEs are problematic
>early in an IPL process; but none of these problems obtains for COBOL
>APs.
Very late to this, so sorry if my concerns have been answered earlier.
What about shops with
In <0810432924290538.wa.dbohnaegonusa@listserv.ua.edu>, on
09/06/2013
at 08:16 AM, "Bohn, Dale" said:
>The non-loaded class are only supported in the PM3(?) load modules
>which the binder will only put into a PDSE.
Don't confuse load modules with program objects. The BINDER will only
crea
In
<4ee2851a2279b94cb70cd69b17410609ae51c...@s1flokydce2kx01.dm0001.info53.com>,
on 09/06/2013
at 12:01 PM, "Jousma, David" said:
>A program object is a new style GOOF executable that is the output
>from the binder when binding an object module from Enterprise
>COBOL V5.1.
No. A program obj
In , on 09/07/2013
at 09:22 AM, Tom Ross said:
>No, the COBOL Migration Guide is correct, all COBOL programs
>produce GOFF output with COBOL V5, so after Binding you will have
>a program object and it must reside in a PDSE.
It's not the use of GOFF per se that requires program objects, it's
Shane's surmise that the PDSE requirement for COBOL 5.1 executables
will slow its adoption in many shops is certainly correct. All such
requirements do so.
Where Shane and I differ, and I suspect that this difference is
visceral, is that I am radically impatient with the "conservatism" of
these s
17
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Gilmore
Sent: Sunday, September 08, 2013 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Shane's surmise that t
It is true that 5.1 resource requirements for compilation [AND for
binding] are greater, but the resulting program objects are measurably
more efficient. Both residence time and resource usage are reduced.
In an engineering shop, in which compilations are often executed only
a few times, this wou
> It is true that 5.1 resource requirements for compilation [AND for binding]
> are greater, but the resulting program objects are measurably more efficient.
>
Can you point me to the data that supports that claim? Thanks.
Bob Shannon
Rocket Software
-
I see that in January the price for COBOL V3 and V4 will be raised to
equal V5. So there's one reason not to upgrade that no longer exists.
--
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com
--
For IBM-MAIN subscribe
>In , on 09/07/2013
> at 09:22 AM, Tom Ross said:
>
>>No, the COBOL Migration Guide is correct, all COBOL programs=20
>>produce GOFF output with COBOL V5, so after Binding you will have=20
>>a program object and it must reside in a PDSE.
>
>It's not the use of GOFF per se that requires program o
2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool,
etc
>In , on 09/07/2013
> at 09:22 AM, Tom Ross said:
>
>>No, the COBOL Migration Guide is correct, all COBOL programs=20
>>produce GOFF output with COBOL V5, so after Binding you will have=20 a
>>program obj
: Sunday, September 08, 2013 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Shane's surmise that the PDSE requirement for COBOL 5.1 executables
will slow its adoption in many shops is certainly correct. All such
requirements do
In
<4ee2851a2279b94cb70cd69b17410609ae9bb...@s1flokydce2kx01.dm0001.info53.com>,
on 09/09/2013
at 11:53 AM, "Jousma, David" said:
>I'm pretty sure that most of them will be converted with a simple
>DFDSS job
If there is no PDS sharing across sysplex boundaries.
--
Shmuel (Seymour J.) M
>Could you share the SHARE presentations you have given on COBOL V5?
You can download them from the SHARE website (www.share.org).
Bob Shannon
Rocket Software
--
For IBM-MAIN subscribe / signoff / archive access instructions,
se
On 09/09/2013 10:08 AM, David Andrews wrote:
> I see that in January the price for COBOL V3 and V4 will be raised to
> equal V5. So there's one reason not to upgrade that no longer exists.
>
Just a radical thought...
>From users' standpoint IBM could have achieved an even better impetus
for migra
I agree,
This essentially makes in mandatory to be SMS on any volume and that
means a lot of rule changes in the SMS constructs and in addition
forcing SMS on just about any type of load module PDSE's. IN
addition it seems to make in necessary for the whole SMS
infrastructure to be in pla
> This essentially makes in mandatory to be SMS on any volume and that means a
> lot of rule changes in the SMS constructs and in addition forcing SMS on just
> about any type of load module PDSE's.
>IN addition it seems to make in necessary for the whole SMS infrastructure to
>be in place day
On 9/9/2013 9:58 AM, Ed Gould wrote:
This essentially makes in mandatory to be SMS on any volume and that
means a lot of rule changes in the SMS constructs and in addition
forcing SMS on just about any type of load module PDSE's. IN addition
it seems to make in necessary for the whole SMS infra
On Mon, Sep 9, 2013 at 12:19 PM, Bob Shannon wrote:
> > This essentially makes in mandatory to be SMS on any volume and that
> means a lot of rule changes in the SMS constructs and in addition forcing
> SMS on just about any type of load module PDSE's.
> >IN addition it seems to make in necessary
Around here, this is another nail in the z/OS coffin. My manager is trying
to get price reductions from our current software vendors. His plea is
"give us an execute-only, no-support contract at a reduced price".
Basically we are being "stabilized" at our current levels. IT management
has been told
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Monday, September 09, 2013 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
In
<4ee2851a2279b94cb70cd69b17410609ae
>On Sat, 7 Sep 2013 21:52:07 -0400, John Gilmore wrote:
>
>>Qua sysprog, I am sure thjat you are aware that PDSEs are problematic
>>early in an IPL process; but none of these problems obtains for COBOL
>>APs.
>
>Very late to this, so sorry if my concerns have been answered earlier.
>What about sho
Bob,
I know of at least one shop that is fairly large ( 3+ 6 way
sysplexes) and has a minimal SMS configuration (and some must have OS
allowances for PDSe's and HFS's(ZFS) etc) but there are staunchly
anti SMS (they have purchased another SMS look alike product). I
honestly don't think t
Frank
>
> From: Tom Ross
>To: IBM-MAIN@LISTSERV.UA.EDU
>Sent: Monday, September 9, 2013 9:18 AM
>Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
>
>
>>In , on 09/07/2013
>> at 09:22 AM, Tom Ross said:
>>
>>>No, the CO
Tom,
Why convert to PDSE? I am curious? A stated IBM direction?
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 9, 2013, at 11:18 AM, Tom Ross wrote:
>> In , on 09/07/2013
>> at 09:22 AM, Tom Ross said:
>>
>>> No, the COBOL Migration Guide is
Tom,
> >Very late to this, so sorry if my concerns have been answered earlier.
> >What about shops with a ring of monoplexes ?. The sysplex scope is each ind=
> >ividual monoplex - but the sharing boundary is the larger GRSplex. Latch co=
> >ntention - particularly PDSE latches - are a PITA.
> I
On Mon, 9 Sep 2013 14:28:26 -0700, Tom Ross wrote:
>Never too late! I need to know these answers too. Some of my customers say
>PDSE is not a problem, others are quite concerned, like you.
Hey Tom, Barbara explained the particular issues a ring of monoplexes present.
Seems IBM have disavowed th
>Tom,
>
>Why convert to PDSE? I am curious? A stated IBM direction?
Converting to PDSE just makes it easier to use or move to COBOL V5.1.
PDSE is far better than PDS, lots of advantages, so you could view it
as IBM direction, but for COBOL, that is the only thing we can do.
In COBOL V5.1, we alwa
>Tom,
>
>Could you share the SHARE presentations you have given on COBOL V5?
Yes, thanks for the reminder! One of my TODOs has been to get our Web
people to add my 2 COBOL V5 presentaitons to our resources page.
I just sent them over, they should be live soon at:
http://www-01.ibm.com/support/doc
Tom,
Thank you. I like Frank's idea also
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 10, 2013, at 5:44 PM, Tom Ross wrote:
>> Tom,
>>
>> Why convert to PDSE? I am curious? A stated IBM direction?
>
> Converting to PDSE just makes it easier t
On 9/7/2013 10:22 AM, Tom Ross wrote:
If I am reading this correctly, the BINDER would need to use a PDSE output
file if there is JAVA, C/C++ type of programs. If you have native cobol,
then you might be able to continue the LKED with BINDER to a non PDSE.
No, the COBOL Migration Guide is corr
58 matches
Mail list logo
