Cheryl;
Thanks for writing back.
As usual, I have a lot to say, so I'll start with a summary:
A pandemic and potential economic crisis (May Oil futures went negative and
hit -$40/barrel yesterday for the first time ever) is not the time for IBM
to be maximizing only shareholder value. (Disclosure: I own 118 shares,
this date.)
In its March 2nd, 2020 podcast, Marketplace (add Kai Ryssdal if you search)
reporting on the passing of Jack Walsh, noted how Mr. Walsh changed his
approach in later years, when GE got into trouble, to one that took more
stakeholders into account. The podcast goes on to note how "leading groups
including the Business Round Table, Black Rock, and the Davos World
Economic Forum are rethinking the shareholders first model and it's
limitations." In other words, employees, customers, suppliers and society
in general need to be taken into account. You can't pollute a stream,
especially if you know your downstream neighbors get their drinking water
from it. We are seeing everyone, except IBM and some large restaurant
chains, doing their part. Some landlords are waiving rent and food pantry
have mile long lines.
The logic behind holding back the TSO PIPE command defies all reason. If
it is related to the "Unbundling" Consent Decree circa 1970, then surely
the DOJ could be persuaded to revisit the issue, if not because the
behemoths Microsoft, Amazon, Netflix, Google, Intel, China Inc., etc.
preclude any renewal of monopolistic behavior by IBM, then perhaps because
of the economic risks of not doing so. At least the Decree could be
suspended until the crisis abates. If the holding back TSO PIPEs is
because IBM fears the loss of business, consider that USS would be a
gateway to z/OS because TSO PIPEs is roughly an order of magnitude faster
than UNIX-style piping. Whether or not the Watson A.I. is written in
Pipes, it needs to be out there on the off chance that it will mitigate the
crisis, get people their unemployment checks faster, help find a cure or
treatment, improve testing and contract tracing, AND/or find better ways to
objectively quantify essential businesses and/or contagion control
techniques. Just the good press would be more than worth it.
The co-marketing of BatchPipes and the TSO PIPE command (a.k.a
BatchPipesWorks) was a huge mistake. The functionalities completely
different: The TSO PIPE command allows an essentially unlimited number of
filters to operate on the same in-memory copy of a record. The BatchPipes
inter-JOB record passing only works between one step of emitting JOBs and
one step of receiver JOBs. The other steps must execute first or wait to
run after. I know of one bank that dropped (JOB-TO-JOB) BatchPipes because
restarts were so problematic. Of course the choice of names doesn't help;
confusion abounds when talking about the two 99% unrelated pieces of
software, BatchPipes and the TSO PIPE command. I've heard sysprogs use the
term BagPipes presumably because the software is so difficult to operate.
(I would not be surprised if there were more to the analogy than was
shared.)
I was astonished to hear that IBM is giving free COBOL training and that US
State governments are struggling to find COBOL programmers. Why? Because
COBOL IS THE PROBLEM! How can you identify a bottleneck when you can't see
the forest for the trees? Not adding more trees. What follows is a
skeleton example, reading a dataset/file:
In COBOL and JCL:
//INPUT DD DISP=SHR,DSN=APPHLQ.QUAL2.TYPE
ASSIGN ,,,
FD …
...
PERFORM UNTIL EOF
READ ...
AT END …
IF NOT EOF PERFORM
…
END-PERFORM
END-PERFORM.
In REXX/TSO:
“alloc …”
“execio …”
"free ..."
In Pipes, UNIX/Linux/USS:
< apphlq.qual2.type
Anyone who is more than a casual user of CMS/TSO PIPEs gets really excited
about it. Frequently, they can't communicate why. I reminds me of an
early exposure to REXX, around 1990, before it joined the z/OS base. The
guy was so excited about REXX as a fantastic programming language that I
thought he was a little off. Now, with experience and knowing that there
are about 20 unique things about REXX, any of which applies to only a few
other programming languages and none has them all or even most, I think he
understated the case.
The same is true for the TSO PIPEs command. It will eventually be part of
the z/OS base because it belongs there and has to be there. Without the
PIPE command z/OS is just OS/360 with a few bells and whistles tacked on.
On to your note, Cheryl.
On Sun, Apr 19, 2020 at 3:45 PM Cheryl Watson Walker <
che...@watsonwalker.com> wrote:
> Hi Hobart,
>
>
>
> I’m sorry that I’ve been unable to help you with your SHARE requirement. I
> have been overloaded with work and some personal issues. I wasn’t even able
> to attend the Requirements call when it was discussed. But I **do** know
> that the requirement is unlikely to get any IBM support, and I’m pretty
> sure that it will be rejected. They have a limited staff these days (their
> unfortunate decision in my mind) and almost nobody left in the REXX/TSO
> areas.
>
Even an old version of the TSO PIPE command would be a fantastic
improvement. It is my understanding, from various sources, that CMS
Pipelines has (almost) always been ready to run on TSO, with only trivial
changes. John Hartmann's Author's Edition on Pipelines specifically
documents the few builtin stages that are not available on TSO such as
READER and PUNCH. It also describes the stages that are only available
under TSO.
>
>
> I also was not able to help you with even your first draft because this is
> way over my head. I know that I’ve heard people say that pipes are
> wonderful and I also know that several people tried to get IBM to stop
> charging for BatchPipes, so I was supporting of you trying to get a SHARE
> requirement. But again, I could not begin to help you make it more concise
> because I don’t fundamentally understand pipes and haven’t programmed in 30
> years.
>
I'd be happy if IBM kept charging for BatchPipes. It's just the TSO PIPE
command that needs to be free.
>
>
> I think that SHARE should follow its normal policy and open it for voting
> to see what current feelings are at the time. Other hot spots have come up.
> If IBM doesn’t accept it, then I think you should post it as a regular RFE
> and post something on IBM-Main that asks people to go vote on it like
> Lionel does.
>
Good idea. However, Mike seems like a nice guy caught between a rock and a
hard place. I'm not sure he or SHARE should be subjected to any resulting
blow-back.
>
>
> I would NOT try to sell it using assertions that COVID-19 victims would
> sue IBM. That will not will you any supporters. I recently tried to talk
> IBM management in extending the EOS dates for COBOL V5 and z/OS 2.2 due to
> the hardships of COVID-19 and hit a brick wall. And that wouldn’t have cost
> them anything! Frank used to tell me that it could take a year to get a
> decision changed in IBM, and I feel that he’s right. It’s quite frustrating
> for us too.
>
Yes, my statement was a mistake. The pandemic, economic impacts,
isolation, and extra protection measures may have resulted in a temporary
lapse of judgement. Then there is IBM's lame excuse for not doing the
right thing. Considering that it's been almost 3 decades since i first
submitted this kind of request, I guess it's at least 25 years overdue.
Given that, I'm adding IBM-MAIN to the cc: list.
>
>
> The only other thing I would try is to make a much smaller requirement
> that simply asks for BatchPipeWorks to be made available separately at
> no-charge. Knowing IBM, that will be rejected as well.
>
Gee. I thought that what I was doing. You do make my point about the
confusing names.
>
>
> I’m sorry that I haven’t been able to help you with this. I hope you’re
> staying safe and healthy.
>
No apologies necessary. If you know anyone who can help, please get us in
contact or share this email.
>
>
> Best regards,
>
> Cheryl
>
>
>
> ===========================
>
> Cheryl Watson
>
> Watson & Walker, Inc.
>
> 1661 Ringling Blvd, PMB 49886
>
> Sarasota, FL 34230
>
> Text/cell: 941-266-6609
>
> www.watsonwalker.com
>
> ===========================
>
>
>
>
>
> *From:* Hobart Spitz <orexx...@gmail.com>
> *Sent:* Sunday, April 12, 2020 8:28 AM
> *To:* Rob van der Heij <rvdh...@gmail.com>; Cheryl Watson <
> che...@watsonwalker.com>
> *Subject:* Fwd: SHARE requirement Address Temporary Dataset and USS
> Piping Issues
>
>
>
>
> OREXXMan
>
> JCL is the buggy whip of 21st century computing. Stabilize it.
>
> Put Pipelines in the z/OS base. Would you rather process data one
> character at a time (Unix/C style), or one record at a time?
>
> IBM has been looking for an HLL for program products; REXX is that
> language.
>
>
>
> ---------- Forwarded message ---------
> From: *Hobart Spitz* <orexx...@gmail.com>
> Date: Sun, Apr 12, 2020 at 7:27 AM
> Subject: Re: SHARE requirement Address Temporary Dataset and USS Piping
> Issues
> To: Mike Shorkend <mike.shork...@gmail.com>
>
>
>
> Mike;
>
>
>
> I'll try to make this brief. I will make it polite, since I don't know
> you. The IBM guy is giving you bad information either out of ignorance, an
> illegitimate agenda, or both. He should be ashamed and embarrassed for
> even suggesting such things. I apologize to you on his behalf for his
> misleading you. I was level III support for CMS Pipes, and have used both
> TSO Pipes, and BatchPipes I know what I am talking about.
>
> - The premises are false. BatchPipes and BatchPipesWorks are two 99%
> unrelated products that should never have been marketed together. It was
> like putting a Denver boot* (JOB-to-JOB piping) *on a sports car *(CMS/TSO
> PIPEs)* and charging extra for the boot. *(Italics added later.)*
> Making TSO Pipelines, the more current product, available for free is the
> reverse of a non-starter; it has no licencing relationship to BatchPipes.
> Since BatchPipesWorks was marketed as an add-on (accepting the first false
> premise) there is no marketing or licencing reason for making just the
> "minor" add-on available for free in its current form.
> - It's not a binary choice. There are other options than you have
> listed, specifically what's listed in the RFE.
> - The RFE elements (temporary datasets and USS piping) as written are
> not addressed by either of the options presented by your question.
> - Making TSO Pipelines part of the z/OS base would increase the market
> for BatchPipes, by getting customers familiar with the concepts and giving
> them the knowledge and experience to understand what inter-JOB piping can
> do.
> - If IBM can't support this RFE for the many business reasons that it
> should, then it should do so for foisting such closed, unproductive
> technologies as JCL, COBOL, and USS on customers who now have
> unmaintainable, underperforming systems that are failing under the enormous
> loads that they could never have been written to handle... unless
> Pipelines had been available.
> - This is a time of global health and economic emergencies. IBM must
> do it for the patients who have died and those that may, for their
> families, for the first responders who have gotten sick and those that
> might, for the unemployed workers already living paycheck to paycheck who
> can't pay their bills and those that might be in the same situation, and
> for the children who have or will hungry all because some piece of
> information didn't arrive on time due to an out of date IBM product or
> system. State, national and other governments and organizations are
> failing their citizens because systems are not what they could and should
> be.
> - Does IBM really want to be sued by the victims of COVID-19 and the
> economic calamity that may be on the horizon?
>
> Any one of the reasons I mentioned are sufficient to open the most
> requested RFE for voting as is. Together, they are compelling
> technologically, logically, economically, compassionately, and for
> humanitarian reasons. Don't let anyone get in the way of your doing what's
> right, least of all someone who doesn't know what they are talking about.
>
>
>
> At this time IBM must put aside all other considerations and instead
> recognize all stakeholders as any responsible corporate citizen will.
> There is no excuse to debate this any further.
>
>
>
> Thanks.
>
>
>
> - Hobart
>
>
>
>
>
> On Thu, Apr 9, 2020 at 1:54 AM Mike Shorkend <mike.shork...@gmail.com>
> wrote:
>
> Hi Hobart
>
> We discussed your requirement at our monthly requirements meeting.
>
> One of the IBM guys that attends these meetings pointed out that if you
> are asking for pipes as a charge free feature, then this requirement is a
> non-starter as BatchPipes provides some of the functionality as a licensed
> product.
>
>
>
> If you asking enhancements for BatchPipes, that is a different story.
>
>
>
> So which is it?
>
>
>
> Thanks
>
>
>
> Mike
>
>
>
> On Sun, 29 Mar 2020 at 08:49, Mike Shorkend <mike.shork...@gmail.com>
> wrote:
>
> Let me get back to you on this.
>
>
>
> Thanks
>
>
>
>
>
> On Fri, 27 Mar 2020 at 18:30, Hobart Spitz <orexx...@gmail.com> wrote:
>
> I know this is obvious to an experienced requirements person, but would it
> be better to shorten (etc.) it now, or wait for the feedback?
>
>
> OREXXMan
>
> JCL is the buggy whip of 21st century computing. Stabilize it.
>
> Put Pipelines in the z/OS base. Would you rather process data one
> character at a time (Unix/C style), or one record at a time?
>
> IBM has been looking for an HLL for program products; REXX is that
> language.
>
>
>
>
>
> On Fri, Mar 27, 2020 at 3:11 AM Mike Shorkend <mike.shork...@gmail.com>
> wrote:
>
> Thanks for your understanding. I will bring it up at our meeting and we
> will get back to you
>
>
>
> Mike
>
>
>
> On Thu, 26 Mar 2020, 19:21 Hobart Spitz, <orexx...@gmail.com> wrote:
>
> Mike;
>
>
>
> No prob. I feel the same. I cut it down from 8 pages. No offense taken
> whatsoever.
>
>
>
> I've done very few requirements on my own, none successful. I've had two
> ideas implemented that were written up by others. (BUFSIZE defaulting to
> largest known BLKSIZE, and no QSAM output to PDS directory.) I'm happy to
> consider any and all editorial (or other) suggestions. If you are unable
> provide specific guidance, please suggest some who can. If someone is
> willing to do more, like edit it, that might be the best way to ensure
> success.
>
>
>
> Satisfying this need is my only goal here.
>
>
>
> Thanks for writing.
>
>
>
> - Hobart
>
> 443-297-7879
>
> On Thu, 26 Mar 2020, 11:37 am Mike Shorkend, <mike.shork...@gmail.com>
> wrote:
>
> Hi Hobart
>
> I do MVSE requirements for SHARE
>
> I have not moved your requirement to voting yet because I would like to
> discuss it at the monthly meeting we have for requirements, scheduled for
> April 8th.
>
> I have heard some concerns that while the requirement is a valid one, the
> style and length you used might not be the best to promote this
> requirement. No offense intended.
>
>
>
> Stay safe
>
>
>
> Mike Shorkend
>
>
>
>
>
>
>
>
>
> --
>
> Mike Shorkend
> m...@shorkend.com
> www.shorkend.com
> Tel: +972524208743
> Fax: +97239772196
>
>
>
> --
>
> Mike Shorkend
> m...@shorkend.com
> www.shorkend.com
> Tel: +972524208743
> Fax: +97239772196
>
>
>
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
