Discussion:
[TSO-REXX] Fwd: Pipelines in the z/OS base.
Add Reply
Paul Gilmartin
2017-11-16 18:11:47 UTC
Reply
Permalink
Raw Message
The early versions of UNIX were written on small machines (32K?!), with
slow/small disk drives. Writing temporary results out to disk was too slow
and inefficient, so they came up a pipe operator ( | ), which connected
the input of one command to the output of the previous one, thus avoiding
physical I/O.. E.g. *ls | wc*. The data passed thru an in-memory buffer
with both commands running, and UNIX dispatching each as needed. It also
allowed intermediate results to be very much larger than the available disk
space, since those intermediate results didn't have to be written to disk.
Sometimes. Otherwise, in those early days, real memory was often the
constraining factor so the piped implementation had performance inferior to
using a temporary file because of paging overhead.
... The original questioner thought
I was pulling his leg (since one could do that with a single character in
UNIX) and he had left before I was done.
Yup. Pipelines is not quite so terse.
UNIX: foo <file1 | bar >file2
Pipelines: PIPE < file1 | foo | bar | > file2
If you have any doubt about the usefulness of Pipes, take a poll of your
z/VM friends. They would tell you that they couldn't live without Pipes,
not because z/VM otherwise lacks anything, but because Pipes is so powerful
and efficient.
Not entirely true. CMS is grievously deficient in any support for concurrency.
In consequence, any CMS command stage suspends the entire remainder of the
pipeline while the CMS stage runs. So, Piplines reinvented many of the classic
CMS wheels (it often did better). I hope pipelines on z/OS can employ ATTACH
to avoid such redundancy.

CMS pipelines is not well integrated with classic CMS commands. While the
output of a CMS command can be connected to a Pipeline stage, a Pipeline
stage can not be connected to the input of a CMS command.

A question I have often asked, and usually been misunderstood is, "Can a
Pipeline be connected to a DDNAME of a classic z/OS utility?"
"Sure, Pipelines has a DD driver." answers a different question. That assumes
that DD has been ALLOCATEd to a data set. But how can I connect a Pipeline
to SYSUT1 or SYSUT2 of a classic command? I imagine the recherché approach:

SYSCALL pipe
connect a Pipeline to the input descriptor of the pipe.
BPXWDYN ALLOC SYSUT1 to the output descriptor of the pipe
SYSCALL pipe
BPXWDYN ALLOC SYSUT2 to the input descriptor of that pipe
connect a pipeline to the output descriptor of that pipe
somehow invoke a utility.

I suppose that could all be encapsulated in a Rexx stage. OS/360
had a design integrity with I/O abstraction better than that of CMS.
I hope Pipelines for z/OS doesn't ignore that.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-11-16 21:29:09 UTC
Reply
Permalink
Raw Message
Not sure where this fits in to the discussion, but Netview System Automation has a built-in pipes function. So we see messages like these:

AOF570I 00:39:48 : ISSUED "PIPE SAFE AOFMSAFE | EDIT /AFTER
00:00:03,MVS $A/ N JOBNUM N /;S/ N JOBNUM N | NETVIEW" FOR
MVSESA MVSESA - MSGTYPE IS $HASP100

AOF570I 01:04:11 : ISSUED "PIPE SAFE AOFMSAFE | EDIT FWDLINE 1
PARSE /,/ SKIPTO /DSNAME=/ W1 SUBSTR 8.* WL | EDIT /MVS S
DB2ALOG,ALOG=/ N W1 N | LOGTO NETLOG | NETV" FOR SUBSYSTEM
DA20MSTR - MSGTYPE IS DSNJ003I

I'm not an SA guy, so I can't comment on the function in any detail. Just pointing out that it's included with the product on z/OS.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, November 16, 2017 10:13 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
The early versions of UNIX were written on small machines (32K?!),
with slow/small disk drives. Writing temporary results out to disk
was too slow and inefficient, so they came up a pipe operator ( | ),
which connected the input of one command to the output of the previous
one, thus avoiding physical I/O.. E.g. *ls | wc*. The data passed
thru an in-memory buffer with both commands running, and UNIX
dispatching each as needed. It also allowed intermediate results to
be very much larger than the available disk space, since those intermediate results didn't have to be written to disk.
Sometimes. Otherwise, in those early days, real memory was often the constraining factor so the piped implementation had performance inferior to using a temporary file because of paging overhead.
... The original questioner thought
I was pulling his leg (since one could do that with a single character
in
UNIX) and he had left before I was done.
Yup. Pipelines is not quite so terse.
UNIX: foo <file1 | bar >file2
Pipelines: PIPE < file1 | foo | bar | > file2
If you have any doubt about the usefulness of Pipes, take a poll of
your z/VM friends. They would tell you that they couldn't live
without Pipes, not because z/VM otherwise lacks anything, but because
Pipes is so powerful and efficient.
Not entirely true. CMS is grievously deficient in any support for concurrency.
In consequence, any CMS command stage suspends the entire remainder of the pipeline while the CMS stage runs. So, Piplines reinvented many of the classic CMS wheels (it often did better). I hope pipelines on z/OS can employ ATTACH to avoid such redundancy.

CMS pipelines is not well integrated with classic CMS commands. While the output of a CMS command can be connected to a Pipeline stage, a Pipeline stage can not be connected to the input of a CMS command.

A question I have often asked, and usually been misunderstood is, "Can a Pipeline be connected to a DDNAME of a classic z/OS utility?"
"Sure, Pipelines has a DD driver." answers a different question. That assumes that DD has been ALLOCATEd to a data set. But how can I connect a Pipeline to SYSUT1 or SYSUT2 of a classic command? I imagine the recherché approach:

SYSCALL pipe
connect a Pipeline to the input descriptor of the pipe.
BPXWDYN ALLOC SYSUT1 to the output descriptor of the pipe
SYSCALL pipe
BPXWDYN ALLOC SYSUT2 to the input descriptor of that pipe
connect a pipeline to the output descriptor of that pipe
somehow invoke a utility.

I suppose that could all be encapsulated in a Rexx stage. OS/360 had a design integrity with I/O abstraction better than that of CMS.
I hope Pipelines for z/OS doesn't ignore that.

-- gil


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Horein
2017-11-16 23:25:11 UTC
Reply
Permalink
Raw Message
Those are NetView PIPEs that your Automation admins happen to take
advantage of.
In other words, you don't need SA to perform the same type of
functionality, just NetView.
I am happy I grew up with TSO Rexx, happier now that I can expand
capability with NetView Rexx.

Other "native" NetView PIPEs:
https://www.ibm.com/support/knowledgecenter/SSZJDU_6.2.1/com.ibm.itnetviewforzos.doc_6.2.1/dqs_cst.htm


Porting the NetView functionality into TSO would be a nice enhancement, if
ever done.
Post by Jesse 1 Robinson
Not sure where this fits in to the discussion, but Netview System
AOF570I 00:39:48 : ISSUED "PIPE SAFE AOFMSAFE | EDIT /AFTER
00:00:03,MVS $A/ N JOBNUM N /;S/ N JOBNUM N | NETVIEW" FOR
MVSESA MVSESA - MSGTYPE IS $HASP100
AOF570I 01:04:11 : ISSUED "PIPE SAFE AOFMSAFE | EDIT FWDLINE 1
PARSE /,/ SKIPTO /DSNAME=/ W1 SUBSTR 8.* WL | EDIT /MVS S
DB2ALOG,ALOG=/ N W1 N | LOGTO NETLOG | NETV" FOR SUBSYSTEM
DA20MSTR - MSGTYPE IS DSNJ003I
I'm not an SA guy, so I can't comment on the function in any detail. Just
pointing out that it's included with the product on z/OS.
.
.
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
-----Original Message-----
Behalf Of Paul Gilmartin
Sent: Thursday, November 16, 2017 10:13 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
The early versions of UNIX were written on small machines (32K?!),
with slow/small disk drives. Writing temporary results out to disk
was too slow and inefficient, so they came up a pipe operator ( | ),
which connected the input of one command to the output of the previous
one, thus avoiding physical I/O.. E.g. *ls | wc*. The data passed
thru an in-memory buffer with both commands running, and UNIX
dispatching each as needed. It also allowed intermediate results to
be very much larger than the available disk space, since those
intermediate results didn't have to be written to disk.
Sometimes. Otherwise, in those early days, real memory was often the
constraining factor so the piped implementation had performance inferior to
using a temporary file because of paging overhead.
... The original questioner thought
I was pulling his leg (since one could do that with a single character
in
UNIX) and he had left before I was done.
Yup. Pipelines is not quite so terse.
UNIX: foo <file1 | bar >file2
Pipelines: PIPE < file1 | foo | bar | > file2
If you have any doubt about the usefulness of Pipes, take a poll of
your z/VM friends. They would tell you that they couldn't live
without Pipes, not because z/VM otherwise lacks anything, but because
Pipes is so powerful and efficient.
Not entirely true. CMS is grievously deficient in any support for concurrency.
In consequence, any CMS command stage suspends the entire remainder of the
pipeline while the CMS stage runs. So, Piplines reinvented many of the
classic CMS wheels (it often did better). I hope pipelines on z/OS can
employ ATTACH to avoid such redundancy.
CMS pipelines is not well integrated with classic CMS commands. While the
output of a CMS command can be connected to a Pipeline stage, a Pipeline
stage can not be connected to the input of a CMS command.
A question I have often asked, and usually been misunderstood is, "Can a
Pipeline be connected to a DDNAME of a classic z/OS utility?"
"Sure, Pipelines has a DD driver." answers a different question. That
assumes that DD has been ALLOCATEd to a data set. But how can I connect a
Pipeline to SYSUT1 or SYSUT2 of a classic command? I imagine the recherché
SYSCALL pipe
connect a Pipeline to the input descriptor of the pipe.
BPXWDYN ALLOC SYSUT1 to the output descriptor of the pipe
SYSCALL pipe
BPXWDYN ALLOC SYSUT2 to the input descriptor of that pipe
connect a pipeline to the output descriptor of that pipe
somehow invoke a utility.
I suppose that could all be encapsulated in a Rexx stage. OS/360 had a
design integrity with I/O abstraction better than that of CMS.
I hope Pipelines for z/OS doesn't ignore that.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Nims,Alva John , Al
2017-11-17 15:07:31 UTC
Reply
Permalink
Raw Message
Thank you for "PIPing" up on this! :)

One thing to note, the PIPE command is part of the Base NetView product, you do not have to add SA to get it.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, November 16, 2017 4:30 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Not sure where this fits in to the discussion, but Netview System Automation has a built-in pipes function. So we see messages like these:

AOF570I 00:39:48 : ISSUED "PIPE SAFE AOFMSAFE | EDIT /AFTER
00:00:03,MVS $A/ N JOBNUM N /;S/ N JOBNUM N | NETVIEW" FOR
MVSESA MVSESA - MSGTYPE IS $HASP100

AOF570I 01:04:11 : ISSUED "PIPE SAFE AOFMSAFE | EDIT FWDLINE 1
PARSE /,/ SKIPTO /DSNAME=/ W1 SUBSTR 8.* WL | EDIT /MVS S
DB2ALOG,ALOG=/ N W1 N | LOGTO NETLOG | NETV" FOR SUBSYSTEM
DA20MSTR - MSGTYPE IS DSNJ003I

I'm not an SA guy, so I can't comment on the function in any detail. Just pointing out that it's included with the product on z/OS.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, November 16, 2017 10:13 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
The early versions of UNIX were written on small machines (32K?!),
with slow/small disk drives. Writing temporary results out to disk
was too slow and inefficient, so they came up a pipe operator ( | ),
which connected the input of one command to the output of the previous
one, thus avoiding physical I/O.. E.g. *ls | wc*. The data passed
thru an in-memory buffer with both commands running, and UNIX
dispatching each as needed. It also allowed intermediate results to
be very much larger than the available disk space, since those intermediate results didn't have to be written to disk.
Sometimes. Otherwise, in those early days, real memory was often the constraining factor so the piped implementation had performance inferior to using a temporary file because of paging overhead.
... The original questioner thought
I was pulling his leg (since one could do that with a single character
in
UNIX) and he had left before I was done.
Yup. Pipelines is not quite so terse.
UNIX: foo <file1 | bar >file2
Pipelines: PIPE < file1 | foo | bar | > file2
If you have any doubt about the usefulness of Pipes, take a poll of
your z/VM friends. They would tell you that they couldn't live
without Pipes, not because z/VM otherwise lacks anything, but because
Pipes is so powerful and efficient.
Not entirely true. CMS is grievously deficient in any support for concurrency.
In consequence, any CMS command stage suspends the entire remainder of the pipeline while the CMS stage runs. So, Piplines reinvented many of the classic CMS wheels (it often did better). I hope pipelines on z/OS can employ ATTACH to avoid such redundancy.

CMS pipelines is not well integrated with classic CMS commands. While the output of a CMS command can be connected to a Pipeline stage, a Pipeline stage can not be connected to the input of a CMS command.

A question I have often asked, and usually been misunderstood is, "Can a Pipeline be connected to a DDNAME of a classic z/OS utility?"
"Sure, Pipelines has a DD driver." answers a different question. That assumes that DD has been ALLOCATEd to a data set. But how can I connect a Pipeline to SYSUT1 or SYSUT2 of a classic command? I imagine the recherché approach:

SYSCALL pipe
connect a Pipeline to the input descriptor of the pipe.
BPXWDYN ALLOC SYSUT1 to the output descriptor of the pipe
SYSCALL pipe
BPXWDYN ALLOC SYSUT2 to the input descriptor of that pipe
connect a pipeline to the output descriptor of that pipe
somehow invoke a utility.

I suppose that could all be encapsulated in a Rexx stage. OS/360 had a design integrity with I/O abstraction better than that of CMS.
I hope Pipelines for z/OS doesn't ignore that.

-- gil


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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-11-17 18:24:49 UTC
Reply
Permalink
Raw Message
I suspected that this function belonged to Netview, but as you noted, it was implemented here only during SA installation. I brought it up because there is obviously native z/OS code involved. Porting that to TSO might be a tad easier than lifting code across from z/VM.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Thank you for "PIPing" up on this! :)

One thing to note, the PIPE command is part of the Base NetView product, you do not have to add SA to get it.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, November 16, 2017 4:30 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Not sure where this fits in to the discussion, but Netview System Automation has a built-in pipes function. So we see messages like these:

AOF570I 00:39:48 : ISSUED "PIPE SAFE AOFMSAFE | EDIT /AFTER
00:00:03,MVS $A/ N JOBNUM N /;S/ N JOBNUM N | NETVIEW" FOR
MVSESA MVSESA - MSGTYPE IS $HASP100

AOF570I 01:04:11 : ISSUED "PIPE SAFE AOFMSAFE | EDIT FWDLINE 1
PARSE /,/ SKIPTO /DSNAME=/ W1 SUBSTR 8.* WL | EDIT /MVS S
DB2ALOG,ALOG=/ N W1 N | LOGTO NETLOG | NETV" FOR SUBSYSTEM
DA20MSTR - MSGTYPE IS DSNJ003I

I'm not an SA guy, so I can't comment on the function in any detail. Just pointing out that it's included with the product on z/OS.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, November 16, 2017 10:13 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
The early versions of UNIX were written on small machines (32K?!),
with slow/small disk drives. Writing temporary results out to disk
was too slow and inefficient, so they came up a pipe operator ( | ),
which connected the input of one command to the output of the previous
one, thus avoiding physical I/O.. E.g. *ls | wc*. The data passed
thru an in-memory buffer with both commands running, and UNIX
dispatching each as needed. It also allowed intermediate results to
be very much larger than the available disk space, since those intermediate results didn't have to be written to disk.
Sometimes. Otherwise, in those early days, real memory was often the constraining factor so the piped implementation had performance inferior to using a temporary file because of paging overhead.
... The original questioner thought
I was pulling his leg (since one could do that with a single character
in
UNIX) and he had left before I was done.
Yup. Pipelines is not quite so terse.
UNIX: foo <file1 | bar >file2
Pipelines: PIPE < file1 | foo | bar | > file2
If you have any doubt about the usefulness of Pipes, take a poll of
your z/VM friends. They would tell you that they couldn't live
without Pipes, not because z/VM otherwise lacks anything, but because
Pipes is so powerful and efficient.
Not entirely true. CMS is grievously deficient in any support for concurrency.
In consequence, any CMS command stage suspends the entire remainder of the pipeline while the CMS stage runs. So, Piplines reinvented many of the classic CMS wheels (it often did better). I hope pipelines on z/OS can employ ATTACH to avoid such redundancy.

CMS pipelines is not well integrated with classic CMS commands. While the output of a CMS command can be connected to a Pipeline stage, a Pipeline stage can not be connected to the input of a CMS command.

A question I have often asked, and usually been misunderstood is, "Can a Pipeline be connected to a DDNAME of a classic z/OS utility?"
"Sure, Pipelines has a DD driver." answers a different question. That assumes that DD has been ALLOCATEd to a data set. But how can I connect a Pipeline to SYSUT1 or SYSUT2 of a classic command? I imagine the recherché approach:

SYSCALL pipe
connect a Pipeline to the input descriptor of the pipe.
BPXWDYN ALLOC SYSUT1 to the output descriptor of the pipe
SYSCALL pipe
BPXWDYN ALLOC SYSUT2 to the input descriptor of that pipe
connect a pipeline to the output descriptor of that pipe
somehow invoke a utility.

I suppose that could all be encapsulated in a Rexx stage. OS/360 had a design integrity with I/O abstraction better than that of CMS.
I hope Pipelines for z/OS doesn't ignore that.

-- gil


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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-11-17 19:05:25 UTC
Reply
Permalink
Raw Message
Dumb question of the day: Assuming you have NetView installed, can the NetView pipes implementation be used outside of NetView? E.G., in a batch step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?

Based on the discussion so far I am guessing probably not, but thought it was worth throwing out the question.

I am totally ignorant of NetView functionality other than using NetView Access for certain 3270 terminal logons, so please be gentle.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

I suspected that this function belonged to Netview, but as you noted, it was implemented here only during SA installation. I brought it up because there is obviously native z/OS code involved. Porting that to TSO might be a tad easier than lifting code across from z/VM.
.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Thank you for "PIPing" up on this! :)

One thing to note, the PIPE command is part of the Base NetView product, you do not have to add SA to get it.
--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-11-17 19:10:45 UTC
Reply
Permalink
Raw Message
Post by Jesse 1 Robinson
I suspected that this function belonged to Netview, but as you noted, it was implemented here only during SA installation. I brought it up because there is obviously native z/OS code involved. Porting that to TSO might be a tad easier than lifting code across from z/VM.
In the frontmatter of:
z/VM CMS Pipelines User’s Guide and Reference Version 6 Release 4
SC24-6252-00

| Though this book is specific to z/VM, it also describes built-in programs that are specific
| to z/OS and contains other references to z/OS and TSO Pipelines. These references do not
| imply that an implementation of CMS Pipelines for z/OS is available.

WTF? Revision bars!? This reeks of bitter politics.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-11-17 19:28:43 UTC
Reply
Permalink
Raw Message
Ah Netview Access. Some years ago we had a SHARE (JES2) Singalong ditty entitled the Netview Bunch. Sung of course to tune of the Brady Bunch. All about a family (of software products) bound together without a common parent but designated siblings through a marriage of convenience.

But alas, I also doubt that Netview Pipes could be implemented outside of the Netview environment, of which SA is one. And if you don't already have Netview for other business purposes, acquiring it just for Pipes might be a tough sell.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Friday, November 17, 2017 11:07 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Dumb question of the day: Assuming you have NetView installed, can the NetView pipes implementation be used outside of NetView? E.G., in a batch step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?

Based on the discussion so far I am guessing probably not, but thought it was worth throwing out the question.

I am totally ignorant of NetView functionality other than using NetView Access for certain 3270 terminal logons, so please be gentle.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

I suspected that this function belonged to Netview, but as you noted, it was implemented here only during SA installation. I brought it up because there is obviously native z/OS code involved. Porting that to TSO might be a tad easier than lifting code across from z/VM.
.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Thank you for "PIPing" up on this! :)

One thing to note, the PIPE command is part of the Base NetView product, you do not have to add SA to get it.
--

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2017-11-17 19:39:27 UTC
Reply
Permalink
Raw Message
Let me clarify a couple of things.

The PIPEs SORT stage only uses virtual storage. The DFSORT stage is used
when your data is larger than the virtual storage available. DFSORT uses
disk also, and runs a bit slower.

TSO Pipelines and BatchPipesWorks are two versions/names of CMS/TSO
Pipelines that runs under z/OS. I have used both at a number of sites.
AFAIK, they are still available. They are both chargeable. Someone will
correct me if I'm wrong, but NetView pipes is a different animal and I
doubt it has any significant bearing on this discussion.
Post by Jesse 1 Robinson
Ah Netview Access. Some years ago we had a SHARE (JES2) Singalong ditty
entitled the Netview Bunch. Sung of course to tune of the Brady Bunch. All
about a family (of software products) bound together without a common
parent but designated siblings through a marriage of convenience.
But alas, I also doubt that Netview Pipes could be implemented outside of
the Netview environment, of which SA is one. And if you don't already have
Netview for other business purposes, acquiring it just for Pipes might be a
tough sell.
.
.
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
-----Original Message-----
Behalf Of Farley, Peter x23353
Sent: Friday, November 17, 2017 11:07 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Dumb question of the day: Assuming you have NetView installed, can the
NetView pipes implementation be used outside of NetView? E.G., in a batch
step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?
Based on the discussion so far I am guessing probably not, but thought it
was worth throwing out the question.
I am totally ignorant of NetView functionality other than using NetView
Access for certain 3270 terminal logons, so please be gentle.
Peter
-----Original Message-----
Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
I suspected that this function belonged to Netview, but as you noted, it
was implemented here only during SA installation. I brought it up because
there is obviously native z/OS code involved. Porting that to TSO might be
a tad easier than lifting code across from z/VM.
.
.
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
-----Original Message-----
Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Thank you for "PIPing" up on this! :)
One thing to note, the PIPE command is part of the Base NetView product,
you do not have to add SA to get it.
--
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
OREXXMan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob van der Heij
2017-11-17 20:54:02 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
z/VM CMS Pipelines User’s Guide and Reference Version 6 Release 4
SC24-6252-00
You can blame me for keeping the z/OS pieces in the book. It felt like a waste of resources to carefully edit it out when there might be a chance that we would want to have it back again. I believe it does not confuse the CMS users that much, but it's not typical for z/VM books to document z/OS function.

Sir Rob the Plumber

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-11-17 21:26:47 UTC
Reply
Permalink
Raw Message
Post by Rob van der Heij
Post by Paul Gilmartin
z/VM CMS Pipelines User’s Guide and Reference Version 6 Release 4
SC24-6252-00
You can blame me for keeping the z/OS pieces in the book. It felt like a waste of resources to carefully edit it out when there might be a chance that we would want to have it back again.
Such as via RFE?
Post by Rob van der Heij
... I believe it does not confuse the CMS users that much, but it's not typical for z/VM books to document z/OS function.
Surely the least expense to IBM and the greatest benefit to customers would be a
common sourced Pipelines rather than hacking some other code possibly extant
on z/OS.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Martin Packer
2017-11-18 08:00:04 UTC
Reply
Permalink
Raw Message
A DFSORT stage would/could/should allow all the myriad* DFSORT control statements. And be for heavy lifting. Those are the two reasons I suggested it.

And note a DFSORT stage could be tested outside of a pipeline.

Also note Pipelines could orchestrate multiple DFSORT invocations in a chain.

Cheers, Martin

* If you don’t think the word “myriad” is appropriate RTFM. :-) The point is there’s lots of processing capability there.

Sent from my iPad
Post by Hobart Spitz
Let me clarify a couple of things.
The PIPEs SORT stage only uses virtual storage. The DFSORT stage is used
when your data is larger than the virtual storage available. DFSORT uses
disk also, and runs a bit slower.
TSO Pipelines and BatchPipesWorks are two versions/names of CMS/TSO
Pipelines that runs under z/OS. I have used both at a number of sites.
AFAIK, they are still available. They are both chargeable. Someone will
correct me if I'm wrong, but NetView pipes is a different animal and I
doubt it has any significant bearing on this discussion.
Post by Jesse 1 Robinson
Ah Netview Access. Some years ago we had a SHARE (JES2) Singalong ditty
entitled the Netview Bunch. Sung of course to tune of the Brady Bunch. All
about a family (of software products) bound together without a common
parent but designated siblings through a marriage of convenience.
But alas, I also doubt that Netview Pipes could be implemented outside of
the Netview environment, of which SA is one. And if you don't already have
Netview for other business purposes, acquiring it just for Pipes might be a
tough sell.
.
.
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
-----Original Message-----
Behalf Of Farley, Peter x23353
Sent: Friday, November 17, 2017 11:07 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Dumb question of the day: Assuming you have NetView installed, can the
NetView pipes implementation be used outside of NetView? E.G., in a batch
step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?
Based on the discussion so far I am guessing probably not, but thought it
was worth throwing out the question.
I am totally ignorant of NetView functionality other than using NetView
Access for certain 3270 terminal logons, so please be gentle.
Peter
-----Original Message-----
Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
I suspected that this function belonged to Netview, but as you noted, it
was implemented here only during SA installation. I brought it up because
there is obviously native z/OS code involved. Porting that to TSO might be
a tad easier than lifting code across from z/VM.
.
.
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
-----Original Message-----
Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Thank you for "PIPing" up on this! :)
One thing to note, the PIPE command is part of the Base NetView product,
you do not have to add SA to get it.
--
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
OREXXMan
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2017-11-21 20:04:29 UTC
Reply
Permalink
Raw Message
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT control
statements. And be for heavy lifting. Those are the two reasons I suggested
it.

I was going to do some details research (my DFSORT knowledge is probably
out of date, for which I take responsibility), but time is short, and I
don't want the issue to get stale. I believe you are referring to
INCLUDE/OMIT, INREC/OUTREC, etc.

I hope this answers your point. I don't know if your statement is true, or
will ever be implemented. I will say that Pipelines offers so many more
options in record selection, formatting, conversion and field
specification, that what you suggest probably will never need to be
implemented.

Here's why:

- Of the 300+ Pipelines stages, many are selection stages. In this case,
"many" is much more than myriad, AFAIK, by an order of magniture. There
are simple selectors, but also complex ones that support conversions,
logic, arithmetic, and reformatting.

- Fields can be identified by character, word, or delimited field. Each of
these can used as substring to an enclosing specification, to multiple
levels. E.g., take the second slash delimited subfield in the seventh tab
delimited field to get a numeric month value. And you are not limited to
blanks as white space or tabs as delimiters.

- The DFSORT program product control statements can only be used in
connection with the sort process. Pipelines stages can be used even when
you are not sorting. In other words, Pipelines skills, while being easy to
learn (unlike my recollection of DFSORT control statement), they have a
vastly broader range of applicable uses.

- The DFSORT program product E15 and E35 internal sort exits can only be
used once per sort. Pipelines stages bring this efficiency to each and
every stage in a Pipeline. To press the point, unlike the need for record
and field definitions in, say, a COBOL internal sort exit, the intermediate
records don't have to be defined, and fields only have to be referenced if
they are actually involved in the a particular stage.

- Finally, you can process unselected records without having to reprocess
the entire input file, as shown below.

Business problem: You have an externally produced name and address file
that has to be sorted by ZIP code to get a USPS discount rate. There are
two types of records, business and residential. The fields are free format
and tab delimited. The business records differ from residential records in
that there are additional fields: Company after the name fields and an
ATTN: field after the ZIP code. This would be trivial in pipes if the ZIP
code were the last field, but we can't use that because of the ATTN: field.

A pipes approach is as follows: Separate the records into streams and
prefix each record with its ZIP code. Then sort by the ZIP in the first
field, discard the prefix ZIP. It would look something like this in
commented REXX. ( Visualizing someone else's multi-stream pipe is easier
with a flow chart.)

...
/*--------------------------------------------------------*/
/* f200: f800: */
/* +-+ +-+ +----+ +-+ +------+ +----+ +-+ */
/* |<|-->|p|-->|spec|-->|f|-->|dfsort|-->|chop|-->|>| */
/* +-+ |i| +----+ |a| +------+ +----+ +-+ */
/* |c| |n| */
/* |k| +----+ |i| */
/* | |-->|spec|-->|n| */
/* +-+ +----+ +-+ */
/*--------------------------------------------------------*/
"pipe (listerr name ZIPSort.exec end ? ",
"| < in.file ",
"| f200: pick 1.1 == /R/", /* Residential records */
"| specs field 8 1 1-* nextfield", /* ZIP pfx */
"| f800: fanin ", /* Concat residential and business */
"| dfsort option nolist sort fields=(5,10,cha,a)",
, /* NOT compound stage causes CHOP to keep the orig. rcd.*/
"| not chop after 05", /* Trim prefix key and tab.*/
"| > out.file */

"? f200: ", /* Business record come here. */
"| specs field 9 1 1-* nextfield", /* ZIP pfx */
"| f800: ", /* Back to first stream. */
...


I hope this helps. Even if there are features new (to me) of DFSORT would
make some of my statements incorrect, I'm quite sure that the remaining
ones would still drive the point home easily.
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT control
statements. And be for heavy lifting. Those are the two reasons I suggested
it.
And note a DFSORT stage could be tested outside of a pipeline.
Also note Pipelines could orchestrate multiple DFSORT invocations in a chain.
Cheers, Martin
* If you don’t think the word “myriad” is appropriate RTFM. :-) The point
is there’s lots of processing capability there.
Sent from my iPad
Post by Hobart Spitz
Let me clarify a couple of things.
The PIPEs SORT stage only uses virtual storage. The DFSORT stage is used
when your data is larger than the virtual storage available. DFSORT uses
disk also, and runs a bit slower.
TSO Pipelines and BatchPipesWorks are two versions/names of CMS/TSO
Pipelines that runs under z/OS. I have used both at a number of sites.
AFAIK, they are still available. They are both chargeable. Someone will
correct me if I'm wrong, but NetView pipes is a different animal and I
doubt it has any significant bearing on this discussion.
On Fri, Nov 17, 2017 at 2:29 PM, Jesse 1 Robinson <
Post by Jesse 1 Robinson
Ah Netview Access. Some years ago we had a SHARE (JES2) Singalong ditty
entitled the Netview Bunch. Sung of course to tune of the Brady Bunch.
All
Post by Hobart Spitz
Post by Jesse 1 Robinson
about a family (of software products) bound together without a common
parent but designated siblings through a marriage of convenience.
But alas, I also doubt that Netview Pipes could be implemented outside
of
Post by Hobart Spitz
Post by Jesse 1 Robinson
the Netview environment, of which SA is one. And if you don't already
have
Post by Hobart Spitz
Post by Jesse 1 Robinson
Netview for other business purposes, acquiring it just for Pipes might
be a
Post by Hobart Spitz
Post by Jesse 1 Robinson
tough sell.
.
.
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
-----Original Message-----
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Farley, Peter x23353
Sent: Friday, November 17, 2017 11:07 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Dumb question of the day: Assuming you have NetView installed, can the
NetView pipes implementation be used outside of NetView? E.G., in a
batch
Post by Hobart Spitz
Post by Jesse 1 Robinson
step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?
Based on the discussion so far I am guessing probably not, but thought
it
Post by Hobart Spitz
Post by Jesse 1 Robinson
was worth throwing out the question.
I am totally ignorant of NetView functionality other than using NetView
Access for certain 3270 terminal logons, so please be gentle.
Peter
-----Original Message-----
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
I suspected that this function belonged to Netview, but as you noted, it
was implemented here only during SA installation. I brought it up
because
Post by Hobart Spitz
Post by Jesse 1 Robinson
there is obviously native z/OS code involved. Porting that to TSO might
be
Post by Hobart Spitz
Post by Jesse 1 Robinson
a tad easier than lifting code across from z/VM.
.
.
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
-----Original Message-----
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Thank you for "PIPing" up on this! :)
One thing to note, the PIPE command is part of the Base NetView product,
you do not have to add SA to get it.
--
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
OREXXMan
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
OREXXMan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sri h Kolusu
2017-11-21 21:52:46 UTC
Reply
Permalink
Raw Message
Hi,

Here is a sample DFSORT job that reads a pipe and does a sort while
modifying the data using inrec(before sorting) Outrec(after sorting) and
Outfil

//PIPEDEMA JOB (DA26,001,098,J69),'KOLUSU',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID
//*
//**************************************************************
//* DELETE THE INPUT PIPE DATASET IF IT EXISTED **
//**************************************************************
//STEP0001 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//DD1 DD DSN=&SYSUID..PIPE.INPUT,
// UNIT=SYSDA,SPACE=(TRK,0),DISP=(MOD,DELETE)
//*
//**************************************************************
//* CREATE THE INPUT TO SORT AND WRITE IT TO A PIPE **
//* WILL HAVE 60 RECORDS (20 RECORDS FOR EACH NAME) **
//**************************************************************
//PIPERCRE EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
PAUL
MARTIN
HOBART
//SORTOUT DD DSN=&SYSUID..PIPE.INPUT,
// SUBSYS=(BP01,'WAITOPEN=180'),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SYSIN DD *
OPTION COPY
OUTFIL REPEAT=20,OVERLAY=(20:SEQNUM,3,ZD,RESTART=(1,10))
/*
//PIPEDEMB JOB (DA26,001,098,J69),'KOLUSU',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID
//*
//**************************************************************
//* READ THE PIPE AND USING INREC MODIFY MARTIN RECORDS **
//* SORT THE DATA ON NAME AND SEQUENCE DESCENDING **
//* MODIFY PAUL RECORDS USING OUTREC **
//* MODIFY HOBART RECORDS USING OUTFIL **
//**************************************************************
//PIPEREAD EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTDIAG DD DUMMY
//SORTIN DD DISP=SHR,DSN=&SYSUID..PIPE.INPUT,
// SUBSYS=(BP01,'WAITOPEN=180'),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SORTOUT DD SYSOUT=*
//SYSIN DD *
INREC IFTHEN=(WHEN=(01,10,CH,EQ,C'MARTIN',AND,
20,03,SS,EQ,C'005,010,015,020'),
OVERLAY=(31:C'EVERY 5TH RECORD TAGGED USING INREC'))

SORT FIELDS=(01,10,CH,A, $ SORT ON NAME ASC
21,03,ZD,D) $ SORT ON SEQ DESC

OUTREC IFTHEN=(WHEN=(01,10,CH,EQ,C'PAUL',AND,
20,03,SS,EQ,C'006,012,018'),
OVERLAY=(31:C'TAGGED EVERY 6TH RECORD USING OUTREC'))

OUTFIL IFTHEN=(WHEN=(01,10,CH,EQ,C'HOBART',AND,
20,03,CH,EQ,C'020'),
OVERLAY=(31:C'RECORD 20 IS TAGGED USING OUTFIL'))

/*

Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation
Date: 11/21/2017 01:06 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT control
statements. And be for heavy lifting. Those are the two reasons I
suggested
it.
I was going to do some details research (my DFSORT knowledge is probably
out of date, for which I take responsibility), but time is short, and I
don't want the issue to get stale. I believe you are referring to
INCLUDE/OMIT, INREC/OUTREC, etc.
I hope this answers your point. I don't know if your statement is true,
or
will ever be implemented. I will say that Pipelines offers so many more
options in record selection, formatting, conversion and field
specification, that what you suggest probably will never need to be
implemented.
- Of the 300+ Pipelines stages, many are selection stages. In this
case,
"many" is much more than myriad, AFAIK, by an order of magniture. There
are simple selectors, but also complex ones that support conversions,
logic, arithmetic, and reformatting.
- Fields can be identified by character, word, or delimited field. Each
of
these can used as substring to an enclosing specification, to multiple
levels. E.g., take the second slash delimited subfield in the seventh
tab
delimited field to get a numeric month value. And you are not limited
to
blanks as white space or tabs as delimiters.
- The DFSORT program product control statements can only be used in
connection with the sort process. Pipelines stages can be used even
when
you are not sorting. In other words, Pipelines skills, while being easy
to
learn (unlike my recollection of DFSORT control statement), they have a
vastly broader range of applicable uses.
- The DFSORT program product E15 and E35 internal sort exits can only be
used once per sort. Pipelines stages bring this efficiency to each and
every stage in a Pipeline. To press the point, unlike the need for
record
and field definitions in, say, a COBOL internal sort exit, the
intermediate
records don't have to be defined, and fields only have to be referenced
if
they are actually involved in the a particular stage.
- Finally, you can process unselected records without having to
reprocess
the entire input file, as shown below.
Business problem: You have an externally produced name and address file
that has to be sorted by ZIP code to get a USPS discount rate. There
are
two types of records, business and residential. The fields are free
format
and tab delimited. The business records differ from residential records
in
that there are additional fields: Company after the name fields and an
ATTN: field after the ZIP code. This would be trivial in pipes if the
ZIP
field.
A pipes approach is as follows: Separate the records into streams and
prefix each record with its ZIP code. Then sort by the ZIP in the first
field, discard the prefix ZIP. It would look something like this in
commented REXX. ( Visualizing someone else's multi-stream pipe is easier
with a flow chart.)
...
/*--------------------------------------------------------*/
/* f200: f800: */
/* +-+ +-+ +----+ +-+ +------+ +----+ +-+ */
/* |<|-->|p|-->|spec|-->|f|-->|dfsort|-->|chop|-->|>| */
/* +-+ |i| +----+ |a| +------+ +----+ +-+ */
/* |c| |n| */
/* |k| +----+ |i| */
/* | |-->|spec|-->|n| */
/* +-+ +----+ +-+ */
/*--------------------------------------------------------*/
"pipe (listerr name ZIPSort.exec end ? ",
"| < in.file ",
"| f200: pick 1.1 == /R/", /* Residential records */
"| specs field 8 1 1-* nextfield", /* ZIP pfx */
"| f800: fanin ", /* Concat residential and business */
"| dfsort option nolist sort fields=(5,10,cha,a)",
, /* NOT compound stage causes CHOP to keep the orig. rcd.*/
"| not chop after 05", /* Trim prefix key and tab.*/
"| > out.file */
"? f200: ", /* Business record come here. */
"| specs field 9 1 1-* nextfield", /* ZIP pfx */
"| f800: ", /* Back to first stream. */
...
I hope this helps. Even if there are features new (to me) of DFSORT
would
make some of my statements incorrect, I'm quite sure that the remaining
ones would still drive the point home easily.
On Sat, Nov 18, 2017 at 3:01 AM, Martin Packer
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT control
statements. And be for heavy lifting. Those are the two reasons I
suggested
Post by Martin Packer
it.
And note a DFSORT stage could be tested outside of a pipeline.
Also note Pipelines could orchestrate multiple DFSORT invocations in a chain.
Cheers, Martin
* If you don’t think the word “myriad” is appropriate RTFM. :-) The
point
Post by Martin Packer
is there’s lots of processing capability there.
Sent from my iPad
Post by Hobart Spitz
Let me clarify a couple of things.
The PIPEs SORT stage only uses virtual storage. The DFSORT stage is used
when your data is larger than the virtual storage available. DFSORT uses
disk also, and runs a bit slower.
TSO Pipelines and BatchPipesWorks are two versions/names of CMS/TSO
Pipelines that runs under z/OS. I have used both at a number of sites.
AFAIK, they are still available. They are both chargeable. Someone will
correct me if I'm wrong, but NetView pipes is a different animal and I
doubt it has any significant bearing on this discussion.
On Fri, Nov 17, 2017 at 2:29 PM, Jesse 1 Robinson <
Post by Jesse 1 Robinson
Ah Netview Access. Some years ago we had a SHARE (JES2) Singalong ditty
entitled the Netview Bunch. Sung of course to tune of the Brady
Bunch.
Post by Martin Packer
All
Post by Hobart Spitz
Post by Jesse 1 Robinson
about a family (of software products) bound together without a common
parent but designated siblings through a marriage of convenience.
But alas, I also doubt that Netview Pipes could be implemented
outside
Post by Martin Packer
of
Post by Hobart Spitz
Post by Jesse 1 Robinson
the Netview environment, of which SA is one. And if you don't
already
Post by Martin Packer
have
Post by Hobart Spitz
Post by Jesse 1 Robinson
Netview for other business purposes, acquiring it just for Pipes
might
Post by Martin Packer
be a
Post by Hobart Spitz
Post by Jesse 1 Robinson
tough sell.
.
.
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
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Farley, Peter x23353
Sent: Friday, November 17, 2017 11:07 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Dumb question of the day: Assuming you have NetView installed, can the
NetView pipes implementation be used outside of NetView? E.G., in
a
Post by Martin Packer
batch
Post by Hobart Spitz
Post by Jesse 1 Robinson
step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?
Based on the discussion so far I am guessing probably not, but
thought
Post by Martin Packer
it
Post by Hobart Spitz
Post by Jesse 1 Robinson
was worth throwing out the question.
I am totally ignorant of NetView functionality other than using NetView
Access for certain 3270 terminal logons, so please be gentle.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
I suspected that this function belonged to Netview, but as you noted, it
was implemented here only during SA installation. I brought it up
because
Post by Hobart Spitz
Post by Jesse 1 Robinson
there is obviously native z/OS code involved. Porting that to TSO
might
Post by Martin Packer
be
Post by Hobart Spitz
Post by Jesse 1 Robinson
a tad easier than lifting code across from z/VM.
.
.
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
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Thank you for "PIPing" up on this! :)
One thing to note, the PIPE command is part of the Base NetView product,
you do not have to add SA to get it.
--
----------------------------------------------------------------------
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
For IBM-MAIN subscribe / signoff / archive access instructions,
--
OREXXMan
----------------------------------------------------------------------
Post by Martin Packer
Post by Hobart Spitz
For IBM-MAIN subscribe / signoff / archive access instructions,
IBM United Kingdom Limited - Registered in England and Wales with
number
Post by Martin Packer
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
OREXXMan
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-11-21 22:10:53 UTC
Reply
Permalink
Raw Message
I have never worked with pipes in a production batch environment. In a classic batch job, if a problem occurs somewhere in the middle, it's common to restart the job at some recoverable point after fixing the downstream problem. I cannot visualize how to restart a pipes job in such a case. Without intermediate files to resume with, how does all that in-memory data get recreated without starting back at the top?

In a short or medium length job, starting over may not be such a big problem, but for a job that runs hours on a good day, I could envision some major production schedule glitches with pipes.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Sri h Kolusu
Sent: Tuesday, November 21, 2017 1:54 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Hi,

Here is a sample DFSORT job that reads a pipe and does a sort while modifying the data using inrec(before sorting) Outrec(after sorting) and Outfil

//PIPEDEMA JOB (DA26,001,098,J69),'KOLUSU',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID
//*
//**************************************************************
//* DELETE THE INPUT PIPE DATASET IF IT EXISTED **
//**************************************************************
//STEP0001 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//DD1 DD DSN=&SYSUID..PIPE.INPUT,
// UNIT=SYSDA,SPACE=(TRK,0),DISP=(MOD,DELETE)
//*
//**************************************************************
//* CREATE THE INPUT TO SORT AND WRITE IT TO A PIPE **
//* WILL HAVE 60 RECORDS (20 RECORDS FOR EACH NAME) **
//**************************************************************
//PIPERCRE EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
PAUL
MARTIN
HOBART
//SORTOUT DD DSN=&SYSUID..PIPE.INPUT,
// SUBSYS=(BP01,'WAITOPEN=180'),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SYSIN DD *
OPTION COPY
OUTFIL REPEAT=20,OVERLAY=(20:SEQNUM,3,ZD,RESTART=(1,10))
/*
//PIPEDEMB JOB (DA26,001,098,J69),'KOLUSU',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID
//*
//**************************************************************
//* READ THE PIPE AND USING INREC MODIFY MARTIN RECORDS **
//* SORT THE DATA ON NAME AND SEQUENCE DESCENDING **
//* MODIFY PAUL RECORDS USING OUTREC **
//* MODIFY HOBART RECORDS USING OUTFIL **
//**************************************************************
//PIPEREAD EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTDIAG DD DUMMY
//SORTIN DD DISP=SHR,DSN=&SYSUID..PIPE.INPUT,
// SUBSYS=(BP01,'WAITOPEN=180'),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SORTOUT DD SYSOUT=*
//SYSIN DD *
INREC IFTHEN=(WHEN=(01,10,CH,EQ,C'MARTIN',AND,
20,03,SS,EQ,C'005,010,015,020'),
OVERLAY=(31:C'EVERY 5TH RECORD TAGGED USING INREC'))

SORT FIELDS=(01,10,CH,A, $ SORT ON NAME ASC
21,03,ZD,D) $ SORT ON SEQ DESC

OUTREC IFTHEN=(WHEN=(01,10,CH,EQ,C'PAUL',AND,
20,03,SS,EQ,C'006,012,018'),
OVERLAY=(31:C'TAGGED EVERY 6TH RECORD USING OUTREC'))

OUTFIL IFTHEN=(WHEN=(01,10,CH,EQ,C'HOBART',AND,
20,03,CH,EQ,C'020'),
OVERLAY=(31:C'RECORD 20 IS TAGGED USING OUTFIL'))

/*

Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation
Date: 11/21/2017 01:06 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT
control
statements. And be for heavy lifting. Those are the two reasons I
suggested
it.
I was going to do some details research (my DFSORT knowledge is
probably out of date, for which I take responsibility), but time is
short, and I don't want the issue to get stale. I believe you are
referring to INCLUDE/OMIT, INREC/OUTREC, etc.
I hope this answers your point. I don't know if your statement is
true,
or
will ever be implemented. I will say that Pipelines offers so many
more options in record selection, formatting, conversion and field
specification, that what you suggest probably will never need to be
implemented.
- Of the 300+ Pipelines stages, many are selection stages. In this
case,
"many" is much more than myriad, AFAIK, by an order of magniture.
There are simple selectors, but also complex ones that support
conversions, logic, arithmetic, and reformatting.
- Fields can be identified by character, word, or delimited field.
Each
of
these can used as substring to an enclosing specification, to multiple
levels. E.g., take the second slash delimited subfield in the seventh
tab
delimited field to get a numeric month value. And you are not limited
to
blanks as white space or tabs as delimiters.
- The DFSORT program product control statements can only be used in
connection with the sort process. Pipelines stages can be used even
when
you are not sorting. In other words, Pipelines skills, while being
easy
to
learn (unlike my recollection of DFSORT control statement), they have
a vastly broader range of applicable uses.
- The DFSORT program product E15 and E35 internal sort exits can only
be used once per sort. Pipelines stages bring this efficiency to each
and every stage in a Pipeline. To press the point, unlike the need
for
record
and field definitions in, say, a COBOL internal sort exit, the
intermediate
records don't have to be defined, and fields only have to be
referenced
if
they are actually involved in the a particular stage.
- Finally, you can process unselected records without having to
reprocess
the entire input file, as shown below.
Business problem: You have an externally produced name and address
file that has to be sorted by ZIP code to get a USPS discount rate.
There
are
two types of records, business and residential. The fields are free
format
and tab delimited. The business records differ from residential
records
in
that there are additional fields: Company after the name fields and
an
ATTN: field after the ZIP code. This would be trivial in pipes if the
ZIP
field.
A pipes approach is as follows: Separate the records into streams and
prefix each record with its ZIP code. Then sort by the ZIP in the
first field, discard the prefix ZIP. It would look something like
this in commented REXX. ( Visualizing someone else's multi-stream pipe
is easier with a flow chart.)
...
/*--------------------------------------------------------*/
/* f200: f800: */
/* +-+ +-+ +----+ +-+ +------+ +----+ +-+ */
/* |<|-->|p|-->|spec|-->|f|-->|dfsort|-->|chop|-->|>| */
/* +-+ |i| +----+ |a| +------+ +----+ +-+ */
/* |c| |n| */
/* |k| +----+ |i| */
/* | |-->|spec|-->|n| */
/* +-+ +----+ +-+ */
/*--------------------------------------------------------*/
"pipe (listerr name ZIPSort.exec end ? ",
"| < in.file ",
"| f200: pick 1.1 == /R/", /* Residential records */
"| specs field 8 1 1-* nextfield", /* ZIP pfx */
"| f800: fanin ", /* Concat residential and business */
"| dfsort option nolist sort fields=(5,10,cha,a)",
, /* NOT compound stage causes CHOP to keep the orig. rcd.*/
"| not chop after 05", /* Trim prefix key and tab.*/
"| > out.file */
"? f200: ", /* Business record come here. */
"| specs field 9 1 1-* nextfield", /* ZIP pfx */
"| f800: ", /* Back to first stream. */
...
I hope this helps. Even if there are features new (to me) of DFSORT
would
make some of my statements incorrect, I'm quite sure that the
remaining ones would still drive the point home easily.
On Sat, Nov 18, 2017 at 3:01 AM, Martin Packer
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT
control statements. And be for heavy lifting. Those are the two
reasons I
suggested
Post by Martin Packer
it.
And note a DFSORT stage could be tested outside of a pipeline.
Also note Pipelines could orchestrate multiple DFSORT invocations in
a chain.
Cheers, Martin
* If you don’t think the word “myriad” is appropriate RTFM. :-) The
point
Post by Martin Packer
is there’s lots of processing capability there.
Sent from my iPad
Post by Hobart Spitz
Let me clarify a couple of things.
The PIPEs SORT stage only uses virtual storage. The DFSORT stage
is
used
Post by Martin Packer
Post by Hobart Spitz
when your data is larger than the virtual storage available.
DFSORT
uses
Post by Martin Packer
Post by Hobart Spitz
disk also, and runs a bit slower.
TSO Pipelines and BatchPipesWorks are two versions/names of
CMS/TSO Pipelines that runs under z/OS. I have used both at a
number of
sites.
Post by Martin Packer
Post by Hobart Spitz
AFAIK, they are still available. They are both chargeable.
Someone
will
Post by Martin Packer
Post by Hobart Spitz
correct me if I'm wrong, but NetView pipes is a different animal
and
I
Post by Martin Packer
Post by Hobart Spitz
doubt it has any significant bearing on this discussion.
On Fri, Nov 17, 2017 at 2:29 PM, Jesse 1 Robinson <
Post by Jesse 1 Robinson
Ah Netview Access. Some years ago we had a SHARE (JES2) Singalong
ditty
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
entitled the Netview Bunch. Sung of course to tune of the Brady
Bunch.
Post by Martin Packer
All
Post by Hobart Spitz
Post by Jesse 1 Robinson
about a family (of software products) bound together without a
common
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
parent but designated siblings through a marriage of convenience.
But alas, I also doubt that Netview Pipes could be implemented
outside
Post by Martin Packer
of
Post by Hobart Spitz
Post by Jesse 1 Robinson
the Netview environment, of which SA is one. And if you don't
already
Post by Martin Packer
have
Post by Hobart Spitz
Post by Jesse 1 Robinson
Netview for other business purposes, acquiring it just for Pipes
might
Post by Martin Packer
be a
Post by Hobart Spitz
Post by Jesse 1 Robinson
tough sell.
.
.
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
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Farley, Peter x23353
Sent: Friday, November 17, 2017 11:07 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Dumb question of the day: Assuming you have NetView installed,
can
the
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
NetView pipes implementation be used outside of NetView? E.G.,
in
a
Post by Martin Packer
batch
Post by Hobart Spitz
Post by Jesse 1 Robinson
step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?
Based on the discussion so far I am guessing probably not, but
thought
Post by Martin Packer
it
Post by Hobart Spitz
Post by Jesse 1 Robinson
was worth throwing out the question.
I am totally ignorant of NetView functionality other than using
NetView
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
Access for certain 3270 terminal logons, so please be gentle.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
I suspected that this function belonged to Netview, but as you
noted, it
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
was implemented here only during SA installation. I brought it up
because
Post by Hobart Spitz
Post by Jesse 1 Robinson
there is obviously native z/OS code involved. Porting that to TSO
might
Post by Martin Packer
be
Post by Hobart Spitz
Post by Jesse 1 Robinson
a tad easier than lifting code across from z/VM.
.
.
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
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Thank you for "PIPing" up on this! :)
One thing to note, the PIPE command is part of the Base NetView
product,
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
you do not have to add SA to get it.
--
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sri h Kolusu
2017-11-21 22:36:49 UTC
Reply
Permalink
Raw Message
Jesse,

If one end of the pipe fails for any reason, then both ends would have to
be rerun. The redbook "Batch Modernization on 
z/OS" chapter 16
explains the use of Batch pipes. Martin Packer is one of the co-author.

http://www.redbooks.ibm.com/abstracts/sg247779.html

Thanks,
Kolusu



From: Jesse 1 Robinson <***@SCE.COM>
To: IBM-***@LISTSERV.UA.EDU
Date: 11/21/2017 03:13 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Sent by: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU>



I have never worked with pipes in a production batch environment. In a
classic batch job, if a problem occurs somewhere in the middle, it's
common to restart the job at some recoverable point after fixing the
downstream problem. I cannot visualize how to restart a pipes job in such
a case. Without intermediate files to resume with, how does all that
in-memory data get recreated without starting back at the top?

In a short or medium length job, starting over may not be such a big
problem, but for a job that runs hours on a good day, I could envision
some major production schedule glitches with pipes.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Sri h Kolusu
Sent: Tuesday, November 21, 2017 1:54 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

Hi,

Here is a sample DFSORT job that reads a pipe and does a sort while
modifying the data using inrec(before sorting) Outrec(after sorting) and
Outfil

//PIPEDEMA JOB (DA26,001,098,J69),'KOLUSU',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID
//*
//**************************************************************
//* DELETE THE INPUT PIPE DATASET IF IT EXISTED **
//**************************************************************
//STEP0001 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//DD1 DD DSN=&SYSUID..PIPE.INPUT,
// UNIT=SYSDA,SPACE=(TRK,0),DISP=(MOD,DELETE)
//*
//**************************************************************
//* CREATE THE INPUT TO SORT AND WRITE IT TO A PIPE **
//* WILL HAVE 60 RECORDS (20 RECORDS FOR EACH NAME) **
//**************************************************************
//PIPERCRE EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
PAUL
MARTIN
HOBART
//SORTOUT DD DSN=&SYSUID..PIPE.INPUT,
// SUBSYS=(BP01,'WAITOPEN=180'),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SYSIN DD *
OPTION COPY
OUTFIL REPEAT=20,OVERLAY=(20:SEQNUM,3,ZD,RESTART=(1,10))
/*
//PIPEDEMB JOB (DA26,001,098,J69),'KOLUSU',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID
//*
//**************************************************************
//* READ THE PIPE AND USING INREC MODIFY MARTIN RECORDS **
//* SORT THE DATA ON NAME AND SEQUENCE DESCENDING **
//* MODIFY PAUL RECORDS USING OUTREC **
//* MODIFY HOBART RECORDS USING OUTFIL **
//**************************************************************
//PIPEREAD EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTDIAG DD DUMMY
//SORTIN DD DISP=SHR,DSN=&SYSUID..PIPE.INPUT,
// SUBSYS=(BP01,'WAITOPEN=180'),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SORTOUT DD SYSOUT=*
//SYSIN DD *
INREC IFTHEN=(WHEN=(01,10,CH,EQ,C'MARTIN',AND,
20,03,SS,EQ,C'005,010,015,020'),
OVERLAY=(31:C'EVERY 5TH RECORD TAGGED USING INREC'))

SORT FIELDS=(01,10,CH,A, $ SORT ON NAME ASC
21,03,ZD,D) $ SORT ON SEQ DESC

OUTREC IFTHEN=(WHEN=(01,10,CH,EQ,C'PAUL',AND,
20,03,SS,EQ,C'006,012,018'),
OVERLAY=(31:C'TAGGED EVERY 6TH RECORD USING OUTREC'))

OUTFIL IFTHEN=(WHEN=(01,10,CH,EQ,C'HOBART',AND,
20,03,CH,EQ,C'020'),
OVERLAY=(31:C'RECORD 20 IS TAGGED USING OUTFIL'))

/*

Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation
Date: 11/21/2017 01:06 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT
control
statements. And be for heavy lifting. Those are the two reasons I
suggested
it.
I was going to do some details research (my DFSORT knowledge is
probably out of date, for which I take responsibility), but time is
short, and I don't want the issue to get stale. I believe you are
referring to INCLUDE/OMIT, INREC/OUTREC, etc.
I hope this answers your point. I don't know if your statement is
true,
or
will ever be implemented. I will say that Pipelines offers so many
more options in record selection, formatting, conversion and field
specification, that what you suggest probably will never need to be
implemented.
- Of the 300+ Pipelines stages, many are selection stages. In this
case,
"many" is much more than myriad, AFAIK, by an order of magniture.
There are simple selectors, but also complex ones that support
conversions, logic, arithmetic, and reformatting.
- Fields can be identified by character, word, or delimited field.
Each
of
these can used as substring to an enclosing specification, to multiple
levels. E.g., take the second slash delimited subfield in the seventh
tab
delimited field to get a numeric month value. And you are not limited
to
blanks as white space or tabs as delimiters.
- The DFSORT program product control statements can only be used in
connection with the sort process. Pipelines stages can be used even
when
you are not sorting. In other words, Pipelines skills, while being
easy
to
learn (unlike my recollection of DFSORT control statement), they have
a vastly broader range of applicable uses.
- The DFSORT program product E15 and E35 internal sort exits can only
be used once per sort. Pipelines stages bring this efficiency to each
and every stage in a Pipeline. To press the point, unlike the need
for
record
and field definitions in, say, a COBOL internal sort exit, the
intermediate
records don't have to be defined, and fields only have to be
referenced
if
they are actually involved in the a particular stage.
- Finally, you can process unselected records without having to
reprocess
the entire input file, as shown below.
Business problem: You have an externally produced name and address
file that has to be sorted by ZIP code to get a USPS discount rate.
There
are
two types of records, business and residential. The fields are free
format
and tab delimited. The business records differ from residential
records
in
that there are additional fields: Company after the name fields and
an
ATTN: field after the ZIP code. This would be trivial in pipes if the
ZIP
field.
A pipes approach is as follows: Separate the records into streams and
prefix each record with its ZIP code. Then sort by the ZIP in the
first field, discard the prefix ZIP. It would look something like
this in commented REXX. ( Visualizing someone else's multi-stream pipe
is easier with a flow chart.)
...
/*--------------------------------------------------------*/
/* f200: f800: */
/* +-+ +-+ +----+ +-+ +------+ +----+ +-+ */
/* |<|-->|p|-->|spec|-->|f|-->|dfsort|-->|chop|-->|>| */
/* +-+ |i| +----+ |a| +------+ +----+ +-+ */
/* |c| |n| */
/* |k| +----+ |i| */
/* | |-->|spec|-->|n| */
/* +-+ +----+ +-+ */
/*--------------------------------------------------------*/
"pipe (listerr name ZIPSort.exec end ? ",
"| < in.file ",
"| f200: pick 1.1 == /R/", /* Residential records */
"| specs field 8 1 1-* nextfield", /* ZIP pfx */
"| f800: fanin ", /* Concat residential and business */
"| dfsort option nolist sort fields=(5,10,cha,a)",
, /* NOT compound stage causes CHOP to keep the orig. rcd.*/
"| not chop after 05", /* Trim prefix key and tab.*/
"| > out.file */
"? f200: ", /* Business record come here. */
"| specs field 9 1 1-* nextfield", /* ZIP pfx */
"| f800: ", /* Back to first stream. */
...
I hope this helps. Even if there are features new (to me) of DFSORT
would
make some of my statements incorrect, I'm quite sure that the
remaining ones would still drive the point home easily.
On Sat, Nov 18, 2017 at 3:01 AM, Martin Packer
Post by Martin Packer
A DFSORT stage would/could/should allow all the myriad* DFSORT
control statements. And be for heavy lifting. Those are the two
reasons I
suggested
Post by Martin Packer
it.
And note a DFSORT stage could be tested outside of a pipeline.
Also note Pipelines could orchestrate multiple DFSORT invocations in
a chain.
Cheers, Martin
* If you don’t think the word “myriad” is appropriate RTFM. :-) The
point
Post by Martin Packer
is there’s lots of processing capability there.
Sent from my iPad
Post by Hobart Spitz
Let me clarify a couple of things.
The PIPEs SORT stage only uses virtual storage. The DFSORT stage
is
used
Post by Martin Packer
Post by Hobart Spitz
when your data is larger than the virtual storage available.
DFSORT
uses
Post by Martin Packer
Post by Hobart Spitz
disk also, and runs a bit slower.
TSO Pipelines and BatchPipesWorks are two versions/names of
CMS/TSO Pipelines that runs under z/OS. I have used both at a
number of
sites.
Post by Martin Packer
Post by Hobart Spitz
AFAIK, they are still available. They are both chargeable.
Someone
will
Post by Martin Packer
Post by Hobart Spitz
correct me if I'm wrong, but NetView pipes is a different animal
and
I
Post by Martin Packer
Post by Hobart Spitz
doubt it has any significant bearing on this discussion.
On Fri, Nov 17, 2017 at 2:29 PM, Jesse 1 Robinson <
Post by Jesse 1 Robinson
Ah Netview Access. Some years ago we had a SHARE (JES2) Singalong
ditty
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
entitled the Netview Bunch. Sung of course to tune of the Brady
Bunch.
Post by Martin Packer
All
Post by Hobart Spitz
Post by Jesse 1 Robinson
about a family (of software products) bound together without a
common
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
parent but designated siblings through a marriage of convenience.
But alas, I also doubt that Netview Pipes could be implemented
outside
Post by Martin Packer
of
Post by Hobart Spitz
Post by Jesse 1 Robinson
the Netview environment, of which SA is one. And if you don't
already
Post by Martin Packer
have
Post by Hobart Spitz
Post by Jesse 1 Robinson
Netview for other business purposes, acquiring it just for Pipes
might
Post by Martin Packer
be a
Post by Hobart Spitz
Post by Jesse 1 Robinson
tough sell.
.
.
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
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Farley, Peter x23353
Sent: Friday, November 17, 2017 11:07 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Dumb question of the day: Assuming you have NetView installed,
can
the
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
NetView pipes implementation be used outside of NetView? E.G.,
in
a
Post by Martin Packer
batch
Post by Hobart Spitz
Post by Jesse 1 Robinson
step that executes IRXJCL or IKJEFTxx to invokes a Rexx program?
Based on the discussion so far I am guessing probably not, but
thought
Post by Martin Packer
it
Post by Hobart Spitz
Post by Jesse 1 Robinson
was worth throwing out the question.
I am totally ignorant of NetView functionality other than using
NetView
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
Access for certain 3270 terminal logons, so please be gentle.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Jesse 1 Robinson
Sent: Friday, November 17, 2017 1:26 PM
Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
I suspected that this function belonged to Netview, but as you
noted, it
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
was implemented here only during SA installation. I brought it up
because
Post by Hobart Spitz
Post by Jesse 1 Robinson
there is obviously native z/OS code involved. Porting that to TSO
might
Post by Martin Packer
be
Post by Hobart Spitz
Post by Jesse 1 Robinson
a tad easier than lifting code across from z/VM.
.
.
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
-----Original Message-----
From: IBM Mainframe Discussion List [
On
Post by Hobart Spitz
Post by Jesse 1 Robinson
Behalf Of Nims,Alva John (Al)
Sent: Friday, November 17, 2017 7:09 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Thank you for "PIPing" up on this! :)
One thing to note, the PIPE command is part of the Base NetView
product,
Post by Martin Packer
Post by Hobart Spitz
Post by Jesse 1 Robinson
you do not have to add SA to get it.
--
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN





----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-11-22 01:22:45 UTC
Reply
Permalink
Raw Message
Post by Sri h Kolusu
If one end of the pipe fails for any reason, then both ends would have to
be rerun. The redbook "Batch Modernization on 
z/OS" chapter 16
explains the use of Batch pipes. Martin Packer is one of the co-author.
http://www.redbooks.ibm.com/abstracts/sg247779.html
SORT is a weak instructional tool for pipe concepts. As in:
CMS Pipelines User’s Guide and Reference:
sort—Order Records
...
Record Delay: sort delays all records until end-of-file.

I.e. SORT writes nothing until it has completely read its input. One
might as well write to a temp file and sort that.

A better example might be to use ICETOOL to do a minor reformtting,
record-by-record, of its input. And generate that input with an EXEC
that emits a record every few seconds. And use SDSF to track its
output in real time. But beware: a Master Plumber is apt to jump in
with SPECS stages that do the same thing, faster, better, cheaper.

QSAM buffering will introduce some parasitic delay unless you use
unbuffered RECFM.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2017-12-04 13:48:07 UTC
Reply
Permalink
Raw Message
Sorry for the delay in responding.

I'm guessing that Sri is thinking of BatcfhPipes between two otherwise
independent batch JOBs. That is different animal entirely, even though
BatchPipes and BatchPipesWorks (Pipelines/Pipes) can work together.

As for Jesse's question about how to do restart, the short answer is "it
depends". In a typical scenario, each temporary JCL dataset becomes a pipe
character ( | ), one or more JOB steps become a single stage, and the
Pipe's run time is near that of the longest step. If that longest JCL step
is heavily I/O bound on temporary or passed datasets, the run time could be
much, much shorter. The point is implementing a multi-step job in as a
single Pipe could slash the run time and eliminate any need for restart.
You just rerun.

If you still need to be able restart, you can put your PIPE command(s) in a
loop via REXX, and batch (by record count), partition (by key), or
otherwise track and record your progress. Code checks at program start-up,
when the the process runs again, restart at the last point of progress
(A.K.A checkpoint). Automatic restart, where you don't have to specify the
restart point, may be compelling in some cases. That said, that you need
to have a good understanding of your process, of JCL under the covers, and
of Pipes and REXX. (Batch REXX is frequently be part of the solution.)
And you have to be a bit creative.

Yes, that was the short answer!!!

I started to write the long answer out, but it just became way too long.
There were just too many situations, conditions, and approaches to
consider, and a moderate knowledge of what is going on under the covers
when an initiator is processing JCL is needed.

Despite giving talks on replacing JCL with REXX (plus a stub JOB), I
realized that there was little benefit, to the mass
conversion/implementation of batch REXX and/or PIpes. I further realized
that the expertise does not exist in most sites to do such a conversion,
and that it's easier to create new JCL by copying old JCL (mistakes and
all), then to do it cleanly with a new, possibly risky, approach. The fact
that z/OS is only major platform where the commonly used foreground
scripting language differs from that used in the background.

That said, there are situations where the efficiency of Pipes and/or
flexibility of REXX can be crucial to solve otherwise intractable batch
problems.

Let me cite two actual examples from the last few years, where I've had to
address JOB/process issues because critical batch windows were being missed
almost daily. In both cases, there were processes that were failing, and
which had to be rerun. (Only one used Pipes in the solution. The other
was solved with a batch REXX exec.) The common thread was that by stepping
back and looking at the big picture the issues were addressed, and the
batch windows were met consistently

Citing another example, I once replaced an over-maintained COBOL program of
about 1000 lines with REXX exec of about a dozen lines. The only
significant statement was a Pipe host command where all the processing was
done.

The point is that fresh eyes and fresh approaches can do wonders. The less
JCL you write, versus Pipes and REXX, the more flexibility you have to do
what your business needs require and not what the rules of JCL dictate. So
to understand how to do restart, please suspend disbelief, at least
briefly, and accept that most multi-step JOBs can be done in a single step,
using REXX and/or Pipes.

More generally, the best candidates for rewriting in Pipes and/or REXX are
likely to be JOBs that meet one or more of these conditions;

- Are many stepped jobs with significant I/O to/from temporary/passed
datasets.
- Have mostly utility steps versus application program steps.
- Miss their batch windows and/or fail frequently.
- Run more frequently than daily.
- Have to be restarted frequently.
- Have JCL that has been over-maintained and/or that are overly complex
and would benefit from brevity.
- Have many nearly identical instances that differ only in a few PROC
parameters.
- Run very long or are very costly.
- Represent short running processes that you want to run in foreground.
- Represent processes that you want to port to a different platform,
e.g. z/VM, *nix, Windows, etc.
- Have complex restart requirements or need automatic restart at
resubmission.
- Needs to check a condition and retry, rather than restart.
- Are in need of application specific automation.

What really closed down my idea of going into full detail, however, was
when I was browsing tutorial videos on JCL, to get a feel for the current
state of the what people were doing. (I've been on z/VM for about 90% of
the time recently.) In one case, I found an IEFBR14 step with SYSPRINT,
SYSOUT, and SYSUDUMP DDs.

I was afraid I would go blind!!! ;-D

(For those who may not know, IEFBR14 is a null program that does absolutely
nothing; it allows you to use the side effects of DDs, typically. The
entire program is SR 15,15; BR 14; hence the name. It does not use
SYSPRINT, SYSOUT, or SYSUDUMP.)

I plan to update and improve my Pipes and REXX talks and associated batch
methods. They did not go far enough and much has changed in the
intervening decades. Some of the routine initiator emulation funcitons can
be done with common support routines, rather than code duplication.

To do that will require access to a mainframe environment. I am
considering offering, in exchange for access to either a TSO environment
Pipes or z/VM, to review and, if warranted in my opinion, to rewrite one
problematic batch JOB per corporation/organization, that might run better
as REXX and/or Pipes, at no charge. (The target environment does not have
to be the one that you let me use for updating my talks.) If you are
interested, contact me at my personal email address with brief descriptions
of up to 3 candidates and their problem(s): ***@gmail.com .

On Tue, Nov 21, 2017 at 8:24 PM, Paul Gilmartin <
Post by Paul Gilmartin
Post by Sri h Kolusu
If one end of the pipe fails for any reason, then both ends would have to
be rerun. The redbook "Batch Modernization on z/OS" chapter 16
explains the use of Batch pipes. Martin Packer is one of the co-author.
http://www.redbooks.ibm.com/abstracts/sg247779.html
sort—Order Records
...
Record Delay: sort delays all records until end-of-file.
I.e. SORT writes nothing until it has completely read its input. One
might as well write to a temp file and sort that.
A better example might be to use ICETOOL to do a minor reformtting,
record-by-record, of its input. And generate that input with an EXEC
that emits a record every few seconds. And use SDSF to track its
output in real time. But beware: a Master Plumber is apt to jump in
with SPECS stages that do the same thing, faster, better, cheaper.
QSAM buffering will introduce some parasitic delay unless you use
unbuffered RECFM.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
OREXXMan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-12-04 23:55:48 UTC
Reply
Permalink
Raw Message
Post by Hobart Spitz
As for Jesse's question about how to do restart, the short answer is "it
depends". In a typical scenario, each temporary JCL dataset becomes a pipe
character ( | ), one or more JOB steps become a single stage, and the
Pipe's run time is near that of the longest step. If that longest JCL step
is heavily I/O bound on temporary or passed datasets, the run time could be
much, much shorter. The point is implementing a multi-step job in as a
single Pipe could slash the run time and eliminate any need for restart.
You just rerun.
Err not quite,.,,,We had jobs that were long running 2-3 days and essentially one job step.

Ed


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-12-04 16:29:26 UTC
Reply
Permalink
Raw Message
Post by Hobart Spitz
(For those who may not know, IEFBR14 is a null program that does absolutely
nothing; it allows you to use the side effects of DDs, typically. The
entire program is SR 15,15; BR 14; hence the name. It does not use
SYSPRINT, SYSOUT, or SYSUDUMP.)
True, but they might yet have useful side effects, as in:

//STEP EXEC PGM=IEFBR14
//SYSPRINT DD DISP=(,CATLG),UNIT=SYSALLDA,DSN=&SYSUID..PRINT,SPACE=...

What's in a name?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-12-04 17:44:23 UTC
Reply
Permalink
Raw Message
So the simplest of all imaginable programs was once--according to legend--subject to a PE APAR. In the original incarnation, there was only one instruction, BR 14, leaving R15 as on entry. But R15 is generally taken as a return code, so wild and unpredictable numbers were passed back to the caller. The APAR added the instruction to zero R15.

As to whether IEFBR14 'uses' SYSUDUMP: is there any environment where some kind of abend is utterly beyond the pale?

.
.
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
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Monday, December 04, 2017 8:31 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Post by Hobart Spitz
(For those who may not know, IEFBR14 is a null program that does
absolutely nothing; it allows you to use the side effects of DDs,
typically. The entire program is SR 15,15; BR 14; hence the name. It
does not use SYSPRINT, SYSOUT, or SYSUDUMP.)
True, but they might yet have useful side effects, as in:

//STEP EXEC PGM=IEFBR14
//SYSPRINT DD DISP=(,CATLG),UNIT=SYSALLDA,DSN=&SYSUID..PRINT,SPACE=...

What's in a name?

-- gil


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2017-12-04 22:49:15 UTC
Reply
Permalink
Raw Message
I've also heard that there was some structural problem in IEFBR14 fixed via
APAR -- no comma on END or some such trivial thing that mostly didn't
matter but did in some linkedit cases. Anyone?
Post by Jesse 1 Robinson
So the simplest of all imaginable programs was once--according to
legend--subject to a PE APAR. In the original incarnation, there was only
one instruction, BR 14, leaving R15 as on entry. But R15 is generally taken
as a return code, so wild and unpredictable numbers were passed back to the
caller. The APAR added the instruction to zero R15.
As to whether IEFBR14 'uses' SYSUDUMP: is there any environment where some
kind of abend is utterly beyond the pale?
.
.
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
-----Original Message-----
Behalf Of Paul Gilmartin
Sent: Monday, December 04, 2017 8:31 AM
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
Post by Hobart Spitz
(For those who may not know, IEFBR14 is a null program that does
absolutely nothing; it allows you to use the side effects of DDs,
typically. The entire program is SR 15,15; BR 14; hence the name. It
does not use SYSPRINT, SYSOUT, or SYSUDUMP.)
//STEP EXEC PGM=IEFBR14
//SYSPRINT DD DISP=(,CATLG),UNIT=SYSALLDA,DSN=&SYSUID..PRINT,SPACE=...
What's in a name?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2017-12-05 19:29:03 UTC
Reply
Permalink
Raw Message
We were ESP for MVS in early 80's and found a few. No Eye-catcher, not RENT, RC .ne. 0. The IMS BMP's used to stub out to BR14 for development after XA started getting alignment errors with the call.
 
We didn't have time to investigate fully just put in CNOP(0,4) and it went away.
 
Later I remember some release of ESA we skipped-maybe 4.4 it was left out of the base completely. Last time I looked the eye-catcher had disappeared.
 
In a message dated 12/4/2017 4:50:40 PM Central Standard Time, ***@GMAIL.COM writes:

 
I've also heard that there was some structural problem in IEFBR14 fixed via
APAR -- no comma on END or some such trivial thing that mostly didn't
matter but did in some linkedit cases. Anyone?

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