Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[Tom Marchant]

On Thu, 14 Sep 2017 13:16:58 -0500, Giliad Wilf wrote:

>Yes, but no PDSE may be listed in LPALSTxx, and since LPALSTxx 
>must list SYS1.LPALIB, it can't be a PDSE.

It is true that SYS1.LPALIB cannot be a PDSE, but who cares?
It isn't important. MVS has long had a mechanism to include 
program objects in LPA when the system is IPLed.

-- 
Tom Marchant
 
>On Thu, 14 Sep 2017 07:13:38 -0500, Tom Marchant  
>wrote:
>
>>On Thu, 14 Sep 2017 13:02:54 +0200, Peter Hunkeler wrote:
>>
>>>The LPA is built as part of the IPL process, but only load modules 
>>>not programs objects can be loaded into PLA at that time because 
>>>program objects live in PDS/Es.
>>
>>The LPA statement in PROGxx is processed at the end of IPL.
>>PDSEs can be included at that time.
>>
>>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/proglpa.htm
>>
>>This is a recurring complaint about PDSEs, but I don't see the merit 
>>in it. MVS has provided a mechanism to include program objects when 
>>it is IPLed.

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

Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[Giliad Wilf]

Yes, but no PDSE may be listed in LPALSTxx, and since LPALSTxx must list 
SYS1.LPALIB, it can't be a PDSE.
 
On Thu, 14 Sep 2017 07:13:38 -0500, Tom Marchant  
wrote:

>On Thu, 14 Sep 2017 13:02:54 +0200, Peter Hunkeler wrote:
>
>>The LPA is built as part of the IPL process, but only load modules 
>>not programs objects can be loaded into PLA at that time because 
>>program objects live in PDS/Es.
>
>The LPA statement in PROGxx is processed at the end of IPL.
>PDSEs can be included at that time.
>
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/proglpa.htm
>
>This is a recurring complaint about PDSEs, but I don't see the merit 
>in it. MVS has provided a mechanism to include program objects when 
>it is IPLed.
>
>-- 
>Tom Marchant
>
>--
>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: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[Tom Marchant]

On Thu, 14 Sep 2017 13:02:54 +0200, Peter Hunkeler wrote:

>The LPA is built as part of the IPL process, but only load modules 
>not programs objects can be loaded into PLA at that time because 
>program objects live in PDS/Es.

The LPA statement in PROGxx is processed at the end of IPL.
PDSEs can be included at that time.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/proglpa.htm

This is a recurring complaint about PDSEs, but I don't see the merit 
in it. MVS has provided a mechanism to include program objects when 
it is IPLed.

-- 
Tom Marchant

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

AW: Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[Peter Hunkeler]

>> In my opinion PDSE design wasn't and still isn't ready for prime time.
>> It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB because it
depends on a started task.
 >
>Kind of an arbitrary standard, isn't it? I could argue VSAM or DB2 are not
>ready for prime time because you can't use them for SYS1.NUCLEUS residence.




I don't think these are comparable things. The LPA is built as part of the IPL 
process, but only load modules not programs objects can be loaded into PLA at 
that time because program objects live in PDS/Es. You can load program objects 
into dynamic LPA after IPL has completed, but this code is loaded elsewhere 
(CSA not LPA).


Does this really matter, I hesitate to say yes. But, you can argue that the LPA 
is part of the "MVS kernel", and as such it might be desirable to be able to 
load program objects in the IPL phase already. Again, no strong feelings on the 
necessity on my side. However I always felt such basic things should move into 
the "kernel" one day or the other.


--
Peter Hunkeler



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

Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[Charles Mills]

> In my opinion PDSE design wasn't and still isn't ready for prime time.
> It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB because it
depends on a started task.

Kind of an arbitrary standard, isn't it? I could argue VSAM or DB2 are not
ready for prime time because you can't use them for SYS1.NUCLEUS residence.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, September 13, 2017 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support
for Doc for COBOL

[Default] On 7 Sep 2017 22:56:50 -0700, in bit.listserv.ibm-main
sipp...@sg.ibm.com (Timothy Sipples) wrote:

>IBM first introduced PDSEs about 27 years ago. IBM first introduced 
>Java on
>OS/390 about 21 years ago.
>
>That's a long, long time ago.

In my opinion PDSE design wasn't and still isn't ready for prime time.
It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB because it
depends on a started task.  While I would agree that SYS1.NUCLEUS could be 

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

Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[John Eells]

Paul Gilmartin wrote:

On Wed, 13 Sep 2017 15:52:27 -0300, Clark Morris wrote:


In my opinion PDSE design wasn't and still isn't ready for prime time.
It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB
because it depends on a started task.  ...


