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
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
>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,
>
>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
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,
> >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
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
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
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
>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
: 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
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
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
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
> 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
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
>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
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
: 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
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
>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
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
> 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
-
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
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
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
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
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 <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
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
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
.
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
>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
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
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.
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
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
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
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
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
-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
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
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)
(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,
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
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
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.
>
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
@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
, 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
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
p 616.653.8429
f 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jousma, David
Sent: Friday, September 06, 2013 7:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer
I'm curious about your statement:
"With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be
PDSE. Which we DON'T have today, neither in production or test systems."
If you mean the product code comes in PDSE's then that's no big deal. But if
you are saying the output of th
> 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
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/os/zos/bkserv/zos_migration_manuals.html
Also, see if and when Marna W
57 matches
Mail list logo
