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: SoftwareXcel Discontinued

[Jesse 1 Robinson]

Some time back SHARE folks got wind that IBM was scoring APARs as defects 
against owning organizations and dinging them accordingly. As customers we took 
great umbrage at that judgement, arguing with IBM management that APAR 
fixes--PTFs--serve to improve the product. Especially PTFs installed as 
preventative maintenance. 

It's hard to know what actual impact we had, but we delivered the message loud 
and clear and seemed to get a sympathetic ear from the IBM managers who attend 
SHARE expressly to find out what customers think.

.
.
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 Paul Gilmartin
Sent: Thursday, September 07, 2017 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SoftwareXcel Discontinued

On Fri, 8 Sep 2017 10:22:38 +1000, Andrew Rowley wrote:
>
>The bigger problem is when an organization views customer problem 
>reports as something to be minimized (as opposed to actual problems).
> 
That's what I call "the Microsoft QA metric": the MTB calls to support.
I discovered this years ago when I emailed a colleague a JCL snippet containing 
such as:
//  BLKSIZE=6144
... and he replied, "WTF 'BLKSIZEa44'?"  He had, foolishly IMO, configured Word 
as his MS Exchange viewer.  I surmise MSW ignored my MIME header,
"Content-Transfer-Encoding: 7bit"; did a Bayesian analysis of the content; and 
presumed Quoted-printable.  They get fewer service calls by assuming the MIME 
headers are wrong than by honoring them.

Likewise an HP PostScript printer failed my text document that contained a 
quoted sample of PostScript code: Bayesian analysis said "PostScript", but the 
PostScript was invalid.

DWIM is too often a misapplication of Postel's Robustness Principle.

I need barely mention browsers' attempts to cover up HTML misconceptions such 
as .

-- gil


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

Re: SoftwareXcel Discontinued

[Paul Gilmartin]

On Fri, 8 Sep 2017 10:22:38 +1000, Andrew Rowley wrote:
>
>The bigger problem is when an organization views customer problem
>reports as something to be minimized (as opposed to actual problems).
> 
That's what I call "the Microsoft QA metric": the MTB calls to support.
I discovered this years ago when I emailed a colleague a JCL snippet
containing such as:
//  BLKSIZE=6144
... and he replied, "WTF 'BLKSIZEa44'?"  He had, foolishly IMO, configured
Word as his MS Exchange viewer.  I surmise MSW ignored my MIME header,
"Content-Transfer-Encoding: 7bit"; did a Bayesian analysis of the content;
and presumed Quoted-printable.  They get fewer service calls by assuming
the MIME headers are wrong than by honoring them.

Likewise an HP PostScript printer failed my text document that contained
a quoted sample of PostScript code: Bayesian analysis said "PostScript",
but the PostScript was invalid.

DWIM is too often a misapplication of Postel's Robustness Principle.

I need barely mention browsers' attempts to cover up HTML misconceptions
such as .

-- gil

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

Re: SoftwareXcel Discontinued

[Bill Johnson]

They don't build them using 6 sigma. It would put most dealers out of business.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2017, 9:03 PM, Gibney, Dave  wrote:

Auto "Makers" try to avoid shipping defective cars. Recalls can be expensive. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Johnson
> Sent: Thursday, September 07, 2017 5:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SoftwareXcel Discontinued
> 
> Auto dealers make tons of money fixing defective cars. All software
> companies charge for bug fixes. Some just hide it in the initial cost of the
> software.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Thursday, September 7, 2017, 7:04 PM, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 7 Sep 2017 18:16:34 -0400, Tom Conley wrote:
> 
> >On 9/7/2017 4:07 PM, Jim Mulder wrote:
> >>  With regard  to only the last sentence in Gord's comments,  those of
> >>us in z/OS development who put the bugs into the software  don't have
> >>anything to do with the IBM offerings for reporting bugs and
> >>obtaining fixes for the bugs.  So that does not play any part in  our
> >>decisions about how many bugs to include in the software.  :-)
> >>
> >> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> >> Poughkeepsie NY
> >
> >Laugh it up, furball.
> >
> That cynicism will predictably be aroused by any organization that accounts
> defect support as a profit center.  (I have no evidence that IBM does so.)
> 
> -- 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