In turn, I'd expect that prohibits program objects in SYS1.LPALIB.



Much of the PDSE code lives in LPALIB.  This precludes the use of 
program objects in any IPL-time LPA list data set.  The use of the PDSE 
started tasks (SMSPDSE and SMSPDSE1) are secondary to being able to 
build PLPA to begin with.


--
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: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[Paul Gilmartin]

On Wed, 13 Sep 2017 15:52:27 -0300, Clark Morris wrote:
>
>In my opinion PDSE design wasn't and still isn't ready for prime time.
>It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB
>because it depends on a started task.  ...
> 
In turn, I'd expect that prohibits program objects in SYS1.LPALIB.

-- gil

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

PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

[Clark Morris]

[Default] On 7 Sep 2017 22:56:50 -0700, in bit.listserv.ibm-main
sipp...@sg.ibm.com (Timothy Sipples) wrote:

>IBM first introduced PDSEs about 27 years ago. IBM first introduced Java on
>OS/390 about 21 years ago.
>
>That's a long, long time ago.
>
>It's impossible to defend stubborn opposition to these and to other highly
>mature technologies. Business (and the business of government) will get
>done, with or without you. If that's how you choose to (mis)behave, then I
>can't criticize managers who decide to chuck you in the garbage heap of
>history. If you won't change, then you should be/will be changed. I suppose
>we can quibble about how much change makes business sense in particular
>contexts, but zero is the wrong answer.

In my opinion PDSE design wasn't and still isn't ready for prime time.
It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB
because it depends on a started task.  While I would agree that
SYS1.NUCLEUS could be just a very big IPL text, that still leaves
SYS1.LPALIB and any other data sets read during systems
initialization.  Also the design of limiting PDSE sharing to being
within a sysplex contravened what many shops were doing.  It is like
being required to have BiSync controllers for consoles since channel
attached SNA controllers couldn't be accessed until the VTAM started
task was up (something that still rankles 30+ years later).  In both
cases limited functionality enabling use of data sets or devices
during system initialization could and should have been built into NIP
/ SYS1.NUCLEUS or SYS1.LPALIB.  I can not comment on the reliability
of PDSE when used as specified by IBM with sharing only within a
sysplex but the rate of corrective service and frequency of hiper
APARs would tell the story.  I remember the long teething period for
ICF catalogs.

Clark Morris
>
>Jimmy Iovine said it well: "Never stop being of service."
>
>(My views are my own.)
>
>
>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

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

Re: Lack of Support for Doc for COBOL

[Jesse 1 Robinson]

From the get-go (mid 90s) we created multiple sysplexes for business reasons. 
Long before sysplex, it was the practice here not to share *anything* among 
'systems', each of which had its own purpose: sandbox, development, production, 
etc. For us it was natural (and surprisingly easy) to convert each system into 
its own separate sysplex. Sharing was kept within a strict functional unit. 
Sysplex was the new unit. 

I understand that many (most?) shops did not evolve that way. When I first 
heard at SHARE about the PDSE requirement for COBOL, I was concerned that many 
shops would have to change their way of doing business. It's not an 
insurmountable problem, but it's a 'gate' to moving forward. Unfortunately a 
shop that has shared PDS forever sees little business benefit in creating and 
maintaining multiple PDSEs even though the post-conversion overhead is minimal. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Thursday, September 07, 2017 11:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Lack of Support for Doc for COBOL

On Fri, 8 Sep 2017 13:57:53 +0800, Timothy Sipples  wrote:

>IBM first introduced PDSEs about 27 years ago. IBM first introduced 
>Java on
>OS/390 about 21 years ago.
>
>That's a long, long time ago.
>
>It's impossible to defend stubborn opposition to these and to other 
>highly mature technologies. Business (and the business of government) 
>will get done, with or without you. If that's how you choose to 
>(mis)behave, then I can't criticize managers who decide to chuck you in 
>the garbage heap of history. If you won't change, then you should 
>be/will be changed. I suppose we can quibble about how much change 
>makes business sense in particular contexts, but zero is the wrong answer.
>
>Jimmy Iovine said it well: "Never stop being of service."
>

Still, the idea that safe, regulated sharing of a PDSE can only be guaranteed 
to members of a single sysplex, seems to hint that IBM thought at time that no 
one will ever need more than one sysplex.
Doesn't it seem so?


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

PDSERe: Lack of Support for Doc for COBOL

[Clark Morris]

[Default] On 7 Sep 2017 22:56:50 -0700, in bit.listserv.ibm-main
sipp...@sg.ibm.com (Timothy Sipples) wrote:

>IBM first introduced PDSEs about 27 years ago. IBM first introduced Java on
>OS/390 about 21 years ago.
>
>That's a long, long time ago.
>
>It's impossible to defend stubborn opposition to these and to other highly
>mature technologies. Business (and the business of government) will get
>done, with or without you. If that's how you choose to (mis)behave, then I
>can't criticize managers who decide to chuck you in the garbage heap of
>history. If you won't change, then you should be/will be changed. I suppose
>we can quibble about how much change makes business sense in particular
>contexts, but zero is the wrong answer.
>
>Jimmy Iovine said it well: "Never stop being of service."
>
>(My views are my own.)
>
>
>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

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

Re: Lack of Support for Doc for COBOL

[Giliad Wilf]

On Fri, 8 Sep 2017 13:57:53 +0800, Timothy Sipples  wrote:

>IBM first introduced PDSEs about 27 years ago. IBM first introduced Java on
>OS/390 about 21 years ago.
>
>That's a long, long time ago.
>
>It's impossible to defend stubborn opposition to these and to other highly
>mature technologies. Business (and the business of government) will get
>done, with or without you. If that's how you choose to (mis)behave, then I
>can't criticize managers who decide to chuck you in the garbage heap of
>history. If you won't change, then you should be/will be changed. I suppose
>we can quibble about how much change makes business sense in particular
>contexts, but zero is the wrong answer.
>
>Jimmy Iovine said it well: "Never stop being of service."
>

Still, the idea that safe, regulated sharing of a PDSE can only be guaranteed
to members of a single sysplex, seems to hint that IBM thought at time
that no one will ever need more than one sysplex.
Doesn't it seem so?

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

Re: Lack of Support for Doc for COBOL

[Timothy Sipples]

IBM first introduced PDSEs about 27 years ago. IBM first introduced Java on
OS/390 about 21 years ago.

That's a long, long time ago.

It's impossible to defend stubborn opposition to these and to other highly
mature technologies. Business (and the business of government) will get
done, with or without you. If that's how you choose to (mis)behave, then I
can't criticize managers who decide to chuck you in the garbage heap of
history. If you won't change, then you should be/will be changed. I suppose
we can quibble about how much change makes business sense in particular
contexts, but zero is the wrong answer.

Jimmy Iovine said it well: "Never stop being of service."

(My views are my own.)


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

AW: Re: Lack of Support for Doc for COBOL

[Peter Hunkeler]

>I know companies which are not ready for computers at all.
PDSE is so new... ;-)


I know of companies (or should I say managers) who believe they are beyond the 
need for computers since there is the Internet and Google 8-)


--
Peter Hunkeler




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

Re: Lack of Support for Doc for COBOL

[Pommier, Rex]

Re:  Java is a word not an acronym...  Just Another Vague Acronym?  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Thursday, September 07, 2017 5:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

On 7/09/2017 9:15 AM, Edward Gould wrote:
>> I think that we've finally got past that hang-up. PDSE is ready for prime 
>> time.
> The PDSe outage brought the company to its knees. They do NOT want to see the 
> same thing happening again. All the higher up operating officers got their 
> hands slapped and not nicely either. They lost their bonuses and lost 
> vacation time and a few other things that I am not sure of so I won’t 
> speculate.

I'm glad I don't work for a company who punish people for problems they 
we're not responsible for. If a PDSE problem really did bring your 
company to it's knees then your company probably needs to review it's 
procedures.

> I know that there are some necessary PDSe’s but have hidden that fact from 
> them. My boss told me never to tell anyone that we have some.
> I think is we ever had another outage for PDSe they would be out shopping for 
> another vendor and I wouldn’t blame them. I would leave if they ever tried to 
> bring in a replacement.
> They are extremely weary of JAVA as well, I expect then to get over it in 
> time, but I am not going to push it.

Java is a word not an acronym.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: Lack of Support for Doc for COBOL

[Edward Gould]

> On Sep 6, 2017, at 11:19 AM, Frank Swarbrick  
> wrote:
> 
> I understand the PDSE fear, though we've not run in to any issues.  I don't 
> understand what programmers don't like about COBOL V5/V6.  Do you have any 
> concrete examples?  Just wondering.  I like the new compiler releases.  The 
> NUMCHECK option, when used in development, looks to be very interesting and 
> useful.
> 
> Frank

Frank,
The mere mention that it needs PDSe send spine tingling messages to the nerve 
center and sooner or later the VP’s get involved and when they hear PDSe they 
say its too soon come back it 5 years when it is bug free.
The COBOL itself issue is that (this is bits and pieces I have heard) they just 
do not like it and the documentation sucks (I agree) I have read some of the 
manuals and at times you need to be a lawyer to understand them. With one 
manual I photo copied a few pages and went back to my desk to see if I could 
understand it and after 15 minutes of talking out loud to myself while trying 
to understand it, I ripped the pages up and threw them away. I never wanted to 
see the damn manual again and didn’t want to have to explain it aloud as I 
can’t.

Ed

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

Re: Lack of Support for Doc for COBOL

[Edward Gould]

> On Sep 7, 2017, at 5:24 AM, David Crayford  wrote:
> 
> On 7/09/2017 9:15 AM, Edward Gould wrote:
>>> I think that we've finally got past that hang-up. PDSE is ready for prime 
>>> time.
>> The PDSe outage brought the company to its knees. They do NOT want to see 
>> the same thing happening again. All the higher up operating officers got 
>> their hands slapped and not nicely either. They lost their bonuses and lost 
>> vacation time and a few other things that I am not sure of so I won’t 
>> speculate.
> 
> I'm glad I don't work for a company who punish people for problems they we're 
> not responsible for. If a PDSE problem really did bring your company to it's 
> knees then your company probably needs to review it's procedures.
I was  not around for that catastrophe so I can’t comment on procedures etc etc 
etc. What I can say is that they (upper management) were in some session with 
IBM (dog and pony show I think), IBM came out and pushed PDSe to them on how 
great it was and no problems (this is all hearsay). If I were there at the time 
I would have put a hold and go baby steps, I have been to SHARE and heard the 
horror stories (and lived them at another shop). They actually believed IBM. 
They got there hands slapped from believing IBM. Personally I still hate them. 
and dread doing any work with them. I activly resisted them and if an 
application programmer asks I tell them its too buggy and to stay away. I have 
lost some PDSe’s and I was lucky to have current backups. I have in the past 
just lost them. I was cursing at IBM. Even with VSAM I never lost the vsam file 
in the 20+ years before it became ubiquitous. I somehow was lucky, but I was 
seemingly always putting on the mega PTF tapes that Every one hated, but the 
thing worked (we didn’t do anything exotic), The only time I cursed at VSAM was 
that we had an early solid state drum that had PLPA on it and evertime the 
thing dropped power it lost the PLPA and I had to quick reinitialize it and 
delete the old PLPA in the catalog and redefine it and update parmlib so we 
could IPL again, Each of those times was a 30 minute episode of terror for me 
as we were being really hit by every one because of all the outages. One group 
had 2000 people waiting for CICS to get up again. 

We had to get rid of the solid state because of the pain, I actually liked it 
when it worked it worked great.

> 
>> I know that there are some necessary PDSe’s but have hidden that fact from 
>> them. My boss told me never to tell anyone that we have some.
>> I think is we ever had another outage for PDSe they would be out shopping 
>> for another vendor and I wouldn’t blame them. I would leave if they ever 
>> tried to bring in a replacement.
>> They are extremely weary of JAVA as well, I expect then to get over it in 
>> time, but I am not going to push it.
> 
> Java is a word not an acronym.

They tried it early on and the amount of real storage it needed brought the 
system to its knees, and again I was not there or else I would have ask them to 
do it at an low point.
Ed


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

Re: Lack of Support for Doc for COBOL

[David Crayford]

On 7/09/2017 7:10 PM, R.S. wrote:

W dniu 2017-09-07 o 12:24, David Crayford pisze:

On 7/09/2017 9:15 AM, Edward Gould wrote:
I think that we've finally got past that hang-up. PDSE is ready for 
prime time.
The PDSe outage brought the company to its knees. They do NOT want 
to see the same thing happening again. All the higher up operating 
officers got their hands slapped and not nicely either. They lost 
their bonuses and lost vacation time and a few other things that I 
am not sure of so I won’t speculate.


I'm glad I don't work for a company who punish people for problems 
they we're not responsible for. If a PDSE problem really did bring 
your company to it's knees then your company probably needs to review 
it's procedures.




Of course I meant *were. Bloody iPhone.


I know companies which are not ready for computers at all.
PDSE is so new... ;-)


My goodness what would they say if somebody suggested using the z/OS 
Unix file system? :)







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

Re: Lack of Support for Doc for COBOL

[R.S.]

W dniu 2017-09-07 o 12:24, David Crayford pisze:

On 7/09/2017 9:15 AM, Edward Gould wrote:
I think that we've finally got past that hang-up. PDSE is ready for 
prime time.
The PDSe outage brought the company to its knees. They do NOT want to 
see the same thing happening again. All the higher up operating 
officers got their hands slapped and not nicely either. They lost 
their bonuses and lost vacation time and a few other things that I am 
not sure of so I won’t speculate.


I'm glad I don't work for a company who punish people for problems 
they we're not responsible for. If a PDSE problem really did bring 
your company to it's knees then your company probably needs to review 
it's procedures.


I know companies which are not ready for computers at all.
PDSE is so new... ;-)


--
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.plsą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: Lack of Support for Doc for COBOL

[David Crayford]

On 7/09/2017 9:15 AM, Edward Gould wrote:

I think that we've finally got past that hang-up. PDSE is ready for prime time.

The PDSe outage brought the company to its knees. They do NOT want to see the 
same thing happening again. All the higher up operating officers got their 
hands slapped and not nicely either. They lost their bonuses and lost vacation 
time and a few other things that I am not sure of so I won’t speculate.


I'm glad I don't work for a company who punish people for problems they 
we're not responsible for. If a PDSE problem really did bring your 
company to it's knees then your company probably needs to review it's 
procedures.



I know that there are some necessary PDSe’s but have hidden that fact from 
them. My boss told me never to tell anyone that we have some.
I think is we ever had another outage for PDSe they would be out shopping for 
another vendor and I wouldn’t blame them. I would leave if they ever tried to 
bring in a replacement.
They are extremely weary of JAVA as well, I expect then to get over it in time, 
but I am not going to push it.


Java is a word not an acronym.

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

Re: Lack of Support for Doc for COBOL

[Edward Gould]

> On Sep 6, 2017, at 12:40 PM, Jesse 1 Robinson  wrote:
> 
> Well into the 1970s, there were legions of IT folks who did not trust VSAM. 
> There was a droll little ditty of the 'If it...then it's...' type. The last 
> line went, 'If it...but it doesn't work, then it's VSAM'. 
> 
> So is there anyone left who so mistrusts VSAM that they cannot commit to a 
> technology upgrade? I think that we've finally got past that hang-up. PDSE is 
> ready for prime time. 

The PDSe outage brought the company to its knees. They do NOT want to see the 
same thing happening again. All the higher up operating officers got their 
hands slapped and not nicely either. They lost their bonuses and lost vacation 
time and a few other things that I am not sure of so I won’t speculate.
I know that there are some necessary PDSe’s but have hidden that fact from 
them. My boss told me never to tell anyone that we have some. 
I think is we ever had another outage for PDSe they would be out shopping for 
another vendor and I wouldn’t blame them. I would leave if they ever tried to 
bring in a replacement.
They are extremely weary of JAVA as well, I expect then to get over it in time, 
but I am not going to push it.

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

Re: Lack of Support for Doc for COBOL

[Jesse 1 Robinson]

Well into the 1970s, there were legions of IT folks who did not trust VSAM. 
There was a droll little ditty of the 'If it...then it's...' type. The last 
line went, 'If it...but it doesn't work, then it's VSAM'. 

So is there anyone left who so mistrusts VSAM that they cannot commit to a 
technology upgrade? I think that we've finally got past that hang-up. PDSE is 
ready for prime time. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Wednesday, September 06, 2017 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Lack of Support for Doc for COBOL

With the use of the proper compile options I have not heard of any 
compatibility issues in our environment.  Indeed the original COBOL V5 release 
did have some.  But I believe that IBM has now made it possible, with the 
correct compiler options, to get the same results (albeit with generally better 
generated machine code) as with COBOL V4.  There may, of course, still be some 
edge cases.


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, September 6, 2017 10:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I think when you are maintaining 30-year-old 50,000-line programs the phrase 
"slight incompatibility" sends shivers up your spine.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Wednesday, September 6, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I understand the PDSE fear, though we've not run in to any issues.  I don't 
understand what programmers don't like about COBOL V5/V6.  Do you have any 
concrete examples?  Just wondering.  I like the new compiler releases.  The 
NUMCHECK option, when used in development, looks to be very interesting and 
useful.


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

Re: Lack of Support for Doc for COBOL

[Frank Swarbrick]

With the use of the proper compile options I have not heard of any 
compatibility issues in our environment.  Indeed the original COBOL V5 release 
did have some.  But I believe that IBM has now made it possible, with the 
correct compiler options, to get the same results (albeit with generally better 
generated machine code) as with COBOL V4.  There may, of course, still be some 
edge cases.


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, September 6, 2017 10:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I think when you are maintaining 30-year-old 50,000-line programs the phrase
"slight incompatibility" sends shivers up your spine.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Wednesday, September 6, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I understand the PDSE fear, though we've not run in to any issues.  I don't
understand what programmers don't like about COBOL V5/V6.  Do you have any
concrete examples?  Just wondering.  I like the new compiler releases.  The
NUMCHECK option, when used in development, looks to be very interesting and
useful.

--
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: Lack of Support for Doc for COBOL

[Charles Mills]

I think when you are maintaining 30-year-old 50,000-line programs the phrase
"slight incompatibility" sends shivers up your spine.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Wednesday, September 6, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I understand the PDSE fear, though we've not run in to any issues.  I don't
understand what programmers don't like about COBOL V5/V6.  Do you have any
concrete examples?  Just wondering.  I like the new compiler releases.  The
NUMCHECK option, when used in development, looks to be very interesting and
useful.

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

Re: Lack of Support for Doc for COBOL

[Frank Swarbrick]

I understand the PDSE fear, though we've not run in to any issues.  I don't 
understand what programmers don't like about COBOL V5/V6.  Do you have any 
concrete examples?  Just wondering.  I like the new compiler releases.  The 
NUMCHECK option, when used in development, looks to be very interesting and 
useful.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Edward Gould 
Sent: Tuesday, September 5, 2017 7:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

> On Sep 5, 2017, at 4:51 PM, Mike Schwab  wrote:
>>
>> The number of defects reported against COBOL V4 is almost zero!  That is one 
>> of
>> the reasons why we are considering dropping support for COBOL V4.
>>

Sorry to persuade you otherwise. After much talk to/from management we are 
delaying going to the next v6(?) in COBOL.
We/they don’t trust PDSE. It has broken once to often for this customer (I 
agree) and they lost load modules up the ying yang.
They also got feedback from the programmers and how they hate the new COBOL’s.
Management knows that sooner or later they have to go but between PDSE and 
COBOL, they are delaying it as long as they can.
They understand that they are out of service but to quote one VP better to be 
out of service than to loose load modules and that means downtime and they 
can’t afford downtime.
The auditors know about this but as it turns out they hate PDSe’s as much as 
upper management. The CIO is aware and not happy but he got burned with PDSE 
and he agrees that it is worth the chance. I was surprised at their resistance 
but when you here venom coming out of a VP’s mouth about PDSE’s you would 
understand.
I tried to get the programmers resistance to have them write down their issues, 
but I had a feeling they didn’t have to justify much as the VP was really 
pissed.
When IBM makes enemies like this over one portion of the OS, they are asking 
IMO to loose a customer.

Ed

--
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: Lack of Support for Doc for COBOL

[John McKown]

On Tue, Sep 5, 2017 at 4:51 PM, Mike Schwab  wrote:

> How about an II APAR with notes about errors in the manuals?
>

​Just to be my usual "out in left field" self, I wish that IBM would allow
all "no longer available or maintained" manuals to have their "source"
released using the CC​-NC-SA license ( https://creativecommons.org/
licenses/by-nc-sa/4.0/). I do understand why they don't, I guess. But "in a
perfect world" it would be nice. Even nicer would be if they'd use TeX ( tɛx
 ) ​for​ the source.

-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

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: Lack of Support for Doc for COBOL

[Steve Thompson]

On 09/05/2017 09:21 PM, John McKown wrote:

On Tue, Sep 5, 2017 at 8:05 PM, Edward Gould 
wrote:




​We must live right. We use PDSE libraries for most "production" libraries
(load & "sysin"). We have have _no_ problems. But I'd be willing to bet
that is because we are a single system "sysplex" with little sharing.​ We
used to be a two system basic (not parallel) sysplex, but did not have any
problems then either. Likely because all updates to the PDSEs were done on
a single member of the 'plex.



Where I work, we run parallel sysplex. We have multiple LPARs in 
the main sysplex and it was decided to make our Load Libs PDSE 
some years back (perhaps z/OS 1.13?).


However, I've experienced a PDSE failure using z/OS 1.13 at a 
different shop. Thankfully it was a PDSE holding listing members 
and not the source members. I also lost the Loadlib associated 
with it. So I can appreciate the angst.


With the changes that IBM has made to support PDSE, we have not 
had, that I am aware of, any PDSE failures since I was hired.


Meanwhile, I am a bit concerned that problems are not being 
addressed in COBOL manuals, even if they are "small" or 
"insignificant" problems.


Those insignificant DOC problems cause headaches for people 
writing code to do translation. The difference is, I recognized 
immediately how wrong this was (I'm not doing translation, but 
something related).


Now, for INSPECT TALLYING and EVALUATE, I had to go to a third 
party's explanation to get my COBOL code to work. Yep, I had to 
go to a Fujitsu COBOL manual to get an example. The one I had 
when I was writing SMF code on a W/NT 4.0 box many years ago.


Mind you, not the first time for me to use either verb, but there 
was some interesting things I needed to do and the COBOL 4.2 
manual just didn't do it for me. One look at what was said with 
the Fujitsu book and I recognized how I was misreading IBM's doc.


Regards,
Steve Thompson

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

Re: Lack of Support for Doc for COBOL

[John McKown]

On Tue, Sep 5, 2017 at 8:05 PM, Edward Gould 
wrote:

> > On Sep 5, 2017, at 4:51 PM, Mike Schwab  wrote:
> >>
> >> The number of defects reported against COBOL V4 is almost zero!  That
> is one of
> >> the reasons why we are considering dropping support for COBOL V4.
> >>
>
> Sorry to persuade you otherwise. After much talk to/from management we are
> delaying going to the next v6(?) in COBOL.
> We/they don’t trust PDSE. It has broken once to often for this customer (I
> agree) and they lost load modules up the ying yang.
> They also got feedback from the programmers and how they hate the new
> COBOL’s.
> Management knows that sooner or later they have to go but between PDSE and
> COBOL, they are delaying it as long as they can.
> They understand that they are out of service but to quote one VP better to
> be out of service than to loose load modules and that means downtime and
> they can’t afford downtime.
> The auditors know about this but as it turns out they hate PDSe’s as much
> as upper management. The CIO is aware and not happy but he got burned with
> PDSE and he agrees that it is worth the chance. I was surprised at their
> resistance but when you here venom coming out of a VP’s mouth about PDSE’s
> you would understand.
> I tried to get the programmers resistance to have them write down their
> issues, but I had a feeling they didn’t have to justify much as the VP was
> really pissed.
> When IBM makes enemies like this over one portion of the OS, they are
> asking IMO to loose a customer.
>

​We must live right. We use PDSE libraries for most "production" libraries
(load & "sysin"). We have have _no_ problems. But I'd be willing to bet
that is because we are a single system "sysplex" with little sharing.​ We
used to be a two system basic (not parallel) sysplex, but did not have any
problems then either. Likely because all updates to the PDSEs were done on
a single member of the 'plex.



>
> Ed
>
>

-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

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: Lack of Support for Doc for COBOL

[Edward Gould]

> On Sep 5, 2017, at 4:51 PM, Mike Schwab  wrote:
>> 
>> The number of defects reported against COBOL V4 is almost zero!  That is one 
>> of
>> the reasons why we are considering dropping support for COBOL V4.
>> 

Sorry to persuade you otherwise. After much talk to/from management we are 
delaying going to the next v6(?) in COBOL.
We/they don’t trust PDSE. It has broken once to often for this customer (I 
agree) and they lost load modules up the ying yang.
They also got feedback from the programmers and how they hate the new COBOL’s.
Management knows that sooner or later they have to go but between PDSE and 
COBOL, they are delaying it as long as they can. 
They understand that they are out of service but to quote one VP better to be 
out of service than to loose load modules and that means downtime and they 
can’t afford downtime.
The auditors know about this but as it turns out they hate PDSe’s as much as 
upper management. The CIO is aware and not happy but he got burned with PDSE 
and he agrees that it is worth the chance. I was surprised at their resistance 
but when you here venom coming out of a VP’s mouth about PDSE’s you would 
understand.
I tried to get the programmers resistance to have them write down their issues, 
but I had a feeling they didn’t have to justify much as the VP was really 
pissed.
When IBM makes enemies like this over one portion of the OS, they are asking 
IMO to loose a customer.

Ed 

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

Re: Lack of Support for Doc for COBOL

[Mike Schwab]

How about an II APAR with notes about errors in the manuals?

On Tue, Sep 5, 2017 at 12:29 PM, Tom Ross  wrote:
>>Very, considering there are literally hundreds if not thousands of shops
>>still using COBOL..
>
> Yes, it is unfortunate, but for a serious error we would reconsider our 
> position
> on COBOL V4 documentation.
>
> In this case, the reported bug was very minor, and most of the many many COBOL
> shops are already using COBOL V5 or V6, whose manuals are getting updated.
>
> The number of defects reported against COBOL V4 is almost zero!  That is one 
> of
> the reasons why we are considering dropping support for COBOL V4.
>
> 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



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

Re: Lack of Support for Doc for COBOL

[Tom Ross]

>Very, considering there are literally hundreds if not thousands of shops
>still using COBOL..

Yes, it is unfortunate, but for a serious error we would reconsider our position
on COBOL V4 documentation.

In this case, the reported bug was very minor, and most of the many many COBOL
shops are already using COBOL V5 or V6, whose manuals are getting updated.

The number of defects reported against COBOL V4 is almost zero!  That is one of
the reasons why we are considering dropping support for COBOL V4.

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: Lack of Support for Doc for COBOL

[Edward Gould]

> On Sep 4, 2017, at 10:26 AM, scott Ford  wrote:
> 
> Very, considering there are literally hundreds if not thousands of shops
> still using COBOL..
> 
> 
> Scott
Amen to that Scott. At one place I worked there were on the order of 100,000+ 
(I have forgotten the exact number).
And that was in user libraries. I was curious and ran it on our link list and 
found 40.
They are still running everyday and keep working.
BTW the *oldest* COBOL program I found was from 1986.

Ed


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

Re: Lack of Support for Doc for COBOL

[Farley, Peter x23353]

"... continuous documentation delivery ..."  Huh.  Didn't we used to have that 
with a few little things IBM called TNL's?

For hardcover textbooks they issue "Errata" texts on the bookseller or author's 
website(s).  IBM could do that much, but choose not to.  Not sad but dumb, IMHO.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Monday, September 04, 2017 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

Very, considering there are literally hundreds if not thousands of shops
still using COBOL..


Scott

On Fri, Sep 1, 2017 at 9:55 AM Charles Mills  wrote:

> Sad.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Thompson
> Sent: Friday, September 1, 2017 5:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Lack of Support for Doc for COBOL
>
> COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS
> dates.
>
> So here is a response to a document error that was acknowledged as being
> valid:
>
> --
>
> Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
> should be none, and SEP|NOSEP should be the abbreviations for the TEST
> suboptions SEPARATE|NOSEPARATE.
>
> However, we do not update the COBOL V4.2 documentation any longer. We now
> support continuous documentation delivery for COBOL V6.1 and V5.2 only.
>
> Sorry for the inconveniences caused. Let us know if you have further
> questions.
>
> Thanks,
> Dana Zhang 张丹
>
> COBOL Information Developer, PMP
> DevOps Systems ID, China Development Lab, IBM
>
> --
>
> The manual has not been updated since “Second Edition (August 2009)”. So
> one wonders how many errors in the doc have been reported that were not
> applied to this manual.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
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 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: Lack of Support for Doc for COBOL

[scott Ford]

Very, considering there are literally hundreds if not thousands of shops
still using COBOL..


Scott

On Fri, Sep 1, 2017 at 9:55 AM Charles Mills  wrote:

> Sad.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Thompson
> Sent: Friday, September 1, 2017 5:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Lack of Support for Doc for COBOL
>
> COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS
> dates.
>
> So here is a response to a document error that was acknowledged as being
> valid:
>
> --
>
> Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
> should be none, and SEP|NOSEP should be the abbreviations for the TEST
> suboptions SEPARATE|NOSEPARATE.
>
> However, we do not update the COBOL V4.2 documentation any longer. We now
> support continuous documentation delivery for COBOL V6.1 and V5.2 only.
>
> Sorry for the inconveniences caused. Let us know if you have further
> questions.
>
> Thanks,
> Dana Zhang 张丹
>
> COBOL Information Developer, PMP
> DevOps Systems ID, China Development Lab, IBM
>
> --
>
> The manual has not been updated since “Second Edition (August 2009)”. So
> one wonders how many errors in the doc have been reported that were not
> applied to this manual.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Lack of Support for Doc for COBOL

[Charles Mills]

Sad.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Thompson
Sent: Friday, September 1, 2017 5:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Lack of Support for Doc for COBOL

COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS
dates.

So here is a response to a document error that was acknowledged as being
valid:

--

Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
should be none, and SEP|NOSEP should be the abbreviations for the TEST
suboptions SEPARATE|NOSEPARATE.

However, we do not update the COBOL V4.2 documentation any longer. We now
support continuous documentation delivery for COBOL V6.1 and V5.2 only.

Sorry for the inconveniences caused. Let us know if you have further
questions.

Thanks,
Dana Zhang 张丹

COBOL Information Developer, PMP
DevOps Systems ID, China Development Lab, IBM

--

The manual has not been updated since “Second Edition (August 2009)”. So
one wonders how many errors in the doc have been reported that were not
applied to this manual.

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

Lack of Support for Doc for COBOL

[Steve Thompson]

COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS 
dates.

So here is a response to a document error that was acknowledged as being valid:

--

Thanks for your comment. You are correct: abbreviation for TEST|NOTEST should 
be none, and SEP|NOSEP should be the abbreviations for the TEST suboptions 
SEPARATE|NOSEPARATE.

However, we do not update the COBOL V4.2 documentation any longer. We now 
support continuous documentation delivery for COBOL V6.1 and V5.2 only.

Sorry for the inconveniences caused. Let us know if you have further questions.

Thanks,
Dana Zhang 张丹

COBOL Information Developer, PMP
DevOps Systems ID, China Development Lab, IBM

--

The manual has not been updated since “Second Edition (August 2009)”. So one 
wonders how many errors in the doc have been reported that were not applied to 
this manual.


Regards,
Steve Thompson


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