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
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.
It also
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 the
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 always
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:
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 tmr...@stlvm20.vnet.ibm.com wrote:
Tom,
Why convert to PDSE? I am curious? A stated IBM direction?
Converting to PDSE
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 the PDSE requirement for COBOL 5.1 executables
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
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 vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013
at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com 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
2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool,
etc
In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013
at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com said:
No, the COBOL Migration Guide is correct, all COBOL programs=20
produce GOFF output with COBOL V5, so after
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 so.
Where Shane and I differ, and I suspect that this difference
In
4ee2851a2279b94cb70cd69b17410609ae9bb...@s1flokydce2kx01.dm0001.info53.com,
on 09/09/2013
at 11:53 AM, Jousma, David david.jou...@53.com 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
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,
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
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
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 1
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
On Mon, Sep 9, 2013 at 12:19 PM, Bob Shannon bshan...@rocketsoftware.comwrote:
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
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
4ee2851a2279b94cb70cd69b17410609ae9bb
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 a
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
From: Tom Ross tmr...@stlvm20.vnet.ibm.com
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 vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013
at 09:22 AM, Tom Ross tmr
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 tmr...@stlvm20.vnet.ibm.com wrote:
In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013
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 a
In 0810432924290538.wa.dbohnaegonusa@listserv.ua.edu, on
09/06/2013
at 08:16 AM, Bohn, Dale db...@aegonusa.com 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
In
4ee2851a2279b94cb70cd69b17410609ae51c...@s1flokydce2kx01.dm0001.info53.com,
on 09/06/2013
at 12:01 PM, Jousma, David david.jou...@53.com 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.
In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013
at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com 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
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
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
.
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 am reading
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
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.
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
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 PDSEs
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 and tools like COBOL 5.1, Fault Analyzer
@LISTSERV.UA.EDUmailto: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
dependencies towards Fault Analyzer, Debug Tool and other
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
@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
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.
With COBOL 5.1, AFAIK, comes also
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/c1473830.pdf
For z/OS V2.1:
http://www-03.ibm.com/systems/z
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.
I'm curious about your
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.
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
(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, Debug
Tool, etc
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
-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
@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 on our z/os 1.12 system now
, 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 the NEXT Version of APA (4Q13
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
[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
Thomas Berg
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
57 matches
Mail list logo