--
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: SoftwareXcel Discontinued

[Edward Gould]

> On Sep 7, 2017, at 8:03 PM, Gibney, Dave  wrote:
> 
> Auto "Makers" try to avoid shipping defective cars. Recalls can be expensive. 


I wonder if IBM would accept a box of tapes with Z/os in it?
What would be funnier is to not attach postage and make IBM pay for it.

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

Re: SoftwareXcel Discontinued

[Edward Gould]

> On Sep 7, 2017, at 3:08 PM, Jim Mulder  wrote:
> 
> With regard  to only the last sentence in Gord's comments, 
> those of us in z/OS development who put the bugs into the software
> don't have anything to do with the IBM offerings for reporting bugs and
> obtaining fixes for the bugs.   So that does not play any part in 
> our decisions about how many bugs to include in the software.   :-)
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY

Jim,

So IBM admits to having bugs in their software? Then you should be paying the 
customer to find them for IBM.

Ed


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

Re: SoftwareXcel Discontinued

[Gibney, Dave]

Auto "Makers" try to avoid shipping defective cars. Recalls can be expensive. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Johnson
> Sent: Thursday, September 07, 2017 5:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SoftwareXcel Discontinued
> 
> Auto dealers make tons of money fixing defective cars. All software
> companies charge for bug fixes. Some just hide it in the initial cost of the
> software.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Thursday, September 7, 2017, 7:04 PM, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 7 Sep 2017 18:16:34 -0400, Tom Conley wrote:
> 
> >On 9/7/2017 4:07 PM, Jim Mulder wrote:
> >>  With regard  to only the last sentence in Gord's comments,  those of
> >>us in z/OS development who put the bugs into the software  don't have
> >>anything to do with the IBM offerings for reporting bugs and
> >>obtaining fixes for the bugs.  So that does not play any part in  our
> >>decisions about how many bugs to include in the software.  :-)
> >>
> >> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> >> Poughkeepsie NY
> >
> >Laugh it up, furball.
> >
> That cynicism will predictably be aroused by any organization that accounts
> defect support as a profit center.  (I have no evidence that IBM does so.)
> 
> -- 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

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

Re: SoftwareXcel Discontinued

[Bill Johnson]

Auto dealers make tons of money fixing defective cars. All software companies 
charge for bug fixes. Some just hide it in the initial cost of the software.


Sent from Yahoo Mail for iPhone


On Thursday, September 7, 2017, 7:04 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

On Thu, 7 Sep 2017 18:16:34 -0400, Tom Conley wrote:

>On 9/7/2017 4:07 PM, Jim Mulder wrote:
>>  With regard  to only the last sentence in Gord's comments,
>> those of us in z/OS development who put the bugs into the software
>> don't have anything to do with the IBM offerings for reporting bugs and
>> obtaining fixes for the bugs.  So that does not play any part in
>> our decisions about how many bugs to include in the software.  :-)
>>
>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
>> Poughkeepsie NY
>
>Laugh it up, furball.
> 
That cynicism will predictably be aroused by any organization that accounts
defect support as a profit center.  (I have no evidence that IBM does so.)

-- 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: SoftwareXcel Discontinued

[Andrew Rowley]

On 8/09/2017 9:55 AM, Paul Gilmartin wrote:


Development management, often impelled by schedules imposed by
Marketing, is apt to view defect response as competing for development
resource and, in defense, nurture those gatekeepers.

Other forms of QA also impact on development schedules. But I have no 
disagreement with the operation of L1 support etc. in principle. The 
problem is when they deny the existence of a problem and/or close 
problems prematurely to meet resolution targets. The greater the 
separation of L1 support from the developers, the less interest L1 
support have in improving the actual product.


The bigger problem is when an organization views customer problem 
reports as something to be minimized (as opposed to actual problems).


I am aware that problems get prioritized amongst a long list of other 
problems and features. If a problem is recorded and assigned a priority 
of "if we run out of other things to do" that's OK - at least someone 
has noted that it exists.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: SoftwareXcel Discontinued

[Paul Gilmartin]

On Fri, 8 Sep 2017 09:16:06 +1000, Andrew Rowley wrote:
>>
>As a vendor, I greatly appreciate customers who take the time to report
>bugs. It helps improve the software and helps me do my job. I suspect
>that most of the developers at IBM feel the same way.
>
>However, there are parts of IBM that view problem reports as a nuisance.
>They work very hard to close them before the developers see them. I
>suspect IBM developers don't realize how much time and effort it takes a
>customer to get a problem report past these gatekeepers before they see it.
> 
Development management, often impelled by schedules imposed by
Marketing, is apt to view defect response as competing for development
resource and, in defense, nurture those gatekeepers.

A suitably small organization can afford neither separation of developlent
and maintenance nor gatekeepers.

--gil

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

Re: SoftwareXcel Discontinued

[Steve Thompson]

Jim:

Now come on, fess up. When put that code there that way, it was 
for an undocumented feature.


Some undocumented features work better than others, but still...



Regards,
Steve Thompson

On 09/07/2017 04:08 PM, Jim Mulder wrote:

  With regard  to only the last sentence in Gord's comments,
those of us in z/OS development who put the bugs into the software
don't have anything to do with the IBM offerings for reporting bugs and
obtaining fixes for the bugs.   So that does not play any part in
our decisions about how many bugs to include in the software.   :-)
  
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.

Poughkeepsie NY



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

Re: SoftwareXcel Discontinued

[Andrew Rowley]

On 8/09/2017 5:02 AM, Gord Tomlin wrote:


Charging for the privilege of reporting bugs, and obtaining fixes for 
the bugs, puts the incentives for the charging vendor in the wrong 
place. It reduces the net cost to the vendor of handling defects, and 
transfers part of the financial impact of bugs from the vendor to the 
customers. It could be viewed as reducing the vendor's incentive to 
develop relatively bug-free software.


As a vendor, I greatly appreciate customers who take the time to report 
bugs. It helps improve the software and helps me do my job. I suspect 
that most of the developers at IBM feel the same way.


However, there are parts of IBM that view problem reports as a nuisance. 
They work very hard to close them before the developers see them. I 
suspect IBM developers don't realize how much time and effort it takes a 
customer to get a problem report past these gatekeepers before they see it.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: SoftwareXcel Discontinued

[Paul Gilmartin]

On Thu, 7 Sep 2017 18:16:34 -0400, Tom Conley wrote:

>On 9/7/2017 4:07 PM, Jim Mulder wrote:
>>   With regard  to only the last sentence in Gord's comments,
>> those of us in z/OS development who put the bugs into the software
>> don't have anything to do with the IBM offerings for reporting bugs and
>> obtaining fixes for the bugs.   So that does not play any part in
>> our decisions about how many bugs to include in the software.   :-)
>>
>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
>> Poughkeepsie NY
>
>Laugh it up, furball.
> 
That cynicism will predictably be aroused by any organization that accounts
defect support as a profit center.  (I have no evidence that IBM does so.)

-- gil

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

Re: SoftwareXcel Discontinued

[Lizette Koehler]

I think that this is awesome. I get to go Easter egg hunts (Bug hunts) for fun 
and giggles.

Thank you IBM very much

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Conley
> Sent: Thursday, September 07, 2017 3:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SoftwareXcel Discontinued
> 
> On 9/7/2017 4:07 PM, Jim Mulder wrote:
> >   With regard  to only the last sentence in Gord's comments, those of
> > us in z/OS development who put the bugs into the software don't have
> > anything to do with the IBM offerings for reporting bugs and
> > obtaining fixes for the bugs.   So that does not play any part in
> > our decisions about how many bugs to include in the software.   :-)
> >
> > Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> > Poughkeepsie NY
> >
> 
> Laugh it up, furball.
> 

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

Re: SoftwareXcel Discontinued

[Tom Conley]

On 9/7/2017 4:07 PM, Jim Mulder wrote:

  With regard  to only the last sentence in Gord's comments,
those of us in z/OS development who put the bugs into the software
don't have anything to do with the IBM offerings for reporting bugs and
obtaining fixes for the bugs.   So that does not play any part in
our decisions about how many bugs to include in the software.   :-)
  
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.

Poughkeepsie NY



Laugh it up, furball.

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

Re: SoftwareXcel Discontinued

[Gord Tomlin]

On 2017-09-07 16:08, Jim Mulder wrote:

With regard  to only the last sentence in Gord's comments,
those of us in z/OS development who put the bugs into the software
don't have anything to do with the IBM offerings for reporting bugs and
obtaining fixes for the bugs.   So that does not play any part in
our decisions about how many bugs to include in the software.:-)


Glad you picked up on the tongue in cheek! In real life, willfully being 
buggy would soon be followed by unwillingly being out of business.


--

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: SoftwareXcel Discontinued

[Jesse 1 Robinson]

I for one am grateful the bugs IBM inserts. If not for them, I would not have a 
job.  ;-))

.
.
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 Jim Mulder
Sent: Thursday, September 07, 2017 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SoftwareXcel Discontinued

 With regard  to only the last sentence in Gord's comments, those of us in z/OS 
development who put the bugs into the software don't have anything to do with 
the IBM offerings for reporting bugs and
obtaining fixes for the bugs.   So that does not play any part in 
our decisions about how many bugs to include in the software.   :-)
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> From: Gord Tomlin 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/07/2017 03:58 PM
> Subject: Re: SoftwareXcel Discontinued Sent by: IBM Mainframe 
> Discussion List 
> 
> On 2017-09-07 12:07, Ed Jaffe wrote:
> > We're a small shop. We *really* don't want to be paying thousands
every 
> > month just for the "privilege" of being able to report bugs with, 
> > and get fixes for, our non-Linux mainframe software. (IMHO such 
> > support ought to be included free as part of MLC and S payments, 
> > but that's
a 
> > discussion for another day...)
> 
> This is as good a day as any...
> 
> Charging for the privilege of reporting bugs, and obtaining fixes for 
> the bugs, puts the incentives for the charging vendor in the wrong 
> place. It reduces the net cost to the vendor of handling defects, and 
> transfers part of the financial impact of bugs from the vendor to the 
> customers. It could be viewed as reducing the vendor's incentive to 
> develop relatively bug-free software.
> 
> --
> 
> 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: SoftwareXcel Discontinued

[Gord Tomlin]

On 2017-09-07 12:07, Ed Jaffe wrote:
We're a small shop. We *really* don't want to be paying thousands every 
month just for the "privilege" of being able to report bugs with, and 
get fixes for, our non-Linux mainframe software. (IMHO such support 
ought to be included free as part of MLC and S payments, but that's a 
discussion for another day...)


This is as good a day as any...

Charging for the privilege of reporting bugs, and obtaining fixes for 
the bugs, puts the incentives for the charging vendor in the wrong 
place. It reduces the net cost to the vendor of handling defects, and 
transfers part of the financial impact of bugs from the vendor to the 
customers. It could be viewed as reducing the vendor's incentive to 
develop relatively bug-free software.


--

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: FTP JCL EXAMPLE - FTP PDS

[John McKown]

On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony  wrote:

>
> If you are transferring a PDS from one MVS LPAR to another and
> creating the target PDS, couldn't you use:
>
> mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate


​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
newest and greatest FTP commands. I need to go read the 2.3 books on that
to see what other goodies exist.​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: FTP JCL EXAMPLE - FTP PDS

[Cieri, Anthony]

If you are transferring a PDS from one MVS LPAR to another and creating 
the target PDS, couldn't you use:

mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'  
(REAllocate


  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, September 07, 2017 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP JCL EXAMPLE - FTP PDS

On Thu, Sep 7, 2017 at 11:47 AM, willie bunter < 
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> John,
>
> I am stuck again.  Would you have the parm when FTPing a PDS/PDSE?
>
> I tried the following:
>
>  QUOTE SITE PRI=50 SEC=20 CYL
>  MPUT 'FTP.V8050.MVS.BUILDJCL(*)' +
>   'DRP.V8050.MVS.BUILDJCL.NEW'
>  QUIT
>
>
​That MPUT command just looks "wrong" to me. I am assuming that you want to 
send all the members in FTP.V8050.MVS.BUILDJCL to a new PDSE called 
DRP.V8050.MVS.BUILDJCL.NEW. What I think you need is akin to:


-- use the next two if transferring within same z/OS system (don't key in this 
line) quote site pri=50 sec=20 cyl mkdir 'DRP.V8050.MVS.BUILD.JCL.NEW' (like 
'FTP.V8050.MVS.BUILDJCL
-- or use the next two if the receiving dataset is on a different z/OS system 
(don't key in this line) quote site lrecl=? recfm=? pri=50 sec=20 cyl dir=100 
pdstype=pdse mkdir 'DRP.V8050.MVS.BUILD.JCL.NEW'​
​-- common commands (don't key in this line) cd 'DRP.V8050.MVS.BUILD.JCL.NEW'
lcd 'FTP.V8050.MVS.BUILDJCL'
prompt
mput *
bye

You can use the first "quote & mkdir" lines - the one with the "(like ..."
- only if the FTP.--- DSN is on the system from which you are doing the ftp, 
which is not likely. If you're sending from one z/OS to another, then use the 
"quote site" and the second "mkdir"​. You must use the "cd" command to direct 
the output into the DRP.--- dataset. You must use the "lcd"
command to read the member from the FTP.--- dataset. I put in the "prompt"
command to disable the normal prompt for confirming the transfer of each 
member. The "mput *' actually transfer the members from the FTP.--- to the
DRP.--- dataset.


--
UNIX was not designed to stop you from doing stupid things, because that would 
also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

--
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: FTP JCL EXAMPLE - FTP PDS

[John McKown]

On Thu, Sep 7, 2017 at 11:47 AM, willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> John,
>
> I am stuck again.  Would you have the parm when FTPing a PDS/PDSE?
>
> I tried the following:
>
>  QUOTE SITE PRI=50 SEC=20 CYL
>  MPUT 'FTP.V8050.MVS.BUILDJCL(*)' +
>   'DRP.V8050.MVS.BUILDJCL.NEW'
>  QUIT
>
>
​That MPUT command just looks "wrong" to me. I am assuming that you want to
send all the members in FTP.V8050.MVS.BUILDJCL to a new PDSE called
DRP.V8050.MVS.BUILDJCL.NEW. What I think you need is akin to:


-- use the next two if transferring within same z/OS system (don't key in
this line)
quote site pri=50 sec=20 cyl
mkdir 'DRP.V8050.MVS.BUILD.JCL.NEW' (like 'FTP.V8050.MVS.BUILDJCL
-- or use the next two if the receiving dataset is on a different z/OS
system (don't key in this line)
quote site lrecl=? recfm=? pri=50 sec=20 cyl dir=100 pdstype=pdse
mkdir 'DRP.V8050.MVS.BUILD.JCL.NEW'​
​-- common commands (don't key in this line)
cd 'DRP.V8050.MVS.BUILD.JCL.NEW'
lcd 'FTP.V8050.MVS.BUILDJCL'
prompt
mput *
bye

You can use the first "quote & mkdir" lines - the one with the "(like ..."
- only if the FTP.--- DSN is on the system from which you are doing the
ftp, which is not likely. If you're sending from one z/OS to another, then
use the "quote site" and the second "mkdir"​. You must use the "cd" command
to direct the output into the DRP.--- dataset. You must use the "lcd"
command to read the member from the FTP.--- dataset. I put in the "prompt"
command to disable the normal prompt for confirming the transfer of each
member. The "mput *' actually transfer the members from the FTP.--- to the
DRP.--- dataset.


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: FTP JCL EXAMPLE - FTP PDS

[willie bunter]

John,

I am stuck again.  Would you have the parm when FTPing a PDS/PDSE?

I tried the following:

 QUOTE SITE PRI=50 SEC=20 CYL  
 MPUT 'FTP.V8050.MVS.BUILDJCL(*)' +  
  'DRP.V8050.MVS.BUILDJCL.NEW'   
 QUIT  


On Fri, 9/1/17, John McKown  wrote:

 Subject: Re: FTP JCL EXAMPLE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, September 1, 2017, 11:27 AM
 
 On Fri, Sep 1, 2017 at 10:19 AM,
 willie bunter <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 > Good Day To
 All,
 >
 >      I am
 trying to FTP a dsn of 90 cylinders from one MAINFRAME Lpar
 to
 > another.  The FTP function is
 unsuccessful because of a space abend.
 >
 > Would anybody have an
 example of how to code the space parm in the FTP
 > batch job?
 >
 > I thought about pre-allocation the dsn on
 the target LPAR.  This works
 > however
 because of other dsns which will be FTP'd, the size of
 the dsns are
 > not known because the
 application batch jobs are run overnight.
 >
 > I looked at IBM
 KNOWLEDGE CENTER but I couldn't find anything that
 would
 > satisfy my  requirement.
 >
 > Here is my
 batchjob.  Please note I blanked out the IP address.
 >
 > //STEPFTP  EXEC
 PGM=FTP,REGION=4096K,TIME=5,
 > //
 PARM='1XX.1XX.XX.XXX
 > //SYSPRINT DD
 SYSOUT=*
 > //OUTPUT   DD SYSOUT=*
 > //INPUT      DD *
 >  O00070 PASSWORD
 >
 
 ​QUOTE SITE PRI=20 SEC=20
 CYL​
 
 
 
 >  PUT 'O00070.OTTCAUDR.AUDITLOG'
 +
 >      
 'O00070.OTTCAUDR.AUDITLOG'
 > 
 QUIT
 > /*
 > //
 >
 > Thanks.
 >
 
 ​The
 QUOTE SITE above is equivalent to SPACE=(CYL,(20,20))​. Of
 course,
 this is a "hard coded"
 value which may be too large for some DSNs and not
 large enough for others. If you need something
 which "dynamically adjusts"
 the
 values, then you'll need to do more work. FTP itself
 cannot do this for
 you.
 
 
 -- 
 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

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

SoftwareXcel Discontinued

[Ed Jaffe]

On Aug 8, 2017 IBM announced they are withdrawing the following offerings:

SoftwareXcel Basic Edition (6942-77G)
SoftwareXcel Enterprise Edition (6942-77E)
Alert for zSeries (6942-16D)
Resolve for zSeries (6942-23D)

replacing them with:

z Systems Premier Software Care (6950-07W)
z Systems Premier Software Care - Alert and Resolve (6948-53Z)

We use SoftwareXcel Basic Edition today and our contract is up for 
renewal at the end of the year.


What scares me is IBM won't even tell us how much "z Systems Premier 
Software Care" will cost. That fear is fueled by the observation that 
the same replacement offering applies to both existing SoftwareXcel 
Basic Edition and Enterprise Edition customers! Yikes!!!


We're a small shop. We *really* don't want to be paying thousands every 
month just for the "privilege" of being able to report bugs with, and 
get fixes for, our non-Linux mainframe software. (IMHO such support 
ought to be included free as part of MLC and S payments, but that's a 
discussion for another day...) Currently, SoftwareXcel Basic is ~$300/mo 
per userid. We have only one...


Bracing for impact (not unlike some Floridians I know)...

--
Phoenix Software International
Edward E. Jaffe
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: 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: IEAARR

[Peter Relson]

I think these two separated points from the same post are to some extent 
in
conflict. If the only documentation of an interface is the macro that
invokes it ...

I do not see a conflict..

I did not say that the macro is the documentation. I said that the book is 
the documentation.
The fact that mappings might be available for parameter lists often does 
not mean that that mapping is intended for you to use to build your own. 
For example, it might be intended for the macro to use and rely upon, or 
it might be provided for diagnostic reasons.

And the change for which I gave an example that would break misuse of an 
interface did not involve recompilation. But it was incompatible if you 
did not follow the documented rules. We do not, in general, ever expect to 
get the user community to recompile. And as a result you can be quite 
confident (in the absence of documentation to the contrary such as 
migration information about an incompatibility) that if you mimic the 
expansion exactly (by whatever mechanism you do so), you will have 
something that works and continues to work.

Peter Relson
z/OS Core Technology Design


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

[Rob Scott]

I would change that third sentence to :

"You can demand that your macro *is* the interface, but that implies you 
require your clients to re-assemble their code whenever they want to utilize 
any of the *real* interface changes"

Any interface worth its salt would support previously assembled code that is 
ignorant of the new parameter list bits and bytes.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Thursday, September 7, 2017 1:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEAARR

The crux of the matter is that an interface must be defined at the execution 
level.  Macros are ephemeral, merely a convenience. You can demand that your 
macro *is* the interface, but that implies you require your clients to 
re-assemble their code whenever the *real* interface changes.  Not so good from 
a customer-service (or
profit-making) perspective.

Some macros are more convenient for my purposes than others.  C'est la vie.

--
sas

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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