Re: COBOL V5+

[Larry Slaten]

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 additional information.


On 8/8/2021 7:08 PM, Larry Slaten wrote:
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.  Programmers noticed in CICS testing regions that 
with CEDF ON, when you hit the PROCEDURE DIVISION USING statement you 
execute a CICS GETMAIN for every 01 level in the LINKAGE SECTION.  
First I assumed that this was due to option PARMCHECK.  In the manuals 
it says that PARMCHECK adds a string of hex values at the end of COBOL 
WORKING-STORAGE.  I assumed that it also did the same for each 01 
level in the LINKAGE SECTION, which logically made sense that the 
compiler would acquire another piece of storage to copy the 01 level 
to and append the string of hex values.  So, that when the called 
program exited, COBOL would be testing the trailing storage for the 
string of hex values to determine if the program had stepped on that 
storage, before doing a CICS FREEMAIN.  Well you know what happens 
when you ASSUME?  We went through the list of testing associated 
compile options. Removing them one at a time, compiling, new copying, 
and testing in the CICS region.  With no success, I finally tried 
removing NOTEST(DWARF).  Eureka, no more CICS GETMAINS for each of the 
LINKAGE SECTION 01 levels.  Not what I was expecting.  None of the 
documentation suggested that NOTEST(DWARF) would affect runtime. It 
should only come into play when the program ABENDs.  Has anybody else 
noticed this behavior? This does affect the time for each transaction 
a great deal. Maybe we can get Mr. COBOL "Tom Ross" to shed some light 
on this?




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

COBOL V5+

[Tom Ross]

Larry,

>In the manuals it says that PARMCHECK adds a string of hex values at the
>end of COBOL WORKING-STORAGE.

This is true!

>I assumed that it also did the same for each 01 level in the LINKAGE
>SECTION, which logically made sense that the compiler would acquire another
>piece of storage to copy the 01 level to and append the string of hex
>values.

This is NOT true, PARMCHECK is only checking for a migration problem where the
sub program would overwrite storage following WORKIN-STORAGE.  PARMCHECK is
not for validating all paramter usage.  Parameter misuse in general 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 region.  With no success, I finally tried removing NOTEST(DWARF).
>Eureka, no more CICS GETMAINS for each of the LINKAGE SECTION 01 levels.
>Not what I was expecting.  None of the documentation suggested that
>NOTEST(DWARF) would affect runtime.  It should only come into play when
>into play when the program ABENDs.
>This does affect the time for each transaction a great deal.

I have never heard of this, is seems wrong to me.  Please open a CASE with
IBM service and have us look into this!

I have a question for you, why would you use NOTEST(DWARF) instead of 
TEST(DWARF)?
TEST is very efficient these days, many shops run in production with TEST.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

COBOL V5+

[Larry Slaten]

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.  Programmers noticed in CICS testing regions that with 
CEDF ON, when you hit the PROCEDURE DIVISION USING statement you execute 
a CICS GETMAIN for every 01 level in the LINKAGE SECTION.  First I 
assumed that this was due to option PARMCHECK.  In the manuals it says 
that PARMCHECK adds a string of hex values at the end of COBOL 
WORKING-STORAGE.  I assumed that it also did the same for each 01 level 
in the LINKAGE SECTION, which logically made sense that the compiler 
would acquire another piece of storage to copy the 01 level to and 
append the string of hex values.  So, that when the called program 
exited, COBOL would be testing the trailing storage for the string of 
hex values to determine if the program had stepped on that storage, 
before doing a CICS FREEMAIN.  Well you know what happens when you 
ASSUME?  We went through the list of testing associated compile 
options.  Removing them one at a time, compiling, new copying, and 
testing in the CICS region.  With no success, I finally tried removing 
NOTEST(DWARF).  Eureka, no more CICS GETMAINS for each of the LINKAGE 
SECTION 01 levels.  Not what I was expecting.  None of the documentation 
suggested that NOTEST(DWARF) would affect runtime.  It should only come 
into play when the program ABENDs.  Has anybody else noticed this 
behavior? This does affect the time for each transaction a great deal. 
Maybe we can get Mr. COBOL "Tom Ross" to shed some light on this?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Tom Ross]

>ABO only creates an optimized LOAD MODULE (program object).  It does not=20
>convert your source to V6, and it will not give you all the=20
>optimizations of V6.  Your biggest payback is if you upgrade your CPU,=20
>then you can run your load modules through ABO and get some 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 caused by invalid data in the COBOL data items at
runtime.  To fix this, users have to change the data, or the data entry
panels, or use new compiler options to tolerate the bad data.  There is
no way to do source conversion to migrate to COBOL V5/V6, like there
was years ago for OS/VS COBOL to anything newer.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Gord Tomlin]

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, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Timothy Sipples]

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 improvements in the new compiler that should help
make your system more efficient and more functional.

For the record, IBM has not announced any End of Service (EoS) date for the
Enterprise COBOL Version 4.2 compiler -- or for Versions 5.1, 5.2, and 6.1
(6.1 is the current release as I write this). If you'd like to review
current General Availability (GA) and EoS dates for the Enterprise COBOL
compilers, please visit:

http://www.ibm.com/software/support/lifecycle/index_e.html

and scroll down to the Enterprise COBOL listings. Updates should be posted
there in due course.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Mike Schwab]

If you convert to the new Country Multiplex Pricing, you only pay for
1 version of Cobol despite having multiple versions available for
compiling.

 
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=897=ENUS215-230

On Tue, Aug 30, 2016 at 11:45 AM, Lizette Koehler
<stars...@mindspring.com> wrote:
> So if EOS is announced - the most that means is no new fixes for that version 
> of
> the Compiler.  I do not think the compiler shuts itself down.  You can still 
> use
> it.
>
> Note:  I think IBM has altered the pricing on V3/V4 Enterprise Cobol Compiler 
> to
> be the same as V5 Enterprise Cobol compiler.  I am not sure if there was a 
> cost
> increase from V5 to V6 Enterprise Cobol Compiler.  So if cost is a factor, I
> think that has already been handled by IBM.
>
> Depending on what your requirements are, here are some things to look at for 
> an
> upgrade
> 1)  Do you have a source management tool that needs to be altered for the new
> compiler? (Change Man, Endevor, CA Telon, etc...)
> a) New work would use the new compiler
> b) old work may use the older compiler
> 2)  What are the new Reserve words in the Compiler and are any current 
> programs
> using them?
> 3)  What COBOL options are in place today, and how does the new compiler alter
> that environment
> a) In a previous release PMAP is LIST on the compiler options
> 3)  Are the benefits of the new Compiler worth the effort to upgrade? (Most 
> have
> indicated yes)
> 4)  Do you have very complex Programs that need TLC to upgrade?  These could 
> be
> including, CICS, IMS, MQ, DB2 type of programs
> 5)  How long does your company require for a checkout for the new compiler?
> a) Some shops have mandatory recompile Everything under the new 
> compiler
> b) Some shops have compile the worst case programs as a test case of 
> the
> new compiler
> c) Some shops have performance requirements for a new compiler.  
> Program
> must run the same way or better.  Not worse
> 6)  Will you need to run only new work through the V5/V6 Enterprise Cobol
> compiler while old work gets the current compiler?
> a)  This may be needed as the older programs have to be evaluated and
> that takes time.
> 7)  How long will this process take.  As other have pointed out - the BIG 
> CLOCK
> Starts the minute you being this process.  Work with your IBM Representative 
> on
> actual requirements.
> 8)  Older programs running do not necessarily need to be recompiled.  That is
> why the new Parmlib member was created.  To allow everything to run as is.
> a) When a program gets a fix - then the company should look are the
> recompile with the new compiler.
>
> There may be other considerations.
>
> To upgrade the compiler is easy.  Running parallel processes to ensure
> everything is working the same or better is what takes time.  And what
> application group is not busy and has the time to do the checkouts?  Answer -
> very few.
>
> And because the LOAD lib for the compile MUST be a PDS/E, that has had a new
> level to a simple 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@LISTSERV.UA.EDU
>> Subject: Re: Cobol V5/V6
>>
>> My concern is that IBM will announce EOS for Enterprise Cobol 4.2 and we will
>> not be ready.
>>
>>
>>
>> > -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: 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 was announced Aug 2015. It requires a Z10 or newer processor.
>> > Here is the announcement letter.
>> >
>> > http://www-01.ibm.com/common/ssi/cgi-
>> > bin/ssialias?subtype=ca=an
>> > =iSource=897=ENUS215-267#availx
>> >
>> > or tinyurl
>> >
>> > http://preview.tinyurl.com/p64hluq
>> >
>> > Lizette
>> >
>> >
>> > > -Original Message-
>> > > From: 

Re: Cobol V5/V6

[Lizette Koehler]

So if EOS is announced - the most that means is no new fixes for that version of
the Compiler.  I do not think the compiler shuts itself down.  You can still use
it.

Note:  I think IBM has altered the pricing on V3/V4 Enterprise Cobol Compiler to
be the same as V5 Enterprise Cobol compiler.  I am not sure if there was a cost
increase from V5 to V6 Enterprise Cobol Compiler.  So if cost is a factor, I
think that has already been handled by IBM.

Depending on what your requirements are, here are some things to look at for an
upgrade
1)  Do you have a source management tool that needs to be altered for the new
compiler? (Change Man, Endevor, CA Telon, etc...)
a) New work would use the new compiler
b) old work may use the older compiler
2)  What are the new Reserve words in the Compiler and are any current programs
using them?  
3)  What COBOL options are in place today, and how does the new compiler alter
that environment
a) In a previous release PMAP is LIST on the compiler options 
3)  Are the benefits of the new Compiler worth the effort to upgrade? (Most have
indicated yes)
4)  Do you have very complex Programs that need TLC to upgrade?  These could be
including, CICS, IMS, MQ, DB2 type of programs
5)  How long does your company require for a checkout for the new compiler?
a) Some shops have mandatory recompile Everything under the new compiler
b) Some shops have compile the worst case programs as a test case of the
new compiler
c) Some shops have performance requirements for a new compiler.  Program
must run the same way or better.  Not worse
6)  Will you need to run only new work through the V5/V6 Enterprise Cobol
compiler while old work gets the current compiler?
a)  This may be needed as the older programs have to be evaluated and
that takes time.
7)  How long will this process take.  As other have pointed out - the BIG CLOCK
Starts the minute you being this process.  Work with your IBM Representative on
actual requirements.
8)  Older programs running do not necessarily need to be recompiled.  That is
why the new Parmlib member was created.  To allow everything to run as is.
a) When a program gets a fix - then the company should look are the
recompile with the new compiler.

There may be other considerations.

To upgrade the compiler is easy.  Running parallel processes to ensure
everything is working the same or better is what takes time.  And what
application group is not busy and has the time to do the checkouts?  Answer -
very few.

And because the LOAD lib for the compile MUST be a PDS/E, that has had a new
level to a simple 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@LISTSERV.UA.EDU
> Subject: Re: Cobol V5/V6
> 
> My concern is that IBM will announce EOS for Enterprise Cobol 4.2 and we will
> not be ready.
> 
> 
> 
> > -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: 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 was announced Aug 2015. It requires a Z10 or newer processor.
> > Here is the announcement letter.
> >
> > http://www-01.ibm.com/common/ssi/cgi-
> > bin/ssialias?subtype=ca=an
> > =iSource=897=ENUS215-267#availx
> >
> > or tinyurl
> >
> > http://preview.tinyurl.com/p64hluq
> >
> > Lizette
> >
> >
> > > -Original Message-----
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lopez, Sharon
> > > Sent: Tuesday, August 30, 2016 6:20 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: 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.
> > >

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Feller, Paul]

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 Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, August 30, 2016 11:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol V5/V6

I have no statistical evidence, but my impression is that V5/V6 is not yet in 
widespread use. The biggest obstacle for *some* shops is the requirement that 
output go to PDSE, which cannot reliably be shared across sysplex boundaries. 
If you don't do that, no problem. If you do, then some (perhaps major) changes 
will be required to create and manage multiple application load libraries.



It's now possible to install V5/V6 on a trial basis without starting the 
dreaded Version Clock. Check with your favorite Beemer. OTOH the Version Clock 
has been extended to 18 months from the standard 12. That should help.



Also note that installing V5/V6 does not mean converting all programs from V4-. 
It just means that all new compiles must be V5/V6. In other words, you can no 
longer invoke the V4- compiler. You are not required by Ts to recompile 
everything. Or anything AFAIK. 



.

.

J.O.Skip Robinson

Southern California Edison Company

Electric Dragon Team Paddler 

SHARE MVS Program Co-Manager

323-715-0595 Mobile

626-302-7535 Office

robin...@sce.com





-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul 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 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 was announced Aug 2016. It requires a Z10 or newer processor.  

>Here is the announcement letter.

> 

https://urldefense.proofpoint.com/v2/url?u=http-3A__www-2D01.ibm.com_common_ssi_cgi-2Dbin_ssialias-3Fsubtype-3Dca-26infotype-3Dan-26appname=DQIGaQ=9g4MJkl2VjLjS6R4ei18BA=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc=IVmtpNYZe1PMJTSNolDJTto3jNco-HA949C8V1MYYyA=-I8sgomiJIAI1OgsZjSy4c1qOQASlBvni-aHGlp8z2E=
 

=iSource=897=ENUS215-267#availx

(Repaired UL, I hope)

>

Wherein I read:

Planned availability date

September 30, 2015



An accelerated delivery schedule, indeed.



-- gil





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Jesse 1 Robinson]

I have no statistical evidence, but my impression is that V5/V6 is not yet in 
widespread use. The biggest obstacle for *some* shops is the requirement that 
output go to PDSE, which cannot reliably be shared across sysplex boundaries. 
If you don't do that, no problem. If you do, then some (perhaps major) changes 
will be required to create and manage multiple application load libraries.

It's now possible to install V5/V6 on a trial basis without starting the 
dreaded Version Clock. Check with your favorite Beemer. OTOH the Version Clock 
has been extended to 18 months from the standard 12. That should help.

Also note that installing V5/V6 does not mean converting all programs from V4-. 
It just means that all new compiles must be V5/V6. In other words, you can no 
longer invoke the V4- compiler. You are not required by Ts to recompile 
everything. Or anything AFAIK. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul 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 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 was announced Aug 2016. It requires a Z10 or newer processor.  
>Here is the announcement letter.
> 
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an
=iSource=897=ENUS215-267#availx
(Repaired UL, I hope)
>
Wherein I read:
Planned availability date
September 30, 2015

An accelerated delivery schedule, indeed.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Paul Gilmartin]

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
>use a PDSE dataset prior to a PDS dataset in our Production batch.
>
>z/OS 2.2 was announced Aug 2016. It requires a Z10 or newer processor.  Here is
>the announcement letter.
> 
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an
=iSource=897=ENUS215-267#availx
(Repaired UL, I hope)
>
Wherein I read:
Planned availability date
September 30, 2015

An accelerated delivery schedule, indeed.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Lopez, Sharon]

My concern is that IBM will announce EOS for Enterprise Cobol 4.2 and we will 
not be ready.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, August 30, 2016 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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.EDU
> Subject: 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 was announced Aug 2016. It requires a Z10 or newer processor.
> Here is the announcement letter.
>
> http://www-01.ibm.com/common/ssi/cgi-
> bin/ssialias?subtype=ca=an
> =iSource=897=ENUS215-267#availx
>
> or tinyurl
>
> http://preview.tinyurl.com/p64hluq
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lopez, Sharon
> > Sent: Tuesday, August 30, 2016 6:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 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.
> >
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Lizette Koehler]

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: 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 was announced Aug 2016. It requires a Z10 or newer processor.  Here
> is the announcement letter.
> 
> http://www-01.ibm.com/common/ssi/cgi-
> bin/ssialias?subtype=ca=an
> =iSource=897=ENUS215-267#availx
> 
> or tinyurl
> 
> http://preview.tinyurl.com/p64hluq
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lopez, Sharon
> > Sent: Tuesday, August 30, 2016 6:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 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.
> >
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol V5/V6

[Lizette Koehler]

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 was announced Aug 2016. It requires a Z10 or newer processor.  Here is
the announcement letter.

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an
=iSource=897=ENUS215-267#availx

or tinyurl

http://preview.tinyurl.com/p64hluq

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lopez, Sharon
> Sent: Tuesday, August 30, 2016 6:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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.
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Cobol V5/V6

[Lopez, Sharon]

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 the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Timothy Sipples]

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 to try the Automatic Binary Optimizer
(ABO) to see what impact it has on your Enterprise COBOL Version 3.x and
Version 4.x programs, IBM introduced a cloud-based, zero installation
trial:

https://optimizer.mybluemix.net

You simply upload an existing COBOL module to the ABO Trial Cloud service.
The IBM service runs ABO on your COBOL module, and then you can download
the optimized module for testing and performance measurement on your
system. It's another simple, quick, and easy way to test the Automatic
Binary Optimizer. (On-site Trial Edition licenses for both Enterprise COBOL
Version 6.1 and the Automatic Binary Optimizer are also still available.)

Enjoy.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A couple of interesting COBOL V5 fixes

[Jon Butler]

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 days, is definitely a violation of the intent of 
the rules and you do so at your own risk.  When the compilers are 
changed...well, you asked for it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A couple of interesting COBOL V5 fixes

[Chris Hoelscher]

Unless you take the perspective that "everything that is not illegal is legal" 
- undocumented closing of "loopholes" or making undesirable (but legal) coding 
practices now illegal doesn't seem to necessarily seem to be in the best 
interest o fhte customer ... 

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> 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 "interesting" things to get around
> limitations within the COBOL standard.  While IBM was "right" from some
> perspective to make the changes they did to COBOL, not considering (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 interesting COBOL V5 fixes
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible
> with how V4 works.
> >
> > http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330
> >
> > "In earlier versions of COBOL, customer source frequently handled
> > dynamically sized pieces of storage 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.
> > 01  wrk-len PIC s9(08) binary.
> > LINKAGE SECTION.
> > 01  L-String1   PIC X(1).
> > 01  L-String2   PIC X(1).
> > PROCEDURE DIVISION.
> > -MAIN.
> > MOVE 1000 TO wrk-len
> > MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len)
> >
> > Behavior difference:  COBOL V4 moves 1000 bytes.  COBOL V5 moves 232
> > bytes due to differing instructions.
> >
> > TABLE ODO Example:
> > WORKING-STORAGE SECTION.
> > 01  CONTROLVAR PIC 9(5) BINARY.
> > 01  MYCONTAINER.
> > 02  MYTABLE.
> > 03 TBL OCCURS 0 TO 1 TIMES DEPENDING ON CONTROLVAR.
> >05 MYFIELD PIC X(1).
> > 02 DUMMY PIC X(300).
> > PROCEDURE DIVISION.
> > MOVE 1 TO CONTROLVAR
> > MOVE ALL 'Z' TO DUMMY
> > DISPLAY DUMMY      <= Contains all Z's
> > MOVE 300 TO CONTROLVAR
> > MOVE ALL 'M' TO MYTABLE <= MYTABLE has 1 byte of M's in V4
> > DISPLAY MYTABLE
> > MOVE 1 TO CONTROLVAR
> > DISPLAY DUMMY   <= DUMMY HAS 299 BYTES OF M's in V4.
> >
> > Behavior difference:  COBOL V4 overlays storage following MYTABLE
> > exactly as expected byte for byte.  COBOL V5 handles the overlay
> > differently such that the storage results differ from COBOL V4."
> >
> > And:
> >
> > "Problem conclusion
> >
> > The compiler was updated to ensure that in the above move
> > scenario the runtime length of the move, as implied by the
> > variable length reference modification, is always used
> > regardless of the defined length of the receiving data item in
> > the linkage section."
> >
> > Note, it won't work if compiled with SSRANGE.
> >
> > No "Local Fix" was outlined. The idea is that you no longer have to
> > fix the code :-)
> >
> > Where such techniques are used, it will make migration easier.
> >
> > Secondly, some movement on the NUMPROC(MIG) issue which has
> previously been discussed here.
> >
> > http://www-01.ibm.com/support/docview.wss?uid=swg1PI56073
> >
> > "
> **
> **
> > * USERS AFFECTED: Users of Enterprise COBOL V5.2 migrating *
> > * from a pre-V5 compiler, compiling and*
> > *     running programs that were using the *
> > * NUMPROC(MIG) compiler option in pre-V5.  *
> > *  *
>

Re: A couple of interesting COBOL V5 fixes

[Frank Swarbrick]

Very interesting stuff, Bill.  Thanks for pointing them out!

Just goes to show that some shops did "interesting" things to get around 
limitations within the COBOL standard.  While IBM was "right" from some 
perspective to make the changes they did to COBOL, not considering (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 interesting COBOL V5 fixes
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible 
> with how V4 works.
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330
> 
> "In earlier versions of COBOL, customer source frequently
> handled dynamically sized pieces of storage 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.
> 01  wrk-len PIC s9(08) binary.
> LINKAGE SECTION.
> 01  L-String1   PIC X(1).
> 01  L-String2   PIC X(1).
> PROCEDURE DIVISION.
> -MAIN.
> MOVE 1000 TO wrk-len
> MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len)
> 
> Behavior difference:  COBOL V4 moves 1000 bytes.  COBOL V5
> moves 232 bytes due to differing instructions.
> 
> TABLE ODO Example:
> WORKING-STORAGE SECTION.
> 01  CONTROLVAR PIC 9(5) BINARY.
> 01  MYCONTAINER.
> 02  MYTABLE.
> 03 TBL OCCURS 0 TO 1 TIMES DEPENDING ON CONTROLVAR.
>05 MYFIELD PIC X(1).
> 02 DUMMY PIC X(300).
> PROCEDURE DIVISION.
> MOVE 1 TO CONTROLVAR
> MOVE ALL 'Z' TO DUMMY
> DISPLAY DUMMY  <= Contains all Z's
> MOVE 300 TO CONTROLVAR
> MOVE ALL 'M' TO MYTABLE <= MYTABLE has 1 byte of M's in V4
> DISPLAY MYTABLE
> MOVE 1 TO CONTROLVAR
> DISPLAY DUMMY   <= DUMMY HAS 299 BYTES OF M's in V4.
> 
> Behavior difference:  COBOL V4 overlays storage following
> MYTABLE exactly as expected byte for byte.  COBOL V5 handles
> the overlay differently such that the storage results differ
> from COBOL V4."
> 
> And:
> 
> "Problem conclusion
> 
> The compiler was updated to ensure that in the above move
> scenario the runtime length of the move, as implied by the
> variable length reference modification, is always used
> regardless of the defined length of the receiving data item in
> the linkage section."
> 
> Note, it won't work if compiled with SSRANGE.
> 
> No "Local Fix" was outlined. The idea is that you no longer have to fix the 
> code :-)
> 
> Where such techniques are used, it will make migration easier.
> 
> Secondly, some movement on the NUMPROC(MIG) issue which has previously been 
> discussed here.
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PI56073
> 
> "
> * USERS AFFECTED: Users of Enterprise COBOL V5.2 migrating *
> * from a pre-V5 compiler, compiling and*
> * running programs that were using the *
> * NUMPROC(MIG) compiler option in pre-V5.      *
> *  *
> ****
>     * PROBLEM DESCRIPTION: Performance: Programs compiled with *
> *  NUMPROC(NOPFD) using Enterprise COBOL   *
> *  V5 is slower than programs compiled *
> *  with NUMPROC(MIG) using a pre   *
> *  Enterprise COBOL V5 compiler.   *
> *  *
> 
> * RECOMMENDATION: Apply the provided PTF.  *
> 
> NUMPROC(MIG) does not require sign codes to be cleaned before
> comparing two zoned decimal data items. NUMPROC(NOPFD) requires
> sign codes to be cleaned.
> 
> Problem conclusion
> 
> A more efficient code sequence for cleaning sign codes during
> comparisons was developed."
> 
> So, NUMPROC(MIG) has not returned (and is less likely to), but NUMPROC(NOPFD) 
> has been made faster.
> 
> This is an amusing one:
> 
> http://www-0

A couple of interesting COBOL V5 fixes

[Bill Woodger]

> 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 seemed to be aware of these 
> differences between COBOL v4 and v5 but seemed inclined to see this as the 
> customers problem. I'm glad they fixed this. It would have made the migration 
> to v5 almost impossible for us. It is hard enough without such issues.
> 
> Fred!
> 

Yes, I think that now there is the acceptance of two different types of "bad 
code" from IBM. "bad code" that doesn't work consistently with existing 
compilers, so go sort it out yourself. "bad code" which works consistently with 
the existing compilers, but relies on how the compilers work for things that, 
in the Standard, are down to the implementor. IBM are willing to look at 
getting V5+ to work the same as earlier compilers for the second type of "bad 
code".

Some things, like the new physical location of indexes, immediately after the 
table they are defined on, are going to take longer to sort out, but it's on 
the list of things to do.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A couple of interesting COBOL V5 fixes

[Windt, W.K.F. van der (Fred)]

> Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible
> with how V4 works.
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330
> 
> "In earlier versions of COBOL, customer source frequently handled
> dynamically sized pieces of storage 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.
> 01  wrk-len PIC s9(08) binary.
> LINKAGE SECTION.
> 01  L-String1   PIC X(1).
> 01  L-String2   PIC X(1).
> PROCEDURE DIVISION.
> -MAIN.
> MOVE 1000 TO wrk-len
> MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len)
> 
> Behavior difference:  COBOL V4 moves 1000 bytes.  COBOL V5 moves 232
> bytes due to differing instructions.

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 seemed to be aware of these differences between 
COBOL v4 and v5 but seemed inclined to see this as the customers problem. I'm 
glad they fixed this. It would have made the migration to v5 almost impossible 
for us. It is hard enough without such issues.

Fred!


ATTENTION:
The information in this e-mail is confidential and only meant for the intended 
recipient. If you are not the intended recipient , don't use or disclose it in 
anyway. Please let the sender know and delete the message immediately.
--



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

A couple of interesting COBOL V5 fixes

[Bill Woodger]

Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible with 
how V4 works.

http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330

"In earlier versions of COBOL, customer source frequently
handled dynamically sized pieces of storage 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.
01  wrk-len PIC s9(08) binary.
LINKAGE SECTION.
01  L-String1   PIC X(1).
01  L-String2   PIC X(1).
PROCEDURE DIVISION.
-MAIN.
MOVE 1000 TO wrk-len
MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len)

Behavior difference:  COBOL V4 moves 1000 bytes.  COBOL V5
moves 232 bytes due to differing instructions.

TABLE ODO Example:
WORKING-STORAGE SECTION.
01  CONTROLVAR PIC 9(5) BINARY.
01  MYCONTAINER.
02  MYTABLE.
03 TBL OCCURS 0 TO 1 TIMES DEPENDING ON CONTROLVAR.
   05 MYFIELD PIC X(1).
02 DUMMY PIC X(300).
PROCEDURE DIVISION.
MOVE 1 TO CONTROLVAR
MOVE ALL 'Z' TO DUMMY
DISPLAY DUMMY  <= Contains all Z's
MOVE 300 TO CONTROLVAR
MOVE ALL 'M' TO MYTABLE <= MYTABLE has 1 byte of M's in V4
DISPLAY MYTABLE
MOVE 1 TO CONTROLVAR
DISPLAY DUMMY   <= DUMMY HAS 299 BYTES OF M's in V4.

Behavior difference:  COBOL V4 overlays storage following
MYTABLE exactly as expected byte for byte.  COBOL V5 handles
the overlay differently such that the storage results differ
from COBOL V4."

And:

"Problem conclusion

The compiler was updated to ensure that in the above move
scenario the runtime length of the move, as implied by the
variable length reference modification, is always used
regardless of the defined length of the receiving data item in
the linkage section."

Note, it won't work if compiled with SSRANGE.

No "Local Fix" was outlined. The idea is that you no longer have to fix the 
code :-)

Where such techniques are used, it will make migration easier.

Secondly, some movement on the NUMPROC(MIG) issue which has previously been 
discussed here.

http://www-01.ibm.com/support/docview.wss?uid=swg1PI56073

"
* USERS AFFECTED: Users of Enterprise COBOL V5.2 migrating *
* from a pre-V5 compiler, compiling and*
* running programs that were using the *
* NUMPROC(MIG) compiler option in pre-V5.  *
*  *

* PROBLEM DESCRIPTION: Performance: Programs compiled with *
*      NUMPROC(NOPFD) using Enterprise COBOL   *
*  V5 is slower than programs compiled *
*  with NUMPROC(MIG) using a pre   *
    *  Enterprise COBOL V5 compiler.   *
*  *

* RECOMMENDATION: Apply the provided PTF.  *

NUMPROC(MIG) does not require sign codes to be cleaned before
comparing two zoned decimal data items. NUMPROC(NOPFD) requires
sign codes to be cleaned.

Problem conclusion

A more efficient code sequence for cleaning sign codes during
comparisons was developed."

So, NUMPROC(MIG) has not returned (and is less likely to), but NUMPROC(NOPFD) 
has been made faster.

This is an amusing one:

http://www-01.ibm.com/support/docview.wss?uid=swg1PI59344

ADD 0 TO a-zoned-decimal-field was "optimized out" under the new 
ZONEDATA(NOPFD)/ZONEDATA(MIG). Since this was sefl-defeating (the ADD 0 would 
cause zones, and signs, to be fixed), the ADD 0 will remain.

It is still optimized-out for ZONEDATA(PFD) because "the zone bits are assumed 
to be correct with ZONEDATA(PFD)".

I'm not so sure that last is a good idea, because the ADD 0 also affects the 
sign.  Research needed.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Elardus Engelbrecht]

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 inconsistent copy of RACF db.

>Of course it is still russian rulette, so even if the risk is small (I didn't 
>say that!), it's still worth to use proper tools.

Russian Roulette? ;-)

True. Risks are truly small if you're grown up and very responsible... ;-)


>I'd suggest always use UT200 then UT400 (against the copy) if needed. 

Correct! This is what I do. First UT200, then UT400 (on that copy you said) and 
then perhaps usual DFDSS dump very later.


>Reason: UT200 is easier to use and faster.

Yup! UT400 does some re-org during the copy.

Groete / Greetings
Elardus Engelbrecht!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[R.S.]

Robert,
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 inconsistent copy of 
RACF db.
Of course it is still russian rulette, so even if the risk is small (I 
didn't say that!), it's still worth to use proper tools.
I'd suggest always use UT200 then UT400 (against the copy) if needed. 
Reason: UT200 is easier to use and faster.



Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2016-02-17 o 11:49, Robert S. Hansel (RSH) pisze:

Hi Radoslaw,

It is fine to copy an off line RACF database using the tools you named. For a 
live RACF database, however, by not using IRRUT200, you risk copying the 
database while RACF is in the midst of updating it, in which case the copy may 
have integrity errors. A copy of a live database made using some other tool 
will be fine as long as no updates were being made at that particular point in 
time. IRRUT200 is much safer because it ensures no updates are in progress when 
making its copy. I wouldn't recommend using anything other than IRRUT200 
(preferably) or IRRUT400 for making backups or copies of a live RACF database.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date: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 
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 
proper characteristics. The preferred utility to use to create the backup is 
IRRUT200 which momentarily serializes the database, thereby preventing updates, 
while it copies the database. IRRUT400 can also be used, but it locks the 
database which you then have to unlock. The backup should be allocated as one 
extent, contiguous, and non-movable and, if using IRRUT200, with the exact same 
size as the source.

While I still support to use UT200 to perform copy of RACF db, I have to
admit I did many tests in the past when I intentionally used RACF db
done by ICEGENER, IEBGENER or ADRDSSU DUMP. With no "luck", that mean I
never got inconsistent result. At least none of RACF utilities detected
the inconsistency. In other words even such copy was usable.
Of course I still recommend to use proper tool for that.

BTW: all my tests were done against monoplex configurations.
BTW2: the tests had some reason behind, it wasn't just "hey, let's put
egg to microwave owen and see". ;-)






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Robert S. Hansel (RSH)]

Hi Radoslaw,

It is fine to copy an off line RACF database using the tools you named. For a 
live RACF database, however, by not using IRRUT200, you risk copying the 
database while RACF is in the midst of updating it, in which case the copy may 
have integrity errors. A copy of a live database made using some other tool 
will be fine as long as no updates were being made at that particular point in 
time. IRRUT200 is much safer because it ensures no updates are in progress when 
making its copy. I wouldn't recommend using anything other than IRRUT200 
(preferably) or IRRUT400 for making backups or copies of a live RACF database.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date: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 
> 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 proper characteristics. The preferred utility to use to create the backup 
> is IRRUT200 which momentarily serializes the database, thereby preventing 
> updates, while it copies the database. IRRUT400 can also be used, but it 
> locks the database which you then have to unlock. The backup should be 
> allocated as one extent, contiguous, and non-movable and, if using IRRUT200, 
> with the exact same size as the source.

While I still support to use UT200 to perform copy of RACF db, I have to 
admit I did many tests in the past when I intentionally used RACF db 
done by ICEGENER, IEBGENER or ADRDSSU DUMP. With no "luck", that mean I 
never got inconsistent result. At least none of RACF utilities detected 
the inconsistency. In other words even such copy was usable.
Of course I still recommend to use proper tool for that.

BTW: all my tests were done against monoplex configurations.
BTW2: the tests had some reason behind, it wasn't just "hey, let's put 
egg to microwave owen and see". ;-)


-- 
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[R.S.]

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 
proper characteristics. The preferred utility to use to create the backup is 
IRRUT200 which momentarily serializes the database, thereby preventing updates, 
while it copies the database. IRRUT400 can also be used, but it locks the 
database which you then have to unlock. The backup should be allocated as one 
extent, contiguous, and non-movable and, if using IRRUT200, with the exact same 
size as the source.


While I still support to use UT200 to perform copy of RACF db, I have to 
admit I did many tests in the past when I intentionally used RACF db 
done by ICEGENER, IEBGENER or ADRDSSU DUMP. With no "luck", that mean I 
never got inconsistent result. At least none of RACF utilities detected 
the inconsistency. In other words even such copy was usable.

Of course I still recommend to use proper tool for that.

BTW: all my tests were done against monoplex configurations.
BTW2: the tests had some reason behind, it wasn't just "hey, let's put 
egg to microwave owen and see". ;-)



--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Itschak Mugzach]

Did you oonsider responding with an automation tool and save your fingers?
this is a well defined case where automation can help...

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Mon, Feb 15, 2016 at 10:30 PM, Joe Aulph <syspro...@gmail.com> wrote:

> In previous and current assignments I have, in test, destroyed a DB and
> attempted an IPL, after 45 minutes of bleeding-finger console responses we
> gave up and IPL'd off a good DB.
> We have forced the DB offline, fail soft testing, and after 50-70 console
> responses were able to get 1 TSO user logged on via UADS.
> Then there was the day I cam into the office and my DB was GONE! Only
> because I had a recent backup on an available volume, and a handy IBM tech
> (thank you Russ) we had no real outage and lost only 4 hours of password
> updates.
> All  of which underscores the point, you want a dozen different options
> before you are forced to use UADS, and an on-line available copy of the DB
> is a life saver.
>
> Cheers,
> Joe
>
> On Mon, Feb 15, 2016 at 9:09 AM, John Eells <ee...@us.ibm.com> wrote:
>
> > I would not want to run with such an MPF exit or AUTORxx member active in
> > production.  You can have it there for emergencies and activate it with a
> > SET command.  This keeps the pain level of failsoft mode a lot more
> > tolerable.  We used to have a couple of such exits waiting in the wings
> for
> > recovery to automate operator approvals during system recovery, though at
> > this point I can't recall specifically for what other messages they
> > automated the responses.
> >
> > I absolutely agree with those who express a preference for a one-pack
> > recovery system, by the way.  But I'm a belt-and-suspenders kind of guy
> and
> > would still want one more last-ditch recovery option.
> >
> >
> > Skip Robinson wrote:
> >
> >> This problem occurs so seldom that I never thought of automating a
> >> response. As of R12 or so, we now have AUTORxx, which can reply to WTORs
> >> very early in the IPL. Not sure who here would have to approve such a
> >> change. The chances of mischief being perpetrated are minimal, but it
> does
> >> open a very small window for a clever miscreant.
> >>
> >> .
> >> .
> >> .
> >> J.O.Skip Robinson
> >> Southern California Edison Company
> >> Electric Dragon Team Paddler
> >> SHARE MVS 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, 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) 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 for a tiny
> >>>> handful like JES that bypass integrity. By the time you get to the
> >>>> point of actually logging on to TSO, operator's fingers will be
> >>>> bleeding profusely. If at any time during this process, you are
> >>>> god-forbid required to start over, yet more finger tips will have to
> >>>> sacrificed.
> >>>>
> >>>
> >>> We solved this with an MPF exit that would always reply 'Y' to each of
> >>> those
> >>> prompts (except for the first few IIRC).
> >>>
> >> 
> >
> > --
> > John Eells
> > IBM Poughkeepsie
> > ee...@us.ibm.com
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Joe Aulph]

In previous and current assignments I have, in test, destroyed a DB and
attempted an IPL, after 45 minutes of bleeding-finger console responses we
gave up and IPL'd off a good DB.
We have forced the DB offline, fail soft testing, and after 50-70 console
responses were able to get 1 TSO user logged on via UADS.
Then there was the day I cam into the office and my DB was GONE! Only
because I had a recent backup on an available volume, and a handy IBM tech
(thank you Russ) we had no real outage and lost only 4 hours of password
updates.
All  of which underscores the point, you want a dozen different options
before you are forced to use UADS, and an on-line available copy of the DB
is a life saver.

Cheers,
Joe

On Mon, Feb 15, 2016 at 9:09 AM, John Eells <ee...@us.ibm.com> wrote:

> I would not want to run with such an MPF exit or AUTORxx member active in
> production.  You can have it there for emergencies and activate it with a
> SET command.  This keeps the pain level of failsoft mode a lot more
> tolerable.  We used to have a couple of such exits waiting in the wings for
> recovery to automate operator approvals during system recovery, though at
> this point I can't recall specifically for what other messages they
> automated the responses.
>
> I absolutely agree with those who express a preference for a one-pack
> recovery system, by the way.  But I'm a belt-and-suspenders kind of guy and
> would still want one more last-ditch recovery option.
>
>
> Skip Robinson wrote:
>
>> This problem occurs so seldom that I never thought of automating a
>> response. As of R12 or so, we now have AUTORxx, which can reply to WTORs
>> very early in the IPL. Not sure who here would have to approve such a
>> change. The chances of mischief being perpetrated are minimal, but it does
>> open a very small window for a clever miscreant.
>>
>> .
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS 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, 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) 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 for a tiny
>>>> handful like JES that bypass integrity. By the time you get to the
>>>> point of actually logging on to TSO, operator's fingers will be
>>>> bleeding profusely. If at any time during this process, you are
>>>> god-forbid required to start over, yet more finger tips will have to
>>>> sacrificed.
>>>>
>>>
>>> We solved this with an MPF exit that would always reply 'Y' to each of
>>> those
>>> prompts (except for the first few IIRC).
>>>
>> 
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[John Eells]

I would not want to run with such an MPF exit or AUTORxx member active 
in production.  You can have it there for emergencies and activate it 
with a SET command.  This keeps the pain level of failsoft mode a lot 
more tolerable.  We used to have a couple of such exits waiting in the 
wings for recovery to automate operator approvals during system 
recovery, though at this point I can't recall specifically for what 
other messages they automated the responses.


I absolutely agree with those who express a preference for a one-pack 
recovery system, by the way.  But I'm a belt-and-suspenders kind of guy 
and would still want one more last-ditch recovery option.


Skip Robinson wrote:

This problem occurs so seldom that I never thought of automating a response. As 
of R12 or so, we now have AUTORxx, which can reply to WTORs very early in the 
IPL. Not sure who here would have to approve such a change. The chances of 
mischief being perpetrated are minimal, but it does open a very small window 
for a clever miscreant.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS 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, 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) 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 for a tiny
handful like JES that bypass integrity. By the time you get to the
point of actually logging on to TSO, operator's fingers will be
bleeding profusely. If at any time during this process, you are
god-forbid required to start over, yet more finger tips will have to sacrificed.


We solved this with an MPF exit that would always reply 'Y' to each of those
prompts (except for the first few IIRC).



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Deepthi S]

...
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 good use of UADS is for recovery,
> including DR. It's the only way to log on when you have no security
> database, at least when RACF is the absent DB in question. I'd want to have
> "some number" of sysprog user IDs to be in UADS for recovery purposes. (And
> an appropriate MPF exit, for RACF!)
>
> As SA restore is a serial activity and batch restore is not, minimizing
> recovery time would seem to call for a small number of UADS-defined IDs to
> speed overall restore time if your security DB happens not to share a
> volume with some other data sets required to IPL and log on. But what do I
> know?
>
> 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 UADS, a simple list command tells the story. With
>> TSOE
>> segment, it's a data mining operation. This difference alone has inhibited
>> conversion in some shops.
>>
> 
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Deepthi S]

..
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 good use of UADS is for recovery,
> including DR. It's the only way to log on when you have no security
> database, at least when RACF is the absent DB in question. I'd want to have
> "some number" of sysprog user IDs to be in UADS for recovery purposes. (And
> an appropriate MPF exit, for RACF!)
>
> As SA restore is a serial activity and batch restore is not, minimizing
> recovery time would seem to call for a small number of UADS-defined IDs to
> speed overall restore time if your security DB happens not to share a
> volume with some other data sets required to IPL and log on. But what do I
> know?
>
> 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 UADS, a simple list command tells the story. With
>> TSOE
>> segment, it's a data mining operation. This difference alone has inhibited
>> conversion in some shops.
>>
> 
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Robert S. Hansel (RSH)]

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 
proper characteristics. The preferred utility to use to create the backup is 
IRRUT200 which momentarily serializes the database, thereby preventing updates, 
while it copies the database. IRRUT400 can also be used, but it locks the 
database which you then have to unlock. The backup should be allocated as one 
extent, contiguous, and non-movable and, if using IRRUT200, with the exact same 
size as the source.

As determine by one of our RACF surveys and as found in our numerous RACF 
reviews, many organizations are not using RACF utilities to back up their 
databases and risk having a corrupted backup. If you are interested, the survey 
"RACF Database Backup" can be found on the RACF Center webpage of our website 
at the following URL. For those unfamiliar with our website, you'll find lots 
of other useful RACF information there as well.

http://www.rshconsulting.com/racfres.htm

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training
- RACF Audit & Compliance Roadmap - APR 11-15, 2016
- RACF Level I Administration - MAY 17-20, 2016
- RACF Level II Administration -MAY 3-5, 2016
- RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016
- Securing z/OS UNIX  - WebEx - JUL 25-29, 2016


-Original Message-
Date:Sun, 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 be restored.  I would
contend that is easier, and possibly safer, to do this from a fully
functional "one-drive" tech support emergency z/OS system accessing
production drives than to do it from a UADS-defined TSO user on a
crippled production system without RACF or with a known-damaged database
-- and there are so many other unanticipated problems such an emergency
system can address that it doesn't make sense to be without one. 

If the only problem that can be solved by having a UADS-defined TSO user
can be better addressed by a "must have" alternative, why persist with
any UADS-defined TSO users once the alternative is available?
Joel C. Ewing

On 02/14/2016 01:04 PM, Skip Robinson wrote:
> This problem occurs so seldom that I never thought of automating a response. 
> As of R12 or so, we now have AUTORxx, which can reply to WTORs very early in 
> the IPL. Not sure who here would have to approve such a change. The chances 
> of mischief being perpetrated are minimal, but it does open a very small 
> window for a clever miscreant. 
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS 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, 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) 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 for a tiny
>>> handful like JES that bypass integrity. By the time you get to the
>>> point of actually logging on to TSO, operator's fingers will be
>>> bleeding profusely. If at any time during this process, you are
>>> god-forbid required to start over, yet more finger tips will have to 
>>> sacrificed.
>> We solved this with an MPF exit that would always reply 'Y' to each of those
>> prompts (except for the first few IIRC).
>>
>> --
>> Edward E Jaffe
>> Phoenix Software International, Inc
>> 831 Parkview Drive North
>> El Segundo, CA 90245
>> http://www.phoenixsoftware.com/


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Walt Farrell]

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 achieved via RACF?

It is _controlled_ by RACF, but is allowed by TSO/E only for those users who 
have TSO segments in the RACF database, as I recall. Or users allowed by some 
TSO/E exit.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Ed Jaffe]

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, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Joel C. Ewing]

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
contend that is easier, and possibly safer, to do this from a fully
functional "one-drive" tech support emergency z/OS system accessing
production drives than to do it from a UADS-defined TSO user on a
crippled production system without RACF or with a known-damaged database
-- and there are so many other unanticipated problems such an emergency
system can address that it doesn't make sense to be without one. 

If the only problem that can be solved by having a UADS-defined TSO user
can be better addressed by a "must have" alternative, why persist with
any UADS-defined TSO users once the alternative is available?
Joel C. Ewing

On 02/14/2016 01:04 PM, Skip Robinson wrote:
> This problem occurs so seldom that I never thought of automating a response. 
> As of R12 or so, we now have AUTORxx, which can reply to WTORs very early in 
> the IPL. Not sure who here would have to approve such a change. The chances 
> of mischief being perpetrated are minimal, but it does open a very small 
> window for a clever miscreant. 
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS 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, 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) 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 for a tiny
>>> handful like JES that bypass integrity. By the time you get to the
>>> point of actually logging on to TSO, operator's fingers will be
>>> bleeding profusely. If at any time during this process, you are
>>> god-forbid required to start over, yet more finger tips will have to 
>>> sacrificed.
>> We solved this with an MPF exit that would always reply 'Y' to each of those
>> prompts (except for the first few IIRC).
>>
>> --
>> Edward E Jaffe
>> Phoenix Software International, Inc
>> 831 Parkview Drive North
>> El Segundo, CA 90245
>> http://www.phoenixsoftware.com/


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Skip Robinson]

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. I remember a post (I think from Shmuel) some time ago about 
flipping a bit in the ACEE just before invoking CONSOLE in a Rexx. I prefer 
TSOE segment for the handful of folks who need such functionality. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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 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 RACF database is to have a fairly recent
> backup copy of the RACF data base that can be restored.  I would contend that
> is easier, and possibly safer, to do this from a fully functional "one-drive" 
> tech
> support emergency z/OS system accessing production drives than to do it from
> a UADS-defined TSO user on a crippled production system without RACF or
> with a known-damaged database
> -- and there are so many other unanticipated problems such an emergency
> system can address that it doesn't make sense to be without one.
> 
> If the only problem that can be solved by having a UADS-defined TSO user can
> be better addressed by a "must have" alternative, why persist with any UADS-
> defined TSO users once the alternative is available?
> Joel C. Ewing
> 
> On 02/14/2016 01:04 PM, Skip Robinson wrote:
> > This problem occurs so seldom that I never thought of automating a
> response. As of R12 or so, we now have AUTORxx, which can reply to WTORs
> very early in the IPL. Not sure who here would have to approve such a change.
> The chances of mischief being perpetrated are minimal, but it does open a
> very small window for a clever miscreant.
> >
> > .
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > jo.skip.robin...@att.net
> >
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@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) 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 for a tiny
> >>> handful like JES that bypass integrity. By the time you get to the
> >>> point of actually logging on to TSO, operator's fingers will be
> >>> bleeding profusely. If at any time during this process, you are
> >>> god-forbid required to start over, yet more finger tips will have to
> sacrificed.
> >> We solved this with an MPF exit that would always reply 'Y' to each
> >> of those prompts (except for the first few IIRC).
> >>
> >> --
> >> Edward E Jaffe
> >> Phoenix Software International, Inc
> >> 831 Parkview Drive North
> >> El Segundo, CA 90245
> >> http://www.phoenixsoftware.com/
> 
> 
> --
> Joel C. Ewing,Bentonville, AR   jcew...@acm.org
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Skip Robinson]

This problem occurs so seldom that I never thought of automating a response. As 
of R12 or so, we now have AUTORxx, which can reply to WTORs very early in the 
IPL. Not sure who here would have to approve such a change. The chances of 
mischief being perpetrated are minimal, but it does open a very small window 
for a clever miscreant. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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, 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) 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 for a tiny
> > handful like JES that bypass integrity. By the time you get to the
> > point of actually logging on to TSO, operator's fingers will be
> > bleeding profusely. If at any time during this process, you are
> > god-forbid required to start over, yet more finger tips will have to 
> > sacrificed.
> 
> We solved this with an MPF exit that would always reply 'Y' to each of those
> prompts (except for the first few IIRC).
> 
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Ed Jaffe]

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 for a tiny handful like JES that bypass
integrity. By the time you get to the point of actually logging on to TSO,
operator's fingers will be bleeding profusely. If at any time during this
process, you are god-forbid required to start over, yet more finger tips
will have to sacrificed.


We solved this with an MPF exit that would always reply 'Y' to each of 
those prompts (except for the first few IIRC).


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Ed Gould]

Skip:

I concur. A second cousin war story was that there was a RACF  
"screwup" (ie operator error) took a data center down for a long time  
(more than a few hours). The DC was designed for the one of the  
Chicago markets. The lead sysprog at the time (I thing he is no  
longer with us) was there at the time.
We had a separate DC on the same floor and I think the blood letting  
was felt by everyone.
If memory serves me we had just converted to MVS and went ACF2. I  
don't think the question ever arose in our DC about what IF, but we  
sure should have.

Ed
On Feb 13, 2016, at 10: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 for a tiny handful like JES that bypass
integrity. By the time you get to the point of actually logging on  
to TSO,
operator's fingers will be bleeding profusely. If at any time  
during this
process, you are god-forbid required to start over, yet more finger  
tips

will have to sacrificed.

Whatever UADS is worth, IPLing without a RACF data base is the last  
extreme

recovery option. Please plan a next-to-last option.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS 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 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.

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 only way to log on when you have no security  
database, at

least
when RACF is the absent DB in question. I'd want to have "some  
number" of
sysprog user IDs to be in UADS for recovery purposes. (And an  
appropriate

MPF exit, for RACF!)

As SA restore is a serial activity and batch restore is not,  
minimizing

recovery
time would seem to call for a small number of UADS-defined IDs to  
speed
overall restore time if your security DB happens not to share a  
volume

with

some other data sets required to IPL and log on. But what do I know?

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 UADS, a simple list command tells
the story. With TSOE segment, it's a data mining operation. This
difference alone has inhibited conversion in some shops.



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

- 
-
For IBM-MAIN subscribe / signoff / archive access instructions,  
send email

to

lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Skip Robinson]

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 for a tiny handful like JES that bypass
integrity. By the time you get to the point of actually logging on to TSO,
operator's fingers will be bleeding profusely. If at any time during this
process, you are god-forbid required to start over, yet more finger tips
will have to sacrificed. 

Whatever UADS is worth, IPLing without a RACF data base is the last extreme
recovery option. Please plan a next-to-last option.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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 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.
> 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 only way to log on when you have no security database, at
least
> when RACF is the absent DB in question. I'd want to have "some number" of
> sysprog user IDs to be in UADS for recovery purposes. (And an appropriate
> MPF exit, for RACF!)
> 
> As SA restore is a serial activity and batch restore is not, minimizing
recovery
> time would seem to call for a small number of UADS-defined IDs to speed
> overall restore time if your security DB happens not to share a volume
with
> some other data sets required to IPL and log on. But what do I know?
> 
> 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 UADS, a simple list command tells
> > the story. With TSOE segment, it's a data mining operation. This
> > difference alone has inhibited conversion in some shops.
> 
> 
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Ed Gould]

Skip:

I agree to an extent. The overhead in maintaining charge back #'s was  
just to great (for us) and we just accepted the number on the job/tso/ 
stc and in the end we found some people cheating and wrote memo's to  
their boss and manually made the adjustment (that did work BTW as the  
managers were dinged at review for infractions like this.


Ed
On Feb 2, 2016, at 11:14 AM, Skip Robinson wrote:

At the late great Security Pacific Bank, much care and effort were  
taken for chargeback to business units. This resulted in actual  
bills (internal funny money of course) based on system usage. A  
fairly elaborate account number schema supported this activity.  
Account numbers were tied to projects and were strictly controlled.  
A user had to be permitted to use a particular account number.  
Accounting/chargeback was done for batch via job card and online  
via TSO account number. It was imperative for admins to track all  
of this. Listing a TSO userid would show what account numbers/ 
projects the user was set up for.


I'm not sure all this overhead was worth the cost, but it was the  
law of that land.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS 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 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 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,

but even them didn't know what is the rationale behind.

Regarding reports: TSO information in RACF is not 1:1 from UADS,  
so some

reports cannot be simply converted. However this is side effect of
enhancements. For example there is difference between logon  
procedure "in
use" and allowed. The same apply to acctnum. User may have a  
choice of

many procedures and many (any) acctnums.


Regarding recovery: I would strongly recommend to use "one pack z/ 
OS" or

any other form of tech system, another LPAR. That's waay more
convenient than failsoft processing with UADS.

Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2016-02-01 o 22:50, Skip Robinson pisze:
For the record, my comments on UADS vs. TSO segment have nothing  
to do
with DR. We mirror all DASD from production to recovery site, so  
everything in
production is available in DR. My point about querying a TSO  
segment is this:
when defining a userid with TSO segment, only the first of  
multiple proclibs or
account numbers are stored in the TSO segment itself. Any others  
are defined
in classes TSOPROC or ACCTNUM. While all proclibs and account  
numbers are
displayed via the ACCOUNT LIST command, with TSO segment you have  
to do

multiple queries.


In a previous shop, developers had multiple account numbers in  
order to
track their work by project. Not so much here, but many folks have  
multiple
proclibs for various purposes. Just last week I had to use my  
'dataset free'
emergency proc in order to logon in the face of an unavailable  
dataset. I

happen to have a TSO segment myself because I need CONSOLE (TSOAUTH),
but only a few sysprogs have that requirement.


As for 'conversion' to TSO segment, we have a long-established  
security

management tool consisting of programs--many in COBOL!--that allow a
handful of security admins to manage hundreds of users and  
thousands of
datasets across a dozen LPARs. This tool is complex and  
installation-specific in
a way that only in-house developed software can be. There's a  
fenced-off
section in the local boot hill reserved for tombstones with  
inscriptions like this:


'Here lies Tony the Axe. Hired to kill off the security tool.  
Long live the tool.'


.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-

m...@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

RACF.

An RFE couldn't hurt if you find them lacking.

I don't think there is any problem with the display  
capabilities. Actually, you

use a RACF command or utility (RACF panels for example) to ask RACF
questions about the fields you're interested in.


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 only wa

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[R.S.]

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, 
but even them didn't know what is the rationale behind.


Regarding reports: TSO information in RACF is not 1:1 from UADS, so some 
reports cannot be simply converted. However this is side effect of 
enhancements. For example there is difference between logon procedure 
"in use" and allowed. The same apply to acctnum. User may have a choice 
of many procedures and many (any) acctnums.



Regarding recovery: I would strongly recommend to use "one pack z/OS" or 
any other form of tech system, another LPAR. That's waay more 
convenient than failsoft processing with UADS.


Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2016-02-01 o 22:50, Skip Robinson pisze:

For the record, my comments on UADS vs. TSO segment have nothing to do with DR. 
We mirror all DASD from production to recovery site, so everything in 
production is available in DR. My point about querying a TSO segment is this: 
when defining a userid with TSO segment, only the first of multiple proclibs or 
account numbers are stored in the TSO segment itself. Any others are defined in 
classes TSOPROC or ACCTNUM. While all proclibs and account numbers are 
displayed via the ACCOUNT LIST command, with TSO segment you have to do 
multiple queries.

In a previous shop, developers had multiple account numbers in order to track 
their work by project. Not so much here, but many folks have multiple proclibs 
for various purposes. Just last week I had to use my 'dataset free' emergency 
proc in order to logon in the face of an unavailable dataset. I happen to have 
a TSO segment myself because I need CONSOLE (TSOAUTH), but only a few sysprogs 
have that requirement.

As for 'conversion' to TSO segment, we have a long-established security 
management tool consisting of programs--many in COBOL!--that allow a handful of 
security admins to manage hundreds of users and thousands of datasets across a 
dozen LPARs. This tool is complex and installation-specific in a way that only 
in-house developed software can be. There's a fenced-off section in the local 
boot hill reserved for tombstones with inscriptions like this:

'Here lies Tony the Axe. Hired to kill off the security tool. Long live the 
tool.'

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS 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 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 them lacking.

I don't think there is any problem with the display capabilities. Actually, you
use a RACF command or utility (RACF panels for example) to ask RACF
questions about the fields you're interested in.



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 only way to log on when you have no security
database, at least when RACF is the absent DB in question. I'd want to
have "some number" of sysprog user IDs to be in UADS for recovery
purposes. (And an appropriate MPF exit, for RACF!)

Very true in all aspects.



As SA restore is a serial activity and batch restore is not, minimizing recovery

time would seem to call for a small number of UADS-defined IDs to speed
overall restore time if your security DB happens not to share a volume with
some other data sets required to IPL and log on. But what do I know?

Agreed. Just have a small UADS and test that out by RVARY inactive both your
RACF DBs. Preferably on a sandbox. ;-)

If you setup your RACF properly, you should have no trouble recovering it. Just
have your primary and backup RACF DB on separate volsers, make daily
backup with IRRUT200, do your DRP several times in a year, unload your RACF
DB using IRRDBU00, optionally run DBSYNC to generate commands to recreate
your RACF DB, etc.

I repeat - Just keep your RACF DBs on separate volsers, not on a IPL volser.


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.

That is for fallback purposes. These days it is probably very seldom used.

But you should have documented your UADS+Proclibs and what ids are there
somewhere available during a DRP.



With UADS, a simple list command tells the stor

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Ed Gould]

We use them for resource usage (not for charge back) but it could be  
done as well if we could ever agree on it.


Ed

On Feb 2, 2016, at 4:27 AM, R.S. wrote:


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, but even them didn't know what is the rationale  
behind.


Regarding reports: TSO information in RACF is not 1:1 from UADS, so  
some reports cannot be simply converted. However this is side  
effect of enhancements. For example there is difference between  
logon procedure "in use" and allowed. The same apply to acctnum.  
User may have a choice of many procedures and many (any) acctnums.



Regarding recovery: I would strongly recommend to use "one pack z/ 
OS" or any other form of tech system, another LPAR. That's waay  
more convenient than failsoft processing with UADS.


Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2016-02-01 o 22:50, Skip Robinson pisze:
For the record, my comments on UADS vs. TSO segment have nothing  
to do with DR. We mirror all DASD from production to recovery  
site, so everything in production is available in DR. My point  
about querying a TSO segment is this: when defining a userid with  
TSO segment, only the first of multiple proclibs or account  
numbers are stored in the TSO segment itself. Any others are  
defined in classes TSOPROC or ACCTNUM. While all proclibs and  
account numbers are displayed via the ACCOUNT LIST command, with  
TSO segment you have to do multiple queries.


In a previous shop, developers had multiple account numbers in  
order to track their work by project. Not so much here, but many  
folks have multiple proclibs for various purposes. Just last week  
I had to use my 'dataset free' emergency proc in order to logon in  
the face of an unavailable dataset. I happen to have a TSO segment  
myself because I need CONSOLE (TSOAUTH), but only a few sysprogs  
have that requirement.


As for 'conversion' to TSO segment, we have a long-established  
security management tool consisting of programs--many in COBOL!-- 
that allow a handful of security admins to manage hundreds of  
users and thousands of datasets across a dozen LPARs. This tool is  
complex and installation-specific in a way that only in-house  
developed software can be. There's a fenced-off section in the  
local boot hill reserved for tombstones with inscriptions like this:


'Here lies Tony the Axe. Hired to kill off the security tool. Long  
live the tool.'


.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@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 RACF.

An RFE couldn't hurt if you find them lacking.

I don't think there is any problem with the display capabilities.  
Actually, you

use a RACF command or utility (RACF panels for example) to ask RACF
questions about the fields you're interested in.


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 only way to log on when you have no security
database, at least when RACF is the absent DB in question. I'd  
want to

have "some number" of sysprog user IDs to be in UADS for recovery
purposes. (And an appropriate MPF exit, for RACF!)

Very true in all aspects.


As SA restore is a serial activity and batch restore is not,  
minimizing recovery
time would seem to call for a small number of UADS-defined IDs to  
speed
overall restore time if your security DB happens not to share a  
volume with

some other data sets required to IPL and log on. But what do I know?

Agreed. Just have a small UADS and test that out by RVARY  
inactive both your

RACF DBs. Preferably on a sandbox. ;-)

If you setup your RACF properly, you should have no trouble  
recovering it. Just

have your primary and backup RACF DB on separate volsers, make daily
backup with IRRUT200, do your DRP several times in a year, unload  
your RACF
DB using IRRDBU00, optionally run DBSYNC to generate commands to  
recreate

your RACF DB, etc.

I repeat - Just keep your RACF DBs on separate volsers, not on a  
IPL volser.



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 (was Re: [Bulk] Re: COBOL v5)

[Skip Robinson]

At the late great Security Pacific Bank, much care and effort were taken for 
chargeback to business units. This resulted in actual bills (internal funny 
money of course) based on system usage. A fairly elaborate account number 
schema supported this activity. Account numbers were tied to projects and were 
strictly controlled. A user had to be permitted to use a particular account 
number. Accounting/chargeback was done for batch via job card and online via 
TSO account number. It was imperative for admins to track all of this. Listing 
a TSO userid would show what account numbers/projects the user was set up for.

I'm not sure all this overhead was worth the cost, but it was the law of that 
land.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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 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 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,
> but even them didn't know what is the rationale behind.
> 
> Regarding reports: TSO information in RACF is not 1:1 from UADS, so some
> reports cannot be simply converted. However this is side effect of
> enhancements. For example there is difference between logon procedure "in
> use" and allowed. The same apply to acctnum. User may have a choice of
> many procedures and many (any) acctnums.
> 
> 
> Regarding recovery: I would strongly recommend to use "one pack z/OS" or
> any other form of tech system, another LPAR. That's waay more
> convenient than failsoft processing with UADS.
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> W dniu 2016-02-01 o 22:50, Skip Robinson pisze:
> > For the record, my comments on UADS vs. TSO segment have nothing to do
> with DR. We mirror all DASD from production to recovery site, so everything in
> production is available in DR. My point about querying a TSO segment is this:
> when defining a userid with TSO segment, only the first of multiple proclibs 
> or
> account numbers are stored in the TSO segment itself. Any others are defined
> in classes TSOPROC or ACCTNUM. While all proclibs and account numbers are
> displayed via the ACCOUNT LIST command, with TSO segment you have to do
> multiple queries.
> >
> > In a previous shop, developers had multiple account numbers in order to
> track their work by project. Not so much here, but many folks have multiple
> proclibs for various purposes. Just last week I had to use my 'dataset free'
> emergency proc in order to logon in the face of an unavailable dataset. I
> happen to have a TSO segment myself because I need CONSOLE (TSOAUTH),
> but only a few sysprogs have that requirement.
> >
> > As for 'conversion' to TSO segment, we have a long-established security
> management tool consisting of programs--many in COBOL!--that allow a
> handful of security admins to manage hundreds of users and thousands of
> datasets across a dozen LPARs. This tool is complex and installation-specific 
> in
> a way that only in-house developed software can be. There's a fenced-off
> section in the local boot hill reserved for tombstones with inscriptions like 
> this:
> >
> > 'Here lies Tony the Axe. Hired to kill off the security tool. Long live the 
> > tool.'
> >
> > .
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > jo.skip.robin...@att.net
> >
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@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
> RACF.
> >> An RFE couldn't hurt if you find them lacking.
> >>
> >> I don't think there is any problem with the display capabilities. 
> >> Actually, you
> >> use a RACF command or utility (RACF panels for example) to ask RACF
>

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Skip Robinson]

For the record, my comments on UADS vs. TSO segment have nothing to do with DR. 
We mirror all DASD from production to recovery site, so everything in 
production is available in DR. My point about querying a TSO segment is this: 
when defining a userid with TSO segment, only the first of multiple proclibs or 
account numbers are stored in the TSO segment itself. Any others are defined in 
classes TSOPROC or ACCTNUM. While all proclibs and account numbers are 
displayed via the ACCOUNT LIST command, with TSO segment you have to do 
multiple queries.

In a previous shop, developers had multiple account numbers in order to track 
their work by project. Not so much here, but many folks have multiple proclibs 
for various purposes. Just last week I had to use my 'dataset free' emergency 
proc in order to logon in the face of an unavailable dataset. I happen to have 
a TSO segment myself because I need CONSOLE (TSOAUTH), but only a few sysprogs 
have that requirement. 

As for 'conversion' to TSO segment, we have a long-established security 
management tool consisting of programs--many in COBOL!--that allow a handful of 
security admins to manage hundreds of users and thousands of datasets across a 
dozen LPARs. This tool is complex and installation-specific in a way that only 
in-house developed software can be. There's a fenced-off section in the local 
boot hill reserved for tombstones with inscriptions like this: 

'Here lies Tony the Axe. Hired to kill off the security tool. Long live the 
tool.' 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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 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 them lacking.
> 
> I don't think there is any problem with the display capabilities. Actually, 
> you
> use a RACF command or utility (RACF panels for example) to ask RACF
> questions about the fields you're interested in.
> 
> 
> >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 only way to log on when you have no security
> >database, at least when RACF is the absent DB in question. I'd want to
> >have "some number" of sysprog user IDs to be in UADS for recovery
> >purposes. (And an appropriate MPF exit, for RACF!)
> 
> Very true in all aspects.
> 
> 
> >As SA restore is a serial activity and batch restore is not, minimizing 
> >recovery
> time would seem to call for a small number of UADS-defined IDs to speed
> overall restore time if your security DB happens not to share a volume with
> some other data sets required to IPL and log on. But what do I know?
> 
> Agreed. Just have a small UADS and test that out by RVARY inactive both your
> RACF DBs. Preferably on a sandbox. ;-)
> 
> If you setup your RACF properly, you should have no trouble recovering it. 
> Just
> have your primary and backup RACF DB on separate volsers, make daily
> backup with IRRUT200, do your DRP several times in a year, unload your RACF
> DB using IRRDBU00, optionally run DBSYNC to generate commands to recreate
> your RACF DB, etc.
> 
> I repeat - Just keep your RACF DBs on separate volsers, not on a IPL volser.
> 
> 
> 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.
> 
> That is for fallback purposes. These days it is probably very seldom used.
> 
> But you should have documented your UADS+Proclibs and what ids are there
> somewhere available during a DRP.
> 
> 
> >With UADS, a simple list command tells the story.
> 
> Yup, using ACCOUNT utility. There are CBT utilities available to help you with
> that.
> 
> 
> >With TSOE segment, it's a data mining operation.
> 
> No. It is 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 missed something, but I did not fully followed the origina

UADS (was Re: [Bulk] Re: COBOL v5)

[John Eells]

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 only way to log on when you have no security 
database, at least when RACF is the absent DB in question. I'd want to 
have "some number" of sysprog user IDs to be in UADS for recovery 
purposes. (And an appropriate MPF exit, for RACF!)


As SA restore is a serial activity and batch restore is not, minimizing 
recovery time would seem to call for a small number of UADS-defined IDs 
to speed overall restore time if your security DB happens not to share a 
volume with some other data sets required to IPL and log on. But what do 
I know?


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 UADS, a simple list command tells the story. With TSOE
segment, it's a data mining operation. This difference alone has inhibited
conversion in some shops.



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Elardus Engelbrecht]

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 display capabilities. Actually, you 
use a RACF command or utility (RACF panels for example) to ask RACF questions 
about the fields you're interested in.


>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 only way to log on when you have no security database, at least 
>when RACF is the absent DB in question. I'd want to have "some number" of 
>sysprog user IDs to be in UADS for recovery purposes. (And an appropriate MPF 
>exit, for RACF!)

Very true in all aspects.


>As SA restore is a serial activity and batch restore is not, minimizing 
>recovery time would seem to call for a small number of UADS-defined IDs to 
>speed overall restore time if your security DB happens not to share a volume 
>with some other data sets required to IPL and log on. But what do I know?

Agreed. Just have a small UADS and test that out by RVARY inactive both your 
RACF DBs. Preferably on a sandbox. ;-)

If you setup your RACF properly, you should have no trouble recovering it. Just 
have your primary and backup RACF DB on separate volsers, make daily backup 
with IRRUT200, do your DRP several times in a year, unload your RACF DB using 
IRRDBU00, optionally run DBSYNC to generate commands to recreate your RACF DB, 
etc.

I repeat - Just keep your RACF DBs on separate volsers, not on a IPL volser.


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. 

That is for fallback purposes. These days it is probably very seldom used.

But you should have documented your UADS+Proclibs and what ids are there 
somewhere available during a DRP.


>With UADS, a simple list command tells the story. 

Yup, using ACCOUNT utility. There are CBT utilities available to help you with 
that.


>With TSOE segment, it's a data mining operation. 

No. It is 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 missed something, but I did not fully followed the original COBOL v5 
thread and all these spawned threads.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UADS (was Re: [Bulk] Re: COBOL v5)

[Joel C. Ewing]

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 of UADS is for
> recovery, including DR. It's the only way to log on when you have no
> security database, at least when RACF is the absent DB in question.
> I'd want to have "some number" of sysprog user IDs to be in UADS for
> recovery purposes. (And an appropriate MPF exit, for RACF!)
>
> As SA restore is a serial activity and batch restore is not,
> minimizing recovery time would seem to call for a small number of
> UADS-defined IDs to speed overall restore time if your security DB
> happens not to share a volume with some other data sets required to
> IPL and log on. But what do I know?
>
> 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 UADS, a simple list command tells the story.
>> With TSOE
>> segment, it's a data mining operation. This difference alone has
>> inhibited
>> conversion in some shops.
> 
>
We kept one SysProg RACF Admin userid defined via UADS for years, just
in case.  Never needed it to resolve RACF failure. We actually did lose
the RACF database once (an error on our part) , but by that time we had
a one-drive MVS system always available, and it made much more sense to
use that to restore/rebuild the RACF database.  At that point it became
clear that having a one-drive system available for recovery made
worrying about having a TSO user defined in UADS redundant.

The structure of RACF is such that there is no efficient way in general
to display all users/groups permitted to use a specific TSO ACCT# or TSO
logon PROC, because permits are recorded with individual user and group
profiles and all user and group profiles would have to be examined to
determine the answer.  But if installation standards have a group naming
convention for a permit-group associated with each specific Acct# and a
permit-group associated with each specific TSO Logon Proc, and only
those permit-groups are granted permits, and TSO users are only granted
permission via connects to those standard groups, then it becomes
trivial to list all permitted users to an acct or proc by just examining
the connected users for the associated permit-group profile; and to
deduce all accts/procs a specific user has by examining the group
connects of the user for groups with the special acct/proc permit-group
names.  So while RACF does not provide direct support for easily
displaying this information in real time, it is possible for an
installation to use RACF in ways which make it easy to deduce that
information by other means.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[John Eells]

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 automatically transformed all ISAM
I/O operations to VSAM and returned data to the application as it expected.
Absolutely no changes to the application. The result was breath taking.

I'd be curious to know if that conversion aid is still delivered with z/OS.


Still there.  It's documented in Appendix E., Using ISAM Programs with 
VSAM Data Sets, in the Using Data Sets book.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: COBOL v5

[R.S.]

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 dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: COBOL v5

[Skip Robinson]

I think we're on the same page here, though maybe front and back. Security
administration is complicated, but it should be doable by 'admin types'. You
should not need a sysprog for day-to-day security. One of my biggest
objections to typical non-z/OS architecture is the requirement for fully
trained and authorized 'sysadmins' to manage security definitions that are
not just mundane--a business problem of squandering resources--but totally
outside the appropriate limits of system build and support. Security admins
should report up to a manager at the corporate level outside of IT. The way
to accomplish this goal is not to certify security admins in the intricacies
of RACF (with or without UADS), but to provide tools that simplify the
process of managing user and (particularly) data entities. It should be the
admin's job to verify that a certain user is allowed to access a particular
system with permission to some resources but not to others. The tools should
enable the admin to implement that access without knowing RACF or UADS
keywords. If she knows that much, then make her a sysprog and hire another
admin. 

If a shop has properly implemented this sort of management structure, then
security tools are absolutely crucial to the wellbeing of security
administration. This makes migrating to a new security product or
variation--e.g. TSOE segment--problematic because the tools have to
completely rewritten before the first production user can be migrated. This
is not easy or cheap for older, larger shops. Nor can it be done on the sly
without hoopla. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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 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 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 UADS, a simple list command tells
> > the story.
> > With TSOE
> > segment, it's a data mining operation. This difference alone has
> > inhibited conversion in some shops.
> 
> Skip:
> 
> I disagree with your "defensibility technically" statement.
> we have at least two groups that do the RACF definitions and while they
are so
> so technically they cannot seem to do the job correctly and add to the
> measure adding alias's in the mastercats cannot be trusted to do so
reliably. I
> don't know how many times I have rewritten(multiple times)  rexx and clist
> and JCL they simply screw it up sometimes.
> I had to rein in the catastrophe that they managed to do.
> The UADS is simply far more easy to do than the RACF definition(s).
> They regularly screw that up as well and I have had to redo both. Is this
a
> technical issue (a little) is it a personnel issue yes , but
without firing
> people there is no easy solution. I get a JR sysprog to do any TSO adds
(or
> changes) to UADS and it gets done correctly all the time (although
admittedly
> the change can be tricky at times)
> 
> Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: COBOL v5

[R.S.]

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 have never understood the purpose of account numbers 
nowadays.


Benefits of move to UADS? Very little *now*.
But in general it is really good idea to migrate from old solutions 
before IBM announce Enf Of Life for them. Time pressure or upgrade 
stopper is really pain in the a...



Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2016-01-30 o 18:11, Skip Robinson pisze:

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 UADS, a simple list command tells the story. With TSOE
segment, it's a data mining operation. This difference alone has inhibited
conversion in some shops.

Consider a bigger problem. A shop has been in business for decades. In-house
RYO tools have been developed over the years to enable clerical security
personnel to manage addition, modification, and deletion of userids. All
based on UADS. IBM certainly supports the conversion process, but switching
to TSOE segment would require rewriting all of these in-house tools from the
ground up. Benefit? 'Modernization'. For the vast majority of users, there
is no perceivable difference. Who will fund this change and why? The
business units (clients) who must pony up the funds will not see any
demonstrable benefits. A tough sell. So UADS lives on.

I don't believe that native ISAM is even supported anymore. Back then the
ISAM application I referred to was economical to run because it was old, did
what was needed, and best of all did not require any updating. IIP allowed a
few *external* changes to deliver a major performance boost. An easy
business case to sell.

As I said earlier, I'm not arguing against moving forward with COBOL. Just
seeking some forbearance towards shops that see issues on the horizon.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: COBOL v5

[Skip Robinson]

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 UADS, a simple list command tells the story. With TSOE
segment, it's a data mining operation. This difference alone has inhibited
conversion in some shops. 

Consider a bigger problem. A shop has been in business for decades. In-house
RYO tools have been developed over the years to enable clerical security
personnel to manage addition, modification, and deletion of userids. All
based on UADS. IBM certainly supports the conversion process, but switching
to TSOE segment would require rewriting all of these in-house tools from the
ground up. Benefit? 'Modernization'. For the vast majority of users, there
is no perceivable difference. Who will fund this change and why? The
business units (clients) who must pony up the funds will not see any
demonstrable benefits. A tough sell. So UADS lives on.

I don't believe that native ISAM is even supported anymore. Back then the
ISAM application I referred to was economical to run because it was old, did
what was needed, and best of all did not require any updating. IIP allowed a
few *external* changes to deliver a major performance boost. An easy
business case to sell.

As I said earlier, I'm not arguing against moving forward with COBOL. Just
seeking some forbearance towards shops that see issues on the horizon. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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 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 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
> > automatically transformed all ISAM I/O operations to VSAM and returned
> data to the application as it expected.
> > Absolutely no changes to the application. The result was breath taking.
> >
> > I'd be curious to know if that conversion aid is still delivered with
z/OS.
> >
> It's called IIP - ISAM Interface Program.
> It is designed to use VSAM datasets with ISAM applications. Another reason
to
> not understand people who insisted to use ISAM (which was the case even
> after 2000).
> 
> BTW: Similar example (in human behavior) could be TSO segment. Some
> people still use SYS1.UADS for that, while migration can be done with one
> command, IBM-prepared REXX script. I believe there are no advantages of
> using UADS, despite it is still supported.
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Bulk] Re: COBOL v5

[Ed Gould]

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 UADS, a simple list command tells the story.  
With TSOE
segment, it's a data mining operation. This difference alone has  
inhibited

conversion in some shops.


Skip:

I disagree with your "defensibility technically" statement.
we have at least two groups that do the RACF definitions and while  
they are so so technically they cannot seem to do the job correctly  
and add to the measure adding alias's in the mastercats cannot be  
trusted to do so reliably. I don't know how many times I have  
rewritten(multiple times)  rexx and clist and JCL they simply screw  
it up sometimes.

I had to rein in the catastrophe that they managed to do.
The UADS is simply far more easy to do than the RACF definition(s).  
They regularly screw that up as well and I have had to redo both. Is  
this a technical issue (a little) is it a personnel issue  
yes , but without firing people there is no easy solution. I  
get a JR sysprog to do any TSO adds (or changes) to UADS and it gets  
done correctly all the time (although admittedly the change can be  
tricky at times)


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UADS vs TSO Segment [was: COBOL v5]

[Joel C. Ewing]

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 authorized to use might
>> tell a
>> different story. With UADS, a simple list command tells the story.
>> With TSOE
>> segment, it's a data mining operation. This difference alone has
>> inhibited
>> conversion in some shops.
>
> Skip:
>
> I disagree with your "defensibility technically" statement.
> we have at least two groups that do the RACF definitions and while
> they are so so technically they cannot seem to do the job correctly
> and add to the measure adding alias's in the mastercats cannot be
> trusted to do so reliably. I don't know how many times I have
> rewritten(multiple times)  rexx and clist and JCL they simply screw it
> up sometimes.
> I had to rein in the catastrophe that they managed to do.
> The UADS is simply far more easy to do than the RACF definition(s).
> They regularly screw that up as well and I have had to redo both. Is
> this a technical issue (a little) is it a personnel issue yes
> , but without firing people there is no easy solution. I get a
> JR sysprog to do any TSO adds (or changes) to UADS and it gets done
> correctly all the time (although admittedly the change can be tricky
> at times)
>
> Ed
>
> ...
>
We migrated to MVS (and RACF) from DOS/VSE around 1985 and had the
advantage of not having to deal with pre-existing MVS application data
set names or pre-existing security conventions (since DOS/VSE
essentially had no security at the time).  I spent several months coming
up with ways based on our existing application and production batch and
end-user group relationships to implement standards for MVS data set
names, TSO PROC and account standards, and a RACF hierarchical group
structure that allowed all the "usual" permissions to be granted via
generic profiles to groups and connects to RACF groups. 

It quickly became apparent (before MVS went into production) that the
only  way to prevent inconsistencies in user and application area setup
was to automate the daily creation/deletion of users and occasional
creation/deletion of application areas, so that all the standard RACF
group relationships, connects, catalog aliases, etc would be setup at
the same time to essentially eliminate the possibility of omitting a
step or accidentally violating installation conventions.  This was
initially done with CLISTs, later converted to REXX EXECs when that
option became available.  Only the Technical Support RACF Administrators
supporting the Corporate RACF Security Administrators had a need for
detailed knowledge of the underlying RACF structures and installation
conventions.

When UADS could be replaced by RACF TSO segments, it was only a matter
of reworking the EXECs used by the day-to-day Corporate RACF
administrators for routine user maintenance and a mass conversion to TSO
Segments, not a matter of retraining, because those individuals had
never used the TSO ACCOUNT command directly.  When TSO  account number
and PROC authorizations to users are consistently done by RACF group
connects, then RACF can also easily list those authorized to a specific
account or logon PROC by listing connects to a related RACF group, which
eliminates one of the mentioned issues with switching from UADS to RACF
TSO Segments.  Frankly I always found the syntax of the UADS ACCOUNT
command to be very ugly by comparison to RACF command syntax and was
glad to eliminate the need for its use.

My perspective is colored by working in an environment where any change
to RACF group structures, or allowed high-level DS qualifiers, or access
to non-application data sets were strictly under Technical Services
control, either directly or indirectly via EXECs written by Tech
Services for use by Corporate RACF Administrators, and the detailed 
procedures to be followed by Corporate RACF Administrators was also
written by Technical Services RACF support.  Based on our experience, I
find it difficult to conceive of how one could set up installation
conventions for security, TSO or otherwise, and expect to consistently
follow those conventions without the aid of installation-developed tools
like our EXECs -- there are just too many separate interrelated actions
involved  with common tasks like user creation to expect a person to do
them repeatedly and reliably by hand.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Modern vs Legacy [was: RE: COBOL v5]

[Mike Wawiorko]

Hear! Hear! 

I was thinking of a similar Friday rant but Peter's said it all.

Grow up and move on with the times. 

Nearly always we can look back in 5 years' time at the improvements such things 
have brought and wonder what all the fuss was about. An no, I don't want a list 
of 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?  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 order 
and process from high to low.  That was many times faster than inserting in 
ascending key order due to the way ISAM updated its index records.

I also remember hating VSAM files because they had to be cataloged in "VSAM 
Catalogs".  Imagine that nonsense, do they think I don't already know where I 
put my files?  Why, they are right there on my dedicated removable 3330-II 
packs!  Everyone knows that!  Besides, what's wrong with the OS catalog we 
already have?  Now I have to have a separate "VSAM" catalog too?  Harrumph!  
And what is this idiot IDCAMS utility I have to use now?  Isn't JCL good enough 
for them either?  Double Harrumph!

But anyway Radoslaw is right, it seems there are some who would prefer no 
change at all.  I tend to be in the "modern" group myself.

Peter

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Modern vs Legacy [was: RE: COBOL v5]

[R.S.]

​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 of current features.
Obsolete usually means lack of thinking about progress, new versions, 
IBM's directions.


For "n-1" I decide "feature XYZ is still to fresh and we can live 
without it"
For "obsolete" IBM decides instead of me by removing my obsolete 
options. I had to get rid off 3174-attached consoles, because of ESCON 
discontinuance. It was simple, because I was prepared fot that. However 
I'm aware of horror stories cause by lack of 3380 emulation, VSAM 
passwords removal, etc.


Now we have constraint from IBM to start using PDSE for production 
libraries. PDSE'e are 20+ years old and in fact users have many years to 
preparation (time between COBOL 5.2 announcement and COBOL 4.x end of 
support).


BTW: I've been using PDSE for production libraries for 17 years. I have 
never allowed to share production datasets cross sysplex.


My €0,02

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Tony Thigpen]

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 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 into an old-fashioned load module" are potentially inconsistent
requirements.


Well, IMHO there are two kinds of mainframe customers:

a) Legacy
We don't want PDSE, We don't want binder. We don't want SMS. We still
want VSAM passwords. We don't want VSAM. ISAM was good. We don't want
FICON. We want ESCON ...for BUS connectivity. We want 3274...

b) modern
We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be
multi-volume. We want JCL modifications. Etc.

The problem is satisfying b) means troubles for a) group.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Modern vs Legacy [was: RE: COBOL v5]

[John McKown]

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 order and process from high to low.  That was many times faster
> than inserting in ascending key order due to the way ISAM updated its index
> records.
>
> I also remember hating VSAM files because they had to be cataloged in
> "VSAM Catalogs".  Imagine that nonsense, do they think I don't already know
> where I put my files?  Why, they are right there on my dedicated removable
> 3330-II packs!  Everyone knows that!  Besides, what's wrong with the OS
> catalog we already have?  Now I have to have a separate "VSAM" catalog
> too?  Harrumph!  And what is this idiot IDCAMS utility I have to use now?
> Isn't JCL good enough for them either?  Double Harrumph!
>

​I will rant about my "favorite" in the original VSAM: suballocating
clusters. No VTOC entry, other than for the VSAMDSET(?) which would then
contain _all_ the data for clusters on the volume inside of it. And where
the data actually was within that "space" (the "extent" information) was in
the VSAM catalog (IIRC).​ Oh, and a single volume could only be "owned" by
one single VSAM catalog. So, at least for me, that meant one volume was
dedicated to a single HLQ.



>
> But anyway Radoslaw is right, it seems there are some who would prefer no
> change at all.  I tend to be in the "modern" group myself.
>

​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.​ That may be why I don't hate PDSEs like some
here do. I didn't get on board early. Perhaps because I remember installing
DFEF when it first came out. Curiously, this does not stop me from being
"bleeding edge" on my Fedora Linux system at home.



>
> Peter
>
>
-- 
Werner Heisenberg is driving down the autobahn. A police officer pulls
him over. The officer says, "Excuse me, sir, do you know how fast you
were going?"
"No," replies Dr. Heisenberg, "but I know where I am."

Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

He's about as useful as a wax frying pan.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Paul Gillis]

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,
backwards and the job ran in less than 30 minutes, he understood ISAM
inserts really well. He was one of my colleagues that pointed me toward
systems programming.

Cheers,
Paul Gillis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Savor, Thomas (Alpharetta)
Sent: Friday, 29 January 2016 10:18 AM
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 an Update in Place (not file in/ file
out)ugghh  !

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 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 into an old-fashioned load module" are potentially 
> inconsistent requirements.
>
Well, IMHO there are two kinds of mainframe customers:

a) Legacy
We don't want PDSE, We don't want binder. We don't want SMS. We still want
VSAM passwords. We don't want VSAM. ISAM was good. We don't want FICON. We
want ESCON ...for BUS connectivity. We want 3274...

b) modern
We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be
multi-volume. We want JCL modifications. Etc.

The problem is satisfying b) means troubles for a) group.


--
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 dostpu osób trzecich. Jeeli nie jeste
adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej
przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie,
rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie
zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo,
prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale
usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub
zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If
you are not the intended addressee of this e-mail or the employee authorized
to forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved
to hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII
Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców
KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2016 r.
kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696
zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Skip Robinson]

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 automatically transformed all ISAM
I/O operations to VSAM and returned data to the application as it expected.
Absolutely no changes to the application. The result was breath taking. 

I'd be curious to know if that conversion aid is still delivered with z/OS. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS 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 Paul Gillis
> Sent: Friday, January 29, 2016 12:02 AM
> To: IBM-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,
> backwards and the job ran in less than 30 minutes, he understood ISAM
inserts
> really well. He was one of my colleagues that pointed me toward systems
> programming.
> 
> Cheers,
> Paul Gillis
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Savor, Thomas (Alpharetta)
> Sent: Friday, 29 January 2016 10:18 AM
> 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 an Update in Place (not file in/ file
out)ugghh
> !
> 
> 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 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 into an old-fashioned load module" are potentially
> > inconsistent requirements.
> >
> Well, IMHO there are two kinds of mainframe customers:
> 
> a) Legacy
> We don't want PDSE, We don't want binder. We don't want SMS. We still want
> VSAM passwords. We don't want VSAM. ISAM was good. We don't want
> FICON. We want ESCON ...for BUS connectivity. We want 3274...
> 
> b) modern
> We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to
> be multi-volume. We want JCL modifications. Etc.
> 
> The problem is satisfying b) means troubles for a) group.
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[R.S.]

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 to them. The system automatically transformed all ISAM
I/O operations to VSAM and returned data to the application as it expected.
Absolutely no changes to the application. The result was breath taking.

I'd be curious to know if that conversion aid is still delivered with z/OS.


It's called IIP - ISAM Interface Program.
It is designed to use VSAM datasets with ISAM applications. Another 
reason to not understand people who insisted to use ISAM (which was the 
case even after 2000).


BTW: Similar example (in human behavior) could be TSO segment. Some 
people still use SYS1.UADS for that, while migration can be done with 
one command, IBM-prepared REXX script. I believe there are no advantages 
of using UADS, despite it is still supported.



--
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 dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Tom Marchant]

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 application to them. The system automatically transformed all ISAM
>I/O operations to VSAM and returned data to the application as it expected.
>Absolutely no changes to the application. The result was breath taking.
>
>I'd be curious to know if that conversion aid is still delivered with z/OS.

There are still plenty of references to "ISAM compatibility interface" and 
"ISAM interface" in the z/OS 2.2 manuals.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Binder (was: COBOL v5)

[Tony Harminc]

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 Editor resolved the problem.
> Customer's vendor's tech support diagnosed it as unexpected (mis-)alignment
> of TXT records in the load modules.

I've been trying to think what non-IBM software on non-IBM hardware
uses load modules produced by the IBM Binder. No luck so far...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Barry Lichtenstein]

Sorry if I've confused the matter. What I meant was that only a very few 
important and relatively simple changes to the definition of OBJ objects and 
load module programs are made (nothing that would require new constructs).  
AMODE 64 is an example of one of those.  Other than those, new capabilities are 
implemented only in GOFF and Program Objects.

On Wed, 27 Jan 2016 13:40:38 -0600, Ed Gould wrote:

> On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote:
> 
> > It's not the JCL per-se.  The combination of XOBJ object modules  
> > and the Prelinker was a tactical solution to advancements in  
> > programs, originally created for C programs.  XOBJ object modules  
> > addressed several deficiencies in OBJ object modules, such the  
> > ability to have long case-sensitive 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 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 enhancements to OBJ  
> > object module and load module formats.  Some important things have  
> > been added such as AMODE 64 and quad-word alignment.
> >
> > barry_lichtenst...@us.ibm.com
> 
> Since COBOL does not and will not in the foreseeable future need  
> amode 64 I find the argument un helpful.
> 
> Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Barry Lichtenstein]

Hi Bill,  

Point taken.  But my point was that if your JCL uses a PDS rather than a PDSE, 
in some cases you'll get the binder error "IEW2606S 4B39 MODULE INCORPORATES 
VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT BE SAVED IN LOAD MODULE FORMAT."  
As the PL/I procs do (the ones with "P" in their names), invoking the Prelinker 
can allow a subset of programs to be transformed into a linkage-editor 
compatible format.  It only works when the compiler produces XOBJ object 
modules, not with GOFF.

Simply, you can always make SYSLMOD be a PDSE, but you cannot always make it be 
a PDS -- even with the Prelinker.

barry_lichtenst...@us.ibm.com

On Wed, 27 Jan 2016 18:08:11 -0600, Bill Woodger wrote:

> On Wednesday, 27 January 2016 17:26:04 UTC, Barry Lichtenstein  wrote:
> > It's not the JCL per-se.  The combination of XOBJ object modules and the 
> > Prelinker was a tactical solution to advancements in programs, originally 
> > created for C programs.  XOBJ object modules addressed several deficiencies 
> > in OBJ object modules, such the ability to have long case-sensitive 
> > 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 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 enhancements to OBJ object module and 
> > load module formats.  Some important things have been added such as AMODE 
> > 64 and quad-word alignment.
> > 
> > barry_lichtenst...@us.ibm.com
> > 
> 
> Sorry, I was still being unclear. What I meant is that if you run JCL which 
> uses a PDSE as output for executable programs, then you are using a PDSE. If 
> you run JCL that uses a PDS, then you are using a PDS. Using a PDSE in the 
> JCL to compile a PL/I program does not mean that PL/I can only produce code 
> requiring Program Objects, which was that little side-track in the discussion.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Binder (was: COBOL v5)

[Mike Schwab]

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 believe, where a customer
>> using non-IBM software on non-IBM hardware found load modules produced
>>  by Binder failing.  Regressing to Linkage Editor resolved the problem.
>> Customer's vendor's tech support diagnosed it as unexpected (mis-)alignment
>> of TXT records in the load modules.
>
> I've been trying to think what non-IBM software on non-IBM hardware
> uses load modules produced by the IBM Binder. No luck so far...
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

COBOL v5

[Bill Woodger]

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Binder (was: COBOL v5)

[Greg Shirey]

Hmm, the page displays a "Supper-scale Mainframe System" and a "Large-scale 
Mainframe System."   

If someone asked me if I'd rather have supper or large, I guess my answer would 
depend on how hungry I was 
 
Regards,
Greg Shirey
Ben E. Keith Company 


-Original 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/servers/mainframe/globalserver/



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Charles Mills]

True.

And worse, some (most?) people are partially in each camp. They (we all?)
are Legacy on some issues and Modern on others.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Thursday, January 28, 2016 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.
>
> You can't make an omelet without breaking eggs. "Add new features" and 
> "make it go into an old-fashioned load module" are potentially 
> inconsistent requirements.
>
Well, IMHO there are two kinds of mainframe customers:

a) Legacy
We don't want PDSE, We don't want binder. We don't want SMS. We still want
VSAM passwords. We don't want VSAM. ISAM was good. We don't want FICON. We
want ESCON ...for BUS connectivity. We want 3274...

b) modern
We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be
multi-volume. We want JCL modifications. Etc.

The problem is satisfying b) means troubles for a) group.


--
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 dostpu osób trzecich. Jeeli nie jeste
adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej
przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie,
rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie
zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo,
prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale
usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub
zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If
you are not the intended addressee of this e-mail or the employee authorized
to forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved
to hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Stevet]

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 find the argument un helpful.
> 
> Ed
> --
> 
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[R.S.]

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 into an old-fashioned load module" are potentially inconsistent
requirements.


Well, IMHO there are two kinds of mainframe customers:

a) Legacy
We don't want PDSE, We don't want binder. We don't want SMS. We still 
want VSAM passwords. We don't want VSAM. ISAM was good. We don't want 
FICON. We want ESCON ...for BUS connectivity. We want 3274...


b) modern
We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be 
multi-volume. We want JCL modifications. Etc.


The problem is satisfying b) means troubles for a) group.


--
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 dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Savor, Thomas (Alpharetta)]

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 in/ file out)ugghh 
 !

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 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 into an old-fashioned load module" are potentially 
> inconsistent requirements.
>
Well, IMHO there are two kinds of mainframe customers:

a) Legacy
We don't want PDSE, We don't want binder. We don't want SMS. We still want VSAM 
passwords. We don't want VSAM. ISAM was good. We don't want FICON. We want 
ESCON ...for BUS connectivity. We want 3274...

b) modern
We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be 
multi-volume. We want JCL modifications. Etc.

The problem is satisfying b) means troubles for a) group.


--
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 dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Gibney, David Allen,Jr]

I like the new stuff. I'd use it if I needed it, it was helpful, and I had 
hardware capable.

But, we do share our application loadlib between monoplex LPARs. It is 
read-only from all but the development Lpar.
It's not impossible to revise our change control split off a copy to 
production, but I have many things Ineed to do of a higher priority.

And it's probably moot, we haven't even moved to a 4 level of COBOL :(

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, January 28, 2016 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.
>
> You can't make an omelet without breaking eggs. "Add new features" and 
> "make it go into an old-fashioned load module" are potentially 
> inconsistent requirements.
>
Well, IMHO there are two kinds of mainframe customers:

a) Legacy
We don't want PDSE, We don't want binder. We don't want SMS. We still want VSAM 
passwords. We don't want VSAM. ISAM was good. We don't want FICON. We want 
ESCON ...for BUS connectivity. We want 3274...

b) modern
We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be 
multi-volume. We want JCL modifications. Etc.

The problem is satisfying b) means troubles for a) group.


--
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 dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Binder (was: COBOL v5)

[Paul Gilmartin]

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 to my
manager and we agree that supplying more information than I
already posted might compromise customer confidentiality.

Thanks again,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Ed Gould]

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 "make

it go into an old-fashioned load module" are potentially inconsistent
requirements.

Charles--SNIP--


They had managed to so for 30+ years... and quite successfully I  
might add.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Modern vs Legacy [was: RE: COBOL v5]

[Farley, Peter x23353]

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 order 
and process from high to low.  That was many times faster than inserting in 
ascending key order due to the way ISAM updated its index records.

I also remember hating VSAM files because they had to be cataloged in "VSAM 
Catalogs".  Imagine that nonsense, do they think I don't already know where I 
put my files?  Why, they are right there on my dedicated removable 3330-II 
packs!  Everyone knows that!  Besides, what's wrong with the OS catalog we 
already have?  Now I have to have a separate "VSAM" catalog too?  Harrumph!  
And what is this idiot IDCAMS utility I have to use now?  Isn't JCL good enough 
for them either?  Double Harrumph!

But anyway Radoslaw is right, it seems there are some who would prefer no 
change at all.  I tend to be in the "modern" group myself.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Savor, Thomas (Alpharetta)
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 have ISAM job that did an Update in Place (not file in/ file out)ugghh 
 !

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 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 into an old-fashioned load module" are potentially 
> inconsistent requirements.
>
Well, IMHO there are two kinds of mainframe customers:

a) Legacy
We don't want PDSE, We don't want binder. We don't want SMS. We still want VSAM 
passwords. We don't want VSAM. ISAM was good. We don't want FICON. We want 
ESCON ...for BUS connectivity. We want 3274...

b) modern
We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be 
multi-volume. We want JCL modifications. Etc.

The problem is satisfying b) means troubles for a) group.


--
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 dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This message and any attachments are intended only for the use of the addressee 
and may

Re: COBOL v5

[Ed Gould]

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-Main.

Ed



Since COBOL does not and will not in the foreseeable future need
amode 64 I find the argument un helpful.

Ed
--

This message and any attachments are intended only for the use of  
the addressee and may contain information that is privileged and  
confidential. If the reader of the message is not the intended  
recipient or an authorized representative of the intended  
recipient, you are hereby notified that any dissemination of this  
communication is strictly prohibited. If you have received this  
communication in error, please notify us immediately by e-mail and  
delete the message and any attachments from your system.


- 
-

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM- 
MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Binder (was: COBOL v5)

[Yong Yin]

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Charles Mills]

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 into an old-fashioned 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. BUT as we have heard many times IBM doesn't see a need for
this and have relegated COBOL to the dust bin of history. We have had
discussions on here about the need but until there is critical mass IBM will
not consider this as a "need".
Then IBM will probably come up with a half cocked idea like mandating
PDSE's.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

PDSE was Re: COBOL v5

[Clark Morris]

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 kinds of
>qualms.
>
>-- Many seasoned folks still do not trust PDSE. When I entered this biz
>(late 70s) many folks did not trust VSAM. There was an amusing ditty that
>circulated in what then passed for email about file types. "If it's ..." The
>last item went something like: "If it's ... and ... and ... but it doesn't
>work, it's VSAM". Today there are few open APARs against traditional PDS.
>Can the same be said for PDSE?

I know that I am in a minority when I say that IBM should be
transitioning to FBA for z/OS.  This would mean that all FBA file
types: KSDS, ESDS, RRDS, Linear, PDSE, and UNIX are readable at IPL
time.  SYS1.NUCLEUS could be either merged with NIP or put in either a
PDSE or UNIX file system.  An appropriate UNIX file structure would be
the alternative SPOOL for both JES2 and JES3 (idea snitched from my
time contracting at a site with HP-UX).  ESDS data sets would have to
have a GDG equivalent capability and tools for converting JCL would
have to created.  If UNIX file systems have all of the capability of
PDSE for load modules (and other uses) maybe PDSE should be
functionally stabilized.  An alternative would be to make PDSEs
readable across sysplex boundaries.

I find it ludicrous that started tasks are needed to read basic file
structures such as PDSE and UNIX FS.  It reminds me of my frustration
that we couldn't use our local channel attached SNA 3270s for consoles
back in the 1980s.  We needed to have 2 non-SNA controllers so that
the controller wasn't a single point of failure for IPL.

How reliable is PDSE these days? 

Clark Morris 
>
>-- Few mature shops have standardized on PDSE application load libraries.
>I'd venture to say that other than those necessitated by program products,
>including some pieces of z/OS, PDSEs are fairly rare in most shops. 
>
>-- Here's a serious inhibitor for some shops. Despite decades of advice to
>the contrary, some shops still share application load libraries across
>sysplex boundaries. This practice dates back to pre-sysplex configurations.
>While sharing a PDS in this way is risky, sharing a PDSE among sysplexes is
>a recipe for disaster because only sysplex understands PDSE. It's not GRS or
>ISV equivalent; it's sysplex itself. (I don't know the technicality of this
>limitation.) You cannot just convert a shared PDS to a PDSE. You have to
>change your application load module management practices to support multiple
>targets. If you have product or RYO code that migrates a load module from
>DEV to PROD, you have to change the process to migrate from DEV to PROD1,
>PROD2, ... PRODn. Depending on your configuration and migration process,
>this could be a big deal. This change has to be completed before the first
>COBOL V5 load module moves to production. 
>
>This is not an objection of the COBOL V5 requirement, just an acknowledgment
>of customer uneasiness. 
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>jo.skip.robin...@att.net
>jo.skip.robin...@gmail.com
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Frank Swarbrick
>> Sent: Monday, January 25, 2016 09:01 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: COBOL v5
>> 
>> The one reason I know of what a PDSE is required is because TEST/DEBUG
>> information is now stored in a DWARF NOLOAD segment, and those are only
>> supported by PDSE (or UNIX directory).
>> 
>> > Date: Sat, 23 Jan 2016 14:55:31 -0800
>> > From: charl...@mcn.org
>> > Subject: Re: COBOL v5
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> >
>> > If by "requires" you mean in some absolute fundamental
>> > logical/technical sense, you may well be right. This might be a
>> > "marketing" restriction for all any of us knows.
>> >
>> > OTOH I can assure you it requires a PDSE in the sense that if you
>> > compile a program using COBOL 5.2 and attempt to bind the resulting
>> > object code into an executable, the binder will fail if SYSLMOD
>> > references a PDS -- so in that sense I assure you that COBOL 5.2
>"requires" a
>> PDSE.
>> >
>> > Charles
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> >

COBOL v5

[Bill Woodger]

On Wednesday, 27 January 2016 17:26:04 UTC, Barry Lichtenstein  wrote:
> It's not the JCL per-se.  The combination of XOBJ object modules and the 
> Prelinker was a tactical solution to advancements in programs, originally 
> created for C programs.  XOBJ object modules addressed several deficiencies 
> in OBJ object modules, such the ability to have long case-sensitive 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 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 enhancements to OBJ object module and load 
> module formats.  Some important things have been added such as AMODE 64 and 
> quad-word alignment.
> 
> barry_lichtenst...@us.ibm.com
> 

Sorry, I was still being unclear. What I meant is that if you run JCL which 
uses a PDSE as output for executable programs, then you are using a PDSE. If 
you run JCL that uses a PDS, then you are using a PDS. Using a PDSE in the JCL 
to compile a PL/I program does not mean that PL/I can only produce code 
requiring Program Objects, which was that little side-track in the discussion.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Future shock (Was: COBOL v5)

[Paul Gilmartin]

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
aspirations to feed such a NOGOFF object to Linkage Editor?

My SYSEXEC is a concatenation of PDS and UNIX directories.  That's
not supported.  IBM has sternly told me that when I attempted to
report a problem.  Yet I prefer its shortcoming to the alternative of
synching EXECs between PDS and UNIX.

Our site shares PDSEs transplex to test systems.  Not supported.
Yet we prefer the recurrent ENQ lockouts to the chore of synching
content among multiple PDSEs.

Make lemonade.  If I had a buggy whip, I'd complain that I can't use
it to control my Tesla.  If I had a Tesla.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Tom Marchant]

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 with standard linkage. So, if you have 
an application that consists of several modules, they have to be either 
all XPLINK-64 or none of them.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Don Poitras]

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 another impediment, IMO. That is that XPLINK-64 cannot easily 
> coexist with either XPLINK-31 or with standard linkage. So, if you have 
> an application that consists of several modules, they have to be either 
> all XPLINK-64 or none of them.

> -- 
> Tom Marchant

Your third sentence is refuted by your second. Yes, it's not easy, but
it can be done. IBM could make this easier if they would do the work to
provide 64-bit DLLs for more of their products. As more customers go
to 64-bit, the presure for that will build. Another issue is IEEE float.
Hex float can be used by XPLINK callers, but the HFP library is non-
XPLINK, so ends up being much slower. If your code is in a high-level
language, you can mostly get by by using FLOAT(IEEE), but if you have
lots of assembler math routines (I wonder who would have those?), you're
going to have to dig in a bit. I highly recommend the floating point
chapters in John Erman's assembler book for teaching yourself the 
fine points of this stuff. The pop is probably good enough for the 
mathmeticians among us, but I needed a primer. You can download here:

http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language%20Programming%20for%20IBM%20z%20System%20Servers.pdf

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Tom Marchant]

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 application that consists of several modules, they have to be either
>> all XPLINK-64 or none of them.
>
>Your third sentence is refuted by your second. Yes, it's not easy, but
>it can be done. IBM could make this easier if they would do the work to
>provide 64-bit DLLs for more of their products. 

I should have written, "XPLINK-64 cannot coexist with XPLINK-31 or with 
non-XPLINK LE programs in the same LE enclave." The issue is that the 
LE control blocks are not compatible between these three LE environments. 
IMO it is a reason for LE to provide support for 64-bit code using standard 
(F4SA, F5SA, etc.) save areas.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Barry Lichtenstein]

It's not the JCL per-se.  The combination of XOBJ object modules and the 
Prelinker was a tactical solution to advancements in programs, originally 
created for C programs.  XOBJ object modules addressed several deficiencies in 
OBJ object modules, such the ability to have long case-sensitive 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 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 enhancements to OBJ object module and load 
module formats.  Some important things have been added such as AMODE 64 and 
quad-word alignment.

barry_lichtenst...@us.ibm.com

On Tue, 26 Jan 2016 13:52:28 -0600, Bill Woodger wrote:

> Sorry not to be clear that I was paraphrasing the PL/I Programming Guide:
> 
> 
> "Cataloged procedures IBMZCB and IBMZCBG use features of the program
> management binder introduced in DFSMS/MVS ® 1.4 in place of the prelinker
> supplied with Language Environment. These procedures produce a program object
> in a PDSE.
> 
> Cataloged procedures IBMZCPL, IBMZCPLG and IBMZCPG use the prelinker
> supplied with Language Environment and produce a load module in PDS. Use
> these procedures if you do not want to use a PDSE.
> 
> ...
> 
> The IBMZCB cataloged procedure, shown in Figure 11 on page 142, includes two
> procedure steps: PLI, which is identical to cataloged procedure IBMZC, and 
> BIND,
> which invokes the Program Management binder (symbolic name IEWBLINK) to
> bind the object module produced in the first procedure step.
> ...
> 
> The IBMZCPL cataloged procedure, shown in Figure 13, includes three procedure
> steps: PLI, which is identical to cataloged procedure IBMZC; PLKED, which
> invokes the Language Environment prelinker; and LKED, which invokes the
> linkage editor (symbolic name IEWL) to link-edit the object module produced in
> the first procedure step."
> 
> At the end of the day, it is 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 behind it.
> 
> Aside 2: Who thought it was a good idea to name a place where one or more 
> Object Programs can turn up a Program Object. That's clear, right?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Quadword Alignment in OBJ Modules (Was: COBOL v5)

[Ed Jaffe]

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 alignment.


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

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Don Poitras]

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-online.de> you wrote:
> In the PL/1 mailing list, Peter Elderon (IBM) explicitly stated that there
> are no plans to force the PL/1 users to PDSEs, so IMO this is not true 
> for PL/1,
> at least.
> Kind regards
> Bernd
> Am 26.01.2016 um 15:10 schrieb Steve Thompson:
> > IIRC: At Share 2015 in Seattle, wasn't it stated that the COBOL 5 code 
> > generator is the one that PL/1, C/C++, and a few others are using or 
> > will (soon) be using?
> >
> > IOW: The "architecture aware" code generator was going to be common. 
> > That means it will be generating program objects.
> >
> >
> > Regards,
> > Steve Thompson

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Farley, Peter x23353]

Sorry Ed, many shops and application programmers disagree strongly with that 
opinion.  AMODE64 for COBOL for us is a must-get-to for large in-core tables 
and many other application needs, in the same way and for many of the same 
reasons that 31-bit COBOL was a necessity in the 24-bit COBOL era when the 8 or 
10 Mib private region size was the constraint.

It isn't for large *programs* that AMODE64 is needed, but for large *data*.  
For sure I'm not about to write or support program code that occupies more than 
2GiB of storage, but surely you can see the extreme usefulness of multi-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 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 alignment.
>
> barry_lichtenst...@us.ibm.com

Since COBOL does not and will not in the foreseeable future need  
amode 64 I find the argument un helpful.

Ed
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Quadword Alignment in OBJ Modules (Was: COBOL v5)

[Thomas David Rivers]

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 and quad-word alignment.



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


Good question!

See zOS MVS Program Management: Advanced Facilities (SA23-1392-00),  in 
the section
titled "ESD record" - it's clear you can create an SD, PC or CM symbol 
with quadword
alignment.You can also see the definitions for RMODE 64 and AMODE 64 
there.


The section on "Load module formats"  also indicates how to specify 
quad-word

alignment on these symbols.

Furthmore, from the HLASM Programmar's Guide (SC26-4941-06) we can also
find the same definitions in the section named "ESD record format".

I wonder why HLASM generates this warning - the description for it says:



--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Ed Gould]

On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote:

It's not the JCL per-se.  The combination of XOBJ object modules  
and the Prelinker was a tactical solution to advancements in  
programs, originally created for C programs.  XOBJ object modules  
addressed several deficiencies in OBJ object modules, such the  
ability to have long case-sensitive 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 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 enhancements to OBJ  
object module and load module formats.  Some important things have  
been added such as AMODE 64 and quad-word alignment.


barry_lichtenst...@us.ibm.com


Since COBOL does not and will not in the foreseeable future need  
amode 64 I find the argument un helpful.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Ed Gould]

Peter:

I agree with you. BUT as we have heard many times IBM doesn't see a  
need for this and have relegated COBOL to the dust bin of history. We  
have had discussions on here about the need but until there is  
critical mass IBM will not consider this as a "need".
Then IBM will probably come up with a half cocked idea like mandating  
PDSE's.


Ed
On Jan 27, 2016, at 2:00 PM, Farley, Peter x23353 wrote:

Sorry Ed, many shops and application programmers disagree strongly  
with that opinion.  AMODE64 for COBOL for us is a must-get-to for  
large in-core tables and many other application needs, in the same  
way and for many of the same reasons that 31-bit COBOL was a  
necessity in the 24-bit COBOL era when the 8 or 10 Mib private  
region size was the constraint.


It isn't for large *programs* that AMODE64 is needed, but for large  
*data*.  For sure I'm not about to write or support program code  
that occupies more than 2GiB of storage, but surely you can see the  
extreme usefulness of multi-GiB of main-storage data accessed by a  
program.


Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@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 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 alignment.

barry_lichtenst...@us.ibm.com


Since COBOL does not and will not in the foreseeable future need
amode 64 I find the argument un helpful.

Ed
--

This message and any attachments are intended only for the use of  
the addressee and may contain information that is privileged and  
confidential. If the reader of the message is not the intended  
recipient or an authorized representative of the intended  
recipient, you are hereby notified that any dissemination of this  
communication is strictly prohibited. If you have received this  
communication in error, please notify us immediately by e-mail and  
delete the message and any attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Farley, Peter x23353]

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 into that 64-bit future 
because of PDSE-fear, but it is coming nonetheless.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Wednesday, January 27, 2016 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL v5

Peter:

I agree with you. BUT as we have heard many times IBM doesn't see a  
need for this and have relegated COBOL to the dust bin of history. We  
have had discussions on here about the need but until there is  
critical mass IBM will not consider this as a "need".
Then IBM will probably come up with a half cocked idea like mandating  
PDSE's.

Ed
On Jan 27, 2016, at 2:00 PM, Farley, Peter x23353 wrote:

> Sorry Ed, many shops and application programmers disagree strongly  
> with that opinion.  AMODE64 for COBOL for us is a must-get-to for  
> large in-core tables and many other application needs, in the same  
> way and for many of the same reasons that 31-bit COBOL was a  
> necessity in the 24-bit COBOL era when the 8 or 10 Mib private  
> region size was the constraint.
>
> It isn't for large *programs* that AMODE64 is needed, but for large  
> *data*.  For sure I'm not about to write or support program code  
> that occupies more than 2GiB of storage, but surely you can see the  
> extreme usefulness of multi-GiB of main-storage data accessed by a  
> program.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM- 
> m...@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 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 alignment.
>>
>> barry_lichtenst...@us.ibm.com
>
> Since COBOL does not and will not in the foreseeable future need
> amode 64 I find the argument un helpful.
>
> Ed
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Paul Gilmartin]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

COBOL v5

[Bill Woodger]

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 Optimizer was intended as an amelioration for clients 
concerned about moving to V5 but wanting the performance boost from the latest 
processors.

It comes from IBM Research. The first I saw of it was in a LinkedIn group in 
September 2013, and the Developer Works article linked-to there stated:

"This tool can optimize program modules generated by the following COBOL 
compilers:

COBOL for OS/390 & VM V2
Enterprise COBOL for z/OS v3
Enterprise COBOL for z/OS v4

The tool runs on z/OS version 1.11 or later.
The tool can generate program modules for z10, z196, or zEC12."

Given the range of compilers (and OSes) and target machines, greatly increasing 
development and support complexity, it is no surprise that there has been 
rationalisation.

Whether how it will be used (likely) is coincidence or a later design I don't 
know.

It is not a panacea. From discussion on that group at the time with IBM's 
Marcel Mitran:

"The research team has been collaborating very closely with the COBOL compiler 
team. In fact several of the optimizations used in the binary optimizer were 
co-developed with the compiler team... In general, I would expect the binary 
optimizer improvement to be less than that of the compiler. A fully-enabled and 
optimizing compiler like COBOL 5.1 should always be the preferred approach to 
optimizing applications. The binary optimizer is really only meant to address 
concerns when a recompile is not feasible."

Their current documented suggestions for the situations where the Binary 
Optimizer could be used bear that out.

Use case

IBM Automatic Binary Optimizer for z/OS

Significant performance improvement without requiring source, migration, or 
options tuning

Interoperability and legacy compatibility (eg, support for PDS and old 
Enterprise COBOL)

No need to downgrade ARCH setting to match disaster recovery machine

Latest IBM COBOL compilers

New COBOL development

Maintenance on existing COBOL programs

Maximum performance improvement (source, migration, and options tuning required)


Yes, it does mention the PDS thing. No, it doesn't work on V5 programs.

Enterprise COBOL generating Program Objects is not new with V5. It is new that 
all code generated from V5 must now be Program Objects.

It is central and indivisible in V5. It is part of the planning for the 
development of V5 and beyond. There's no going back with the new compiler.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[John Eells]

Charles Mills wrote:

I was going to post about this but could not remember whether it was still 
under NDA or not and was too busy to research.

Yes! Customers told IBM what has been posted on this thread: "COBOL v5.2 is out of the 
question because we have existing load modules in (PDS) libraries that are *never* not allocated to 
a job on one system or another." (Plus "we have tons of JCL and no budget to revamp it 
all in some clever fashion that would facilitate a phased migration to new (PDSE) libraries.")

This is IBM's solution. Just as the COBOL Binary Optimizer 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 COBOL V5 PDS/PDSE conversions came to us after someone (you 
know who you are...and thanks!) at the TDM pointed it out.


It's certainly not the first time we've built something with one purpose 
in mind to find that it's got other uses; sometimes the "other uses" 
turn out to have more value than the originally intended purpose.  It 
happens.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Ed Gould]

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 post on the  
list itself...


I don't think the Binary Optimizer was intended as an amelioration  
for clients concerned about moving to V5 but wanting the  
performance boost from the latest processors.


It comes from IBM Research. The first I saw of it was in a LinkedIn  
group in September 2013, and the Developer Works article linked-to  
there stated:


"This tool can optimize program modules generated by the following  
COBOL compilers:


COBOL for OS/390 & VM V2
Enterprise COBOL for z/OS v3
Enterprise COBOL for z/OS v4

The tool runs on z/OS version 1.11 or later.
The tool can generate program modules for z10, z196, or zEC12."

Given the range of compilers (and OSes) and target machines,  
greatly increasing development and support complexity, it is no  
surprise that there has been rationalisation.


Whether how it will be used (likely) is coincidence or a later  
design I don't know.


It is not a panacea. From discussion on that group at the time with  
IBM's Marcel Mitran:


"The research team has been collaborating very closely with the  
COBOL compiler team. In fact several of the optimizations used in  
the binary optimizer were co-developed with the compiler team... In  
general, I would expect the binary optimizer improvement to be less  
than that of the compiler. A fully-enabled and optimizing compiler  
like COBOL 5.1 should always be the preferred approach to  
optimizing applications. The binary optimizer is really only meant  
to address concerns when a recompile is not feasible."


Their current documented suggestions for the situations where the  
Binary Optimizer could be used bear that out.


Use case

IBM Automatic Binary Optimizer for z/OS

Significant performance improvement without requiring source,  
migration, or options tuning


Interoperability and legacy compatibility (eg, support for PDS and  
old Enterprise COBOL)


No need to downgrade ARCH setting to match disaster recovery machine

Latest IBM COBOL compilers

New COBOL development

Maintenance on existing COBOL programs

Maximum performance improvement (source, migration, and options  
tuning required)



Yes, it does mention the PDS thing. No, it doesn't work on V5  
programs.


Enterprise COBOL generating Program Objects is not new with V5. It  
is new that all code generated from V5 must now be Program Objects.


It is central and indivisible in V5. It is part of the planning for  
the development of V5 and beyond. There's no going back with the  
new compiler.


IMO IBM blew it on this alone and will loose customers. Maybe even  
the account I am helping out now. At best it was a short sighted  
attempt to get people to buy new hardware. In case IBM didn't realize  
money is extremely tight and bullying them is not a good way to make  
friends.
I will help my client out on figuring a way around this financial  
bullying tactic. If asked I will explain IBM is no longer in the  
business of working for the small business.


It might be IBM has done what MS did with XP. Hint people (many) are  
still running XP.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Charles Mills]

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 wrote:
> I was going to post about this but could not remember whether it was still 
> under NDA or not and was too busy to research.
>
> Yes! Customers told IBM what has been posted on this thread: "COBOL 
> v5.2 is out of the question because we have existing load modules in 
> (PDS) libraries that are *never* not allocated to a job on one system 
> or another." (Plus "we have tons of JCL and no budget to revamp it all 
> in some clever fashion that would facilitate a phased migration to new 
> (PDSE) libraries.")
>
> This is IBM's solution. Just as the COBOL Binary Optimizer 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 COBOL 
V5 PDS/PDSE conversions came to us after someone (you know who you are...and 
thanks!) at the TDM pointed it out.

It's certainly not the first time we've built something with one purpose in 
mind to find that it's got other uses; sometimes the "other uses" 
turn out to have more value than the originally intended purpose.  It happens.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL v5

[Steve Thompson]

IIRC: At Share 2015 in Seattle, wasn't it stated that the COBOL 5 
code generator is the one that PL/1, C/C++, and a few others are 
using or will (soon) be using?


IOW: The "architecture aware" code generator was going to be 
common. That means it will be generating program objects.



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 libraries, however, it is not possible."




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN