Re: accessing a Unix file system DLL in MVS batch

[David Crayford]

I notice that your running Swift programs. I had a play when the beta 
first came out but the compile times were too slow for my liking. Has it 
improved?



On 17/11/2017 9:24 AM, Frank Swarbrick wrote:

While that is not exactly the answer, it lead me to find my answer.  Use 
CEEOPTS to define the LIBPATH environment variable.  Here's my working JCL:

//TEST JOB NOTIFY=,REGION=2000M
//JOBLIB   DD DISP=SHR,DSN=DVFJS.APPLIB.LOAD
// DD DISP=SHR,DSN=DVFJS.SWIFT.SCEERUN2
//GO   EXEC PGM=TESTPGM
//CEEOPTS  DD *
POSIX(ON)
ENVAR('LIBPATH=/u/dvfjs/lib')
/*
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*

TESTPGM, from DVFJS.APPLIB.LOAD executes and loads libtestDLL.dll from 
/u/dvfjs/lib.
Cool!  Thanks,
Frank



From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Thursday, November 16, 2017 5:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: accessing a Unix file system DLL in MVS batch

Yes. You need to set the LIBPATH environment variable to specify the
search path
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/bpxug93.htm.


On 17/11/2017 7:49 AM, Frank Swarbrick wrote:

Is it possible to invoke a program in JCL as EXEC PGM (the actual program name, 
not BPXBATCH et al) and have that program be able to load a DLL from the Unix 
file system?  I believe the answer (currently) is no, because it appears that 
JOBLIB/STEPLIB only works with PDS/PDSE libraries, but I want to make sure I'm 
not missing something.

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

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

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


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

Re: accessing a Unix file system DLL in MVS batch

[Frank Swarbrick]

While that is not exactly the answer, it lead me to find my answer.  Use 
CEEOPTS to define the LIBPATH environment variable.  Here's my working JCL:

//TEST JOB NOTIFY=,REGION=2000M
//JOBLIB   DD DISP=SHR,DSN=DVFJS.APPLIB.LOAD
// DD DISP=SHR,DSN=DVFJS.SWIFT.SCEERUN2
//GO   EXEC PGM=TESTPGM
//CEEOPTS  DD *
POSIX(ON)
ENVAR('LIBPATH=/u/dvfjs/lib')
/*
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*

TESTPGM, from DVFJS.APPLIB.LOAD executes and loads libtestDLL.dll from 
/u/dvfjs/lib.
Cool!  Thanks,
Frank



From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Thursday, November 16, 2017 5:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: accessing a Unix file system DLL in MVS batch

Yes. You need to set the LIBPATH environment variable to specify the
search path
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/bpxug93.htm.


On 17/11/2017 7:49 AM, Frank Swarbrick wrote:
> Is it possible to invoke a program in JCL as EXEC PGM (the actual program 
> name, not BPXBATCH et al) and have that program be able to load a DLL from 
> the Unix file system?  I believe the answer (currently) is no, because it 
> appears that JOBLIB/STEPLIB only works with PDS/PDSE libraries, but I want to 
> make sure I'm not missing something.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: accessing a Unix file system DLL in MVS batch

[David Crayford]

Yes. You need to set the LIBPATH environment variable to specify the 
search path 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/bpxug93.htm.



On 17/11/2017 7:49 AM, Frank Swarbrick wrote:

Is it possible to invoke a program in JCL as EXEC PGM (the actual program name, 
not BPXBATCH et al) and have that program be able to load a DLL from the Unix 
file system?  I believe the answer (currently) is no, because it appears that 
JOBLIB/STEPLIB only works with PDS/PDSE libraries, but I want to make sure I'm 
not missing something.

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


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

accessing a Unix file system DLL in MVS batch

[Frank Swarbrick]

Is it possible to invoke a program in JCL as EXEC PGM (the actual program name, 
not BPXBATCH et al) and have that program be able to load a DLL from the Unix 
file system?  I believe the answer (currently) is no, because it appears that 
JOBLIB/STEPLIB only works with PDS/PDSE libraries, but I want to make sure I'm 
not missing something.

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

Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

[Steve Horein]

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.

On Thu, Nov 16, 2017 at 3:30 PM, Jesse 1 Robinson 
wrote:

> 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
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, November 16, 2017 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.
>
> On 2017-11-16, at 06:48:09, Hobart Spitz wrote:
>
> Cross posted to IBM-MAIN:
> >
> > 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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff 

Re: Discussion List for IBM Connect:Direct?

[Ward, Mike S]

Make sure you have the correct simultaneous connections configured correctly, 
unless you have the unlimited license. They can get you real easy in an audit.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sasso, Leonard
Sent: Thursday, November 16, 2017 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Discussion List for IBM Connect:Direct?

Hi !

Just curious, is there a Discussion List for IBM Connect:Direct?


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More
RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn 
CSRA Think Next. Now.


This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

[Jesse 1 Robinson]

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, November 16, 2017 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

On 2017-11-16, at 06:48:09, Hobart Spitz wrote:

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

Re: Discussion List for IBM Connect:Direct?

[Steve Thompson]

Yes there is, kind of, on Linked In. There are a few MFT groups, 
an IBM Connect:Direct group, and a non-Connect:Direct group.


If you use the NON-C:D group, you will probably get a lot of 
people asking to connect with you, so they can market you to death.


Regards,
Steve Thompson

On 11/16/2017 12:41 PM, Sasso, Leonard wrote:

Hi !

Just curious, is there a Discussion List for IBM Connect:Direct?


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More
RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.


This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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



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

Re: TSSO vs. System REXX for a "new user who is poor".

[Lizette Koehler]

Just a reminder

Description: In z/OS V1R12, the DDDEF'd PARMLIB provides an AUTOR00 member. 
This member should be found in your parmlib concatenation during IPL and will 
result in auto-reply processing being activated. If the WTORs listed in AUTOR00 
are automated by your existing automation product, ensure that the replies in 
AUTOR00 are appropriate.

So, if you specify it within the PARMLIB concatenation and will not intend to 
activate the auto reply functionality, you need to specify AUTOR=OFF in the 
IEASYSxx parmlib member.

There may be other new functions that could augment TSSO

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nims,Alva John (Al)
> Sent: Thursday, November 16, 2017 10:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TSSO vs. System REXX for a "new user who is poor".
> 
> We use CBTTAPE.org's File 019's COMMAND program for both start up and
> shutdown.  COMMAND can respond to outstanding replies, test to see if a task
> is up or down and several more, it a very simple system.
> 
> Al Nims
> Systems Admin/Programmer 3
> UFIT
> University of Florida
> (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Thursday, November 16, 2017 12:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TSSO vs. System REXX for a "new user who is poor".
> 
> I don't really know if that is a good subject line or not. And it, for once,
> does not apply to my company, we use CA-OPS/MVS and like it.
> 
> There is an MPFLST program out there, MPF2REXX, which can be used with the
> MPFLST (natch!) to run System REXX for automation purposes. There is also the
> venerable TSSO system which can be used for this (and maybe more?).
> Now, "venerable" is a _good_ word.  I gather that TSSO has a number of users.
> It has been around for a fairly long time, and has kept up with the newer
> releases of z/OS. So it is most likely well debugged. On the other hand, it
> has some "crufty" code. One example is a "hard coded" allocation of
> SYS1.PARMLIB for its configuration member (TSSOPARM). Now, when a friend of
> mine told me about this latter, I decided that it might be "fun" to see if I
> could fix it. I am working on that, using IEFPRMLB.
> 
> While doing the above, I did notice the aforementioned venerable, but crufty,
> code. So I got to wondering if it would be worth the time and effort to
> "spruce up" TSSO's internals. This means having it basically do the same
> thing, externally, but with (what I consider) more current internals. An
> example would be for the TSSO initialization to dynamically add it's
> subsystem if it were not in the IEFSSNnn member at IPL time. I would also,
> due to OCD, would likely convert code like "  L R1,0(R2) " to "
> L R1,0(,R2)" I.e. move the register from the index register position to the
> base register position. "Just because".
> 
> Or would it basically just be a waste of time in which I could be doing
> "other important work". Such as napping.
> 
> Just curious about people's opinions.
> 
> --
> I have a theory that it's impossible to prove anything, but I can't prove it.
> 
> Maranatha! <><
> John McKown
> 

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

Re: Discussion List for IBM Connect:Direct?

[Karl S Huf]

Not aware of any listserv types for it but there is a forum over at IBM
DeveloperWorks.



___
Karl S Huf | Senior Vice President | World Wide Technology
50 S LaSalle St, LQ-18, Chicago, IL  60603 | phone (312)630-6287 |
k...@ntrs.com
Please visit northerntrust.com
CONFIDENTIALITY NOTICE: This communication is confidential, may be
privileged and is meant only for the intended recipient. If you are not
the intended recipient, please notify the sender ASAP and delete this
message from your system.  NTAC:3NS-20

P Please consider the environment before printing this e-mail.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Sasso, Leonard
> Sent: Thursday, November 16, 2017 11:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXT] Discussion List for IBM Connect:Direct?
>
> Hi !
>
> Just curious, is there a Discussion List for IBM Connect:Direct?
>
>
> Thank You,
> Len Sasso
> System Administrator
> TEAM: Together Everyone Achieves More
> RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
> t: +1.518.257.4209 | m: +1.518.894.0879
> len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter |
> LinkedIn CSRA Think Next. Now.
>
>
> This electronic message transmission contains information from CSRA
that
> may be attorney-client privileged, proprietary or confidential. The
information
> in this message is intended only for use by the individual(s) to whom
it is
> addressed. If you believe you have received this message in error,
please
> contact me immediately and be aware that any use, disclosure, copying
or
> distribution of the contents of this message is strictly prohibited.
NOTE:
> Regardless of content, this email shall not operate to bind CSRA to
any order
> or other contract unless pursuant to explicit written agreement or
government
> initiative expressly permitting the use of email for such purpose.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: Discussion List for IBM Connect:Direct?

[Lester, Bob]

Hi Leonard,

 I can't help with the XCOM part, as I've never used it.

 However, I've been running Connect:Direct since the Sterling Labs days.

 Feel free to reach out (off-list if you prefer) for C:D questions.  I'm 
sure there are others on this list that know more about it than I, and probably 
know XCOM as well!

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sasso, Leonard
Sent: Thursday, November 16, 2017 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Discussion List for IBM Connect:Direct? [ EXTERNAL ]

We (CSRA) are migrating from CA-XCOM to IBM C:D, so I am new to the product.

Is there anything we should be aware of? 

I'm currently working on converting our Production Batch File Transfer Jobs to 
use C:D, instead of XCOM.


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More

RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn 
CSRA Think Next. Now.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Thursday, November 16, 2017 1:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Discussion List for IBM Connect:Direct?

Hi Leonard,

 Not sure, but several users of C:D hang out on this list.  I'm one.

 Have a question?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sasso, Leonard
Sent: Thursday, November 16, 2017 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Discussion List for IBM Connect:Direct? [ EXTERNAL ]

Hi !

Just curious, is there a Discussion List for IBM Connect:Direct?


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More
RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn 
CSRA Think Next. Now.


This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.

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

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

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

Re: TSSO vs. System REXX for a "new user who is poor".

[John McKown]

On Thu, Nov 16, 2017 at 12:02 PM, Dana Mitchell  wrote:

> John,
>
> Has TSSO been updated to keep up with z/OS?  In the past we were using it,
> but at the time the console restructure effectively 'broke' it in approx
> z/OS 1.11 or perhaps 1.13?
>

​Well, I can say that release 4.3 (which is current on the CBTtape.org
site) is running on a z/OS 2.3 system at this time.​ I don't know what all
it is really doing, not being a TSSO person, but it is running.


>
> Dana
>
>
-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Discussion List for IBM Connect:Direct?

[Sasso, Leonard]

We (CSRA) are migrating from CA-XCOM to IBM C:D, so I am new to the product.

Is there anything we should be aware of? 

I'm currently working on converting our Production Batch File Transfer Jobs to 
use C:D, instead of XCOM.


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More

RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Thursday, November 16, 2017 1:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Discussion List for IBM Connect:Direct?

Hi Leonard,

 Not sure, but several users of C:D hang out on this list.  I'm one.

 Have a question?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sasso, Leonard
Sent: Thursday, November 16, 2017 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Discussion List for IBM Connect:Direct? [ EXTERNAL ]

Hi !

Just curious, is there a Discussion List for IBM Connect:Direct?


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More
RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn 
CSRA Think Next. Now.


This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.

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

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

Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

[Paul Gilmartin]

On 2017-11-16, at 06:48:09, Hobart Spitz wrote:

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

Re: Discussion List for IBM Connect:Direct?

[Lester, Bob]

Hi Leonard,

 Not sure, but several users of C:D hang out on this list.  I'm one.

 Have a question?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sasso, Leonard
Sent: Thursday, November 16, 2017 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Discussion List for IBM Connect:Direct? [ EXTERNAL ]

Hi !

Just curious, is there a Discussion List for IBM Connect:Direct?


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More
RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn 
CSRA Think Next. Now.


This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.

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

Re: TSSO vs. System REXX for a "new user who is poor".

[Dana Mitchell]

John,

Has TSSO been updated to keep up with z/OS?  In the past we were using it, but 
at the time the console restructure effectively 'broke' it in approx z/OS 1.11 
or perhaps 1.13? 

Dana

On Thu, 16 Nov 2017 11:33:22 -0600, John McKown  
wrote:

>
>There is also
>the venerable TSSO system which can be used for this (and maybe more?).
>Now, "venerable" is a _good_ word.  I gather that TSSO has a number of
>users. It has been around for a fairly long time, and has kept up with the
>newer releases of z/OS.

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

Re: TSSO vs. System REXX for a "new user who is poor".

[Nims,Alva John (Al)]

We use CBTTAPE.org's File 019's COMMAND program for both start up and shutdown. 
 COMMAND can respond to outstanding replies, test to see if a task is up or 
down and several more, it a very simple system. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, November 16, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TSSO vs. System REXX for a "new user who is poor".

I don't really know if that is a good subject line or not. And it, for once, 
does not apply to my company, we use CA-OPS/MVS and like it.

There is an MPFLST program out there, MPF2REXX, which can be used with the 
MPFLST (natch!) to run System REXX for automation purposes. There is also the 
venerable TSSO system which can be used for this (and maybe more?).
Now, "venerable" is a _good_ word.  I gather that TSSO has a number of users. 
It has been around for a fairly long time, and has kept up with the newer 
releases of z/OS. So it is most likely well debugged. On the other hand, it has 
some "crufty" code. One example is a "hard coded" allocation of SYS1.PARMLIB 
for its configuration member (TSSOPARM). Now, when a friend of mine told me 
about this latter, I decided that it might be "fun" to see if I could fix it. I 
am working on that, using IEFPRMLB.

While doing the above, I did notice the aforementioned venerable, but crufty, 
code. So I got to wondering if it would be worth the time and effort to "spruce 
up" TSSO's internals. This means having it basically do the same thing, 
externally, but with (what I consider) more current internals. An example would 
be for the TSSO initialization to dynamically add it's subsystem if it were not 
in the IEFSSNnn member at IPL time. I would also, due to OCD, would likely 
convert code like "  L R1,0(R2) " to "
L R1,0(,R2)" I.e. move the register from the index register position to the 
base register position. "Just because".

Or would it basically just be a waste of time in which I could be doing "other 
important work". Such as napping.

Just curious about people's opinions.

--
I have a theory that it's impossible to prove anything, but I can't prove it.

Maranatha! <><
John McKown

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

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

Discussion List for IBM Connect:Direct?

[Sasso, Leonard]

Hi !

Just curious, is there a Discussion List for IBM Connect:Direct?


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More
RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.


This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

TSSO vs. System REXX for a "new user who is poor".

[John McKown]

I don't really know if that is a good subject line or not. And it, for
once, does not apply to my company, we use CA-OPS/MVS and like it.

There is an MPFLST program out there, MPF2REXX, which can be used with the
MPFLST (natch!) to run System REXX for automation purposes. There is also
the venerable TSSO system which can be used for this (and maybe more?).
Now, "venerable" is a _good_ word.  I gather that TSSO has a number of
users. It has been around for a fairly long time, and has kept up with the
newer releases of z/OS. So it is most likely well debugged. On the other
hand, it has some "crufty" code. One example is a "hard coded" allocation
of SYS1.PARMLIB for its configuration member (TSSOPARM). Now, when a friend
of mine told me about this latter, I decided that it might be "fun" to see
if I could fix it. I am working on that, using IEFPRMLB.

While doing the above, I did notice the aforementioned venerable, but
crufty, code. So I got to wondering if it would be worth the time and
effort to "spruce up" TSSO's internals. This means having it basically do
the same thing, externally, but with (what I consider) more current
internals. An example would be for the TSSO initialization to dynamically
add it's subsystem if it were not in the IEFSSNnn member at IPL time. I
would also, due to OCD, would likely convert code like "  L R1,0(R2) " to "
L R1,0(,R2)" I.e. move the register from the index register position to the
base register position. "Just because".

Or would it basically just be a waste of time in which I could be doing
"other important work". Such as napping.

Just curious about people's opinions.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: [EXTERNAL] Re: Pipelines in the z/OS base.

[J R]

That's pretty standard for any CP whose I/O is not specifically intended for 
terminal management. 

> On Nov 16, 2017, at 09:04, John McKown  wrote:
> 
> ​Looking at the above, I can see that, if such were implemented, it would
> probably have a requirement that the TSO command whose output is being
> piped would need to use the "putline" (or SAM) interface and not do TPUTs
> or TPGs for it's output. ​

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

Re: [EXTERNAL] Re: Pipelines in the z/OS base.

[Lizette Koehler]

This RFE was submitted through Share to IBM RFE:

DESCRIPT : A facility equivalent to the CMS PIPES product should be added to 
TSO. PIPES allows the output of one TSO command to be directed as input to 
another TSO command and the output from that command can be directed to the 
next ... etc.  

It is in 
Uncommitted Candidate: This request may not be delivered within the release 
currently under development, but the theme is aligned with the current 
multi-year strategy. IBM may consider and evaluate any RFE Community feedback 
for this request through activities such as voting. IBM will update this 
request in the future.




>From the comments section:


Total comments (5)

z/OS NetView has support for PIPEs that is extremely useful but they are sadly 
lacking from TSO/E.

Posted by MikeBike on 31 Mar 2017

Report abuse

Being a z/VM-er, forced to work on z/OS, I miss the functionality provided by 
CMS/TSO Pipes.
I have the told CMS/TSO Pipes code available, and that is a huge productivity 
booster, but the more recent (last couple of decades) enhancements are 
seriously lacking, requiring often to recreate "standard" functions in private 
REXX stages.
So getting a supported TSO/Pipes at the z/VM 6.4 level would be really 
appreciated...

Posted by Ronald van der Laan on 7 Jul 2016

Report abuse

This requirement has been outstanding for more than 25 years.  Clearly, support 
for this requirement is forthcoming from the TSO user community.  

One of the earliest SHARE presentations was SHARE 92 February 1990 "Plumbers 
Who Use TSO and the Users Who Love Them:  An Introduction to TSO Pipelines", 
Session 2873, Hobart Spitz, Paine Webber.  

"Plumbers Who Dump CVTs and the Control Blocks that Love Them:  MVS/TSO 
Pipelines for Systems Programmers", SHARE February 1999, Session 2875, Hobart 
Spitz, Paine Webber

"Two Dimensional Pipes:  How CMS Pipelines Differs from UNIX Pipes", SHARE 97, 
Summer 2001, Session 9109, Marty Zimelis, Computer Associates


Posted by WilliamJ.Smith on 20 May 2016

Report abuse

This addition to the base z/OS environment would significantly improve the 
productivity of those developing and delivery extensions and enhancements to 
the platform. We know the code is available and that it isn't effectively 
marketed. Since it is apparently stable why not integrate it and ship if for 
free.

Posted by LionelB.Dyck on 19 May 2016



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hobart Spitz
> Sent: Thursday, November 16, 2017 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Pipelines in the z/OS base.
> 
> If permitted by policy, could someone post the text of RFE 47699, for those
> who don't have IBM ids?
> 
> On Thu, Nov 16, 2017 at 8:56 AM, Dyck, Lionel B. (TRA) 
> wrote:
> 
> > See RFE 47699 at https://www.ibm.com/developerworks/rfe/execute?
> > use_case=viewRfe_ID=47699
> >
> > Currently sitting at 140 Votes and at #19 on the overall vote count.
> >
> > --
> > 
> > Lionel B. Dyck <
> > Mainframe Systems Programmer - TRA
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lucas Rosalen
> > Sent: Thursday, November 16, 2017 7:49 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: Pipelines in the z/OS base.
> >
> > Hello Hobart,
> >
> > Do you have any RFE already opened for that? I would surely vote for
> > it (plus this might be a good place to broadcast its ref. number)!
> >
> > Thanks, Lucas
> >
> > On Nov 16, 2017 14:36, "Hobart Spitz"  wrote:
> >
> > Someone on TSO-REXX wrote:
> > > Yes and if IBM would give us PIPES (BatchPipesWorks Product) then
> > > you can
> > use PIPE to read from a file into a STEM or STACK and vice-versa.
> >
> > There have been other such posts.
> >
> > For those who don't know TSO PIPEs is like an assembly line with
> > reusable, standardized stations.  (You can create your own, on the fly
> > even.)
> >
> > IMHO, making TSO PIPEs part of the z/OS base is long, long overdue.
> > Over the last 20 years, I have been associated with two requirements
> > for Pipes in the OS base that have been submitted at SHARE, but which
> > produced no results.  I have it on good authority that that if you
> > take all the requests for TSO Pipelines, sort in REXX, and other
> > requirements addressed by TSO PIPEs, that there would be about 75% positive
> RFE votes.
> >
> > Background on the term "piping":
> >
> > 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 

Re: [EXTERNAL] Re: Pipelines in the z/OS base.

[John McKown]

On Thu, Nov 16, 2017 at 7:58 AM, Hobart Spitz  wrote:

> If permitted by policy, could someone post the text of RFE 47699, for those
> who don't have IBM ids?
>
> ​
> DESCRIPT : A facility equivalent to the CMS PIPES product should be added
> to TSO. PIPES allows the output of one TSO command to be directed as input
> to another TSO command and the output from that command can be directed to
> the next ... etc. TimeLimit: N/A


​Looking at the above, I can see that, if such were implemented, it would
probably have a requirement that the TSO command whose output is being
piped would need to use the "putline" (or SAM) interface and not do TPUTs
or TPGs for it's output. ​


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: [EXTERNAL] Re: Pipelines in the z/OS base.

[Hobart Spitz]

If permitted by policy, could someone post the text of RFE 47699, for those
who don't have IBM ids?

On Thu, Nov 16, 2017 at 8:56 AM, Dyck, Lionel B. (TRA) 
wrote:

> See RFE 47699 at https://www.ibm.com/developerworks/rfe/execute?
> use_case=viewRfe_ID=47699
>
> Currently sitting at 140 Votes and at #19 on the overall vote count.
>
> --
> Lionel B. Dyck <
> Mainframe Systems Programmer - TRA
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lucas Rosalen
> Sent: Thursday, November 16, 2017 7:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Pipelines in the z/OS base.
>
> Hello Hobart,
>
> Do you have any RFE already opened for that? I would surely vote for it
> (plus this might be a good place to broadcast its ref. number)!
>
> Thanks, Lucas
>
> On Nov 16, 2017 14:36, "Hobart Spitz"  wrote:
>
> Someone on TSO-REXX wrote:
> > Yes and if IBM would give us PIPES (BatchPipesWorks Product) then you
> > can
> use PIPE to read from a file into a STEM or STACK and vice-versa.
>
> There have been other such posts.
>
> For those who don't know TSO PIPEs is like an assembly line with reusable,
> standardized stations.  (You can create your own, on the fly even.)
>
> IMHO, making TSO PIPEs part of the z/OS base is long, long overdue.  Over
> the last 20 years, I have been associated with two requirements for Pipes
> in the OS base that have been submitted at SHARE, but which produced no
> results.  I have it on good authority that that if you take all the
> requests for TSO Pipelines, sort in REXX, and other requirements addressed
> by TSO PIPEs, that there would be about 75% positive RFE votes.
>
> Background on the term "piping":
>
> 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.
>
> CMS/TSO Pipelines does piping somewhat like this and much more.  Once
> difference is that data doesn't have to move, record descriptors do that
> job for unchanged records.
>
> I was first exposed to this concept, when I was supporting a team of
> previously UNIX-based developers working on TSO for the first time.  One of
> the team came to me and asked how to connect the output of one program to
> the input of the next in JCL.  On the whiteboard, I proceeded to write the
> JCL for creating a temporary dataset in one job step (DD with DSN, UNIT,
> DCB, DISP, etc.) and the JCL to read that dataset in the next job step.
> When I turned around, the questioner was gone.  A short time later, his
> officemate came in with the same question.  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.
>
> For those that may not know:
>
>- TSO PIPEs implements dynamic, record-level, deterministic piping that
>is significantly more advanced than that on UNIX, Linux, and USS.
> (More on
>that below.)
>- If installed, TSO PIPEs can be used by invoking the "pipe": command
>anywhere that a TSO command can be used, including:  READY Prompt, ISPF
>option 6, ISPF command line with the TSO prefix, REXX EXECs, CLISTs, TSO
>batch, and the ISPF service "select cmd(pipe ... )".
>- PIPEs is part of the z/VM base but is optional under z/OS.  Hence this
>post.
>- TSO PIPEs, TSO Pipelines, and BatchPipesWorks, are all names for
>essentially the same product, which is roughly a subset of CMS Pipes.
> (My
>understanding is that TSO PIPEs is not the same as the USS command
> "pipe";
>you need to direct the command to TSO.)
>- Under z/VM, and under z/OS where available, it is well integrated into
>both environments.
>- On a very high-level conceptual level, PIPEs are somewhat similar to
>SQL and 4GLs in that many common, low level processing details (such as
>initialization, looping, and end of data) are taken care of internally.
>Thus, many types of selections, matchings, transformations, etc. can be
>done with compact commands and frequently without convention
> programming in
>languages like COBOL, PL/I, and C/C++.   (It is different from SQL and
> 4GLs
>in that Pipes can process many kinds of data, not just one type of data
> or
>source.)
>- PIPEs can read both USS text and most binary files and can convert
>them to record 

Re: [EXTERNAL] Re: Pipelines in the z/OS base.

[Dyck, Lionel B. (TRA)]

See RFE 47699 at 
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699

Currently sitting at 140 Votes and at #19 on the overall vote count.

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: Thursday, November 16, 2017 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Pipelines in the z/OS base.

Hello Hobart,

Do you have any RFE already opened for that? I would surely vote for it (plus 
this might be a good place to broadcast its ref. number)!

Thanks, Lucas

On Nov 16, 2017 14:36, "Hobart Spitz"  wrote:

Someone on TSO-REXX wrote:
> Yes and if IBM would give us PIPES (BatchPipesWorks Product) then you 
> can
use PIPE to read from a file into a STEM or STACK and vice-versa.

There have been other such posts.

For those who don't know TSO PIPEs is like an assembly line with reusable, 
standardized stations.  (You can create your own, on the fly even.)

IMHO, making TSO PIPEs part of the z/OS base is long, long overdue.  Over the 
last 20 years, I have been associated with two requirements for Pipes in the OS 
base that have been submitted at SHARE, but which produced no results.  I have 
it on good authority that that if you take all the requests for TSO Pipelines, 
sort in REXX, and other requirements addressed by TSO PIPEs, that there would 
be about 75% positive RFE votes.

Background on the term "piping":

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.

CMS/TSO Pipelines does piping somewhat like this and much more.  Once 
difference is that data doesn't have to move, record descriptors do that job 
for unchanged records.

I was first exposed to this concept, when I was supporting a team of previously 
UNIX-based developers working on TSO for the first time.  One of the team came 
to me and asked how to connect the output of one program to the input of the 
next in JCL.  On the whiteboard, I proceeded to write the JCL for creating a 
temporary dataset in one job step (DD with DSN, UNIT, DCB, DISP, etc.) and the 
JCL to read that dataset in the next job step.
When I turned around, the questioner was gone.  A short time later, his 
officemate came in with the same question.  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.

For those that may not know:

   - TSO PIPEs implements dynamic, record-level, deterministic piping that
   is significantly more advanced than that on UNIX, Linux, and USS.  (More on
   that below.)
   - If installed, TSO PIPEs can be used by invoking the "pipe": command
   anywhere that a TSO command can be used, including:  READY Prompt, ISPF
   option 6, ISPF command line with the TSO prefix, REXX EXECs, CLISTs, TSO
   batch, and the ISPF service "select cmd(pipe ... )".
   - PIPEs is part of the z/VM base but is optional under z/OS.  Hence this
   post.
   - TSO PIPEs, TSO Pipelines, and BatchPipesWorks, are all names for
   essentially the same product, which is roughly a subset of CMS Pipes.
(My
   understanding is that TSO PIPEs is not the same as the USS command "pipe";
   you need to direct the command to TSO.)
   - Under z/VM, and under z/OS where available, it is well integrated into
   both environments.
   - On a very high-level conceptual level, PIPEs are somewhat similar to
   SQL and 4GLs in that many common, low level processing details (such as
   initialization, looping, and end of data) are taken care of internally.
   Thus, many types of selections, matchings, transformations, etc. can be
   done with compact commands and frequently without convention programming in
   languages like COBOL, PL/I, and C/C++.   (It is different from SQL and
4GLs
   in that Pipes can process many kinds of data, not just one type of data or
   source.)
   - PIPEs can read both USS text and most binary files and can convert
   them to record orientation (address plus length descriptors).
   - PIPEs can also be invoked from JCL thusly:  //   EXEC
PGM=PIPE,PARM='< IN.FILE|SORT|> OUT.FILE'

PIPEs in the z/OS base would greatly improve the competitiveness of mainframe 
systems, while cutting development, hardware and support costs for IBM, 
third-parties and customers.  By having Pipes 

Re: Pipelines in the z/OS base.

[Lucas Rosalen]

Hello Hobart,

Do you have any RFE already opened for that? I would surely vote for it
(plus this might be a good place to broadcast its ref. number)!

Thanks, Lucas

On Nov 16, 2017 14:36, "Hobart Spitz"  wrote:

Someone on TSO-REXX wrote:
> Yes and if IBM would give us PIPES (BatchPipesWorks Product) then you can
use PIPE to read from a file into a STEM or STACK and vice-versa.

There have been other such posts.

For those who don't know TSO PIPEs is like an assembly line with reusable,
standardized stations.  (You can create your own, on the fly even.)

IMHO, making TSO PIPEs part of the z/OS base is long, long overdue.  Over
the last 20 years, I have been associated with two requirements for Pipes
in the OS base that have been submitted at SHARE, but which produced no
results.  I have it on good authority that that if you take all the
requests for TSO Pipelines, sort in REXX, and other requirements addressed
by TSO PIPEs, that there would be about 75% positive RFE votes.

Background on the term "piping":

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.

CMS/TSO Pipelines does piping somewhat like this and much more.  Once
difference is that data doesn't have to move, record descriptors do that
job for unchanged records.

I was first exposed to this concept, when I was supporting a team of
previously UNIX-based developers working on TSO for the first time.  One of
the team came to me and asked how to connect the output of one program to
the input of the next in JCL.  On the whiteboard, I proceeded to write the
JCL for creating a temporary dataset in one job step (DD with DSN, UNIT,
DCB, DISP, etc.) and the JCL to read that dataset in the next job step.
When I turned around, the questioner was gone.  A short time later, his
officemate came in with the same question.  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.

For those that may not know:

   - TSO PIPEs implements dynamic, record-level, deterministic piping that
   is significantly more advanced than that on UNIX, Linux, and USS.  (More
on
   that below.)
   - If installed, TSO PIPEs can be used by invoking the "pipe": command
   anywhere that a TSO command can be used, including:  READY Prompt, ISPF
   option 6, ISPF command line with the TSO prefix, REXX EXECs, CLISTs, TSO
   batch, and the ISPF service "select cmd(pipe ... )".
   - PIPEs is part of the z/VM base but is optional under z/OS.  Hence this
   post.
   - TSO PIPEs, TSO Pipelines, and BatchPipesWorks, are all names for
   essentially the same product, which is roughly a subset of CMS Pipes.
(My
   understanding is that TSO PIPEs is not the same as the USS command
"pipe";
   you need to direct the command to TSO.)
   - Under z/VM, and under z/OS where available, it is well integrated into
   both environments.
   - On a very high-level conceptual level, PIPEs are somewhat similar to
   SQL and 4GLs in that many common, low level processing details (such as
   initialization, looping, and end of data) are taken care of internally.
   Thus, many types of selections, matchings, transformations, etc. can be
   done with compact commands and frequently without convention programming
in
   languages like COBOL, PL/I, and C/C++.   (It is different from SQL and
4GLs
   in that Pipes can process many kinds of data, not just one type of data
or
   source.)
   - PIPEs can read both USS text and most binary files and can convert
   them to record orientation (address plus length descriptors).
   - PIPEs can also be invoked from JCL thusly:  //   EXEC
PGM=PIPE,PARM='< IN.FILE|SORT|> OUT.FILE'

PIPEs in the z/OS base would greatly improve the competitiveness of
mainframe systems, while cutting development, hardware and support costs
for IBM, third-parties and customers.  By having Pipes available to all
internal and external developers, efficiency and productivity would
improve.  This would help IBM competitiveness and bottom line, as well as
that of mainframe sites, and software vendors.  If you've been following
IBM after quarterly reports are covered in the news, you'll know that IBM
needs a shot in the arm like this.  Results have been poor for many
quarters.  Over the long term it would mean improved profitability for the
entire mainframe division.  There might even be IBM customers who are saved
from moving off mainframes (because of 

Pipelines in the z/OS base.

[Hobart Spitz]

Someone on TSO-REXX wrote:
> Yes and if IBM would give us PIPES (BatchPipesWorks Product) then you can
use PIPE to read from a file into a STEM or STACK and vice-versa.

There have been other such posts.

For those who don't know TSO PIPEs is like an assembly line with reusable,
standardized stations.  (You can create your own, on the fly even.)

IMHO, making TSO PIPEs part of the z/OS base is long, long overdue.  Over
the last 20 years, I have been associated with two requirements for Pipes
in the OS base that have been submitted at SHARE, but which produced no
results.  I have it on good authority that that if you take all the
requests for TSO Pipelines, sort in REXX, and other requirements addressed
by TSO PIPEs, that there would be about 75% positive RFE votes.

Background on the term "piping":

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.

CMS/TSO Pipelines does piping somewhat like this and much more.  Once
difference is that data doesn't have to move, record descriptors do that
job for unchanged records.

I was first exposed to this concept, when I was supporting a team of
previously UNIX-based developers working on TSO for the first time.  One of
the team came to me and asked how to connect the output of one program to
the input of the next in JCL.  On the whiteboard, I proceeded to write the
JCL for creating a temporary dataset in one job step (DD with DSN, UNIT,
DCB, DISP, etc.) and the JCL to read that dataset in the next job step.
When I turned around, the questioner was gone.  A short time later, his
officemate came in with the same question.  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.

For those that may not know:

   - TSO PIPEs implements dynamic, record-level, deterministic piping that
   is significantly more advanced than that on UNIX, Linux, and USS.  (More on
   that below.)
   - If installed, TSO PIPEs can be used by invoking the "pipe": command
   anywhere that a TSO command can be used, including:  READY Prompt, ISPF
   option 6, ISPF command line with the TSO prefix, REXX EXECs, CLISTs, TSO
   batch, and the ISPF service "select cmd(pipe ... )".
   - PIPEs is part of the z/VM base but is optional under z/OS.  Hence this
   post.
   - TSO PIPEs, TSO Pipelines, and BatchPipesWorks, are all names for
   essentially the same product, which is roughly a subset of CMS Pipes.  (My
   understanding is that TSO PIPEs is not the same as the USS command "pipe";
   you need to direct the command to TSO.)
   - Under z/VM, and under z/OS where available, it is well integrated into
   both environments.
   - On a very high-level conceptual level, PIPEs are somewhat similar to
   SQL and 4GLs in that many common, low level processing details (such as
   initialization, looping, and end of data) are taken care of internally.
   Thus, many types of selections, matchings, transformations, etc. can be
   done with compact commands and frequently without convention programming in
   languages like COBOL, PL/I, and C/C++.   (It is different from SQL and 4GLs
   in that Pipes can process many kinds of data, not just one type of data  or
   source.)
   - PIPEs can read both USS text and most binary files and can convert
   them to record orientation (address plus length descriptors).
   - PIPEs can also be invoked from JCL thusly:  //   EXEC
PGM=PIPE,PARM='< IN.FILE|SORT|> OUT.FILE'

PIPEs in the z/OS base would greatly improve the competitiveness of
mainframe systems, while cutting development, hardware and support costs
for IBM, third-parties and customers.  By having Pipes available to all
internal and external developers, efficiency and productivity would
improve.  This would help IBM competitiveness and bottom line, as well as
that of mainframe sites, and software vendors.  If you've been following
IBM after quarterly reports are covered in the news, you'll know that IBM
needs a shot in the arm like this.  Results have been poor for many
quarters.  Over the long term it would mean improved profitability for the
entire mainframe division.  There might even be IBM customers who are saved
from moving off mainframes (because of costs) by such a move.  In short,
making PIPEs part of the z/OS base would more than pay for itself in
reduced costs, retained customers, and additional sales.  If I were an IBM
stockholder, a manager at a mainframe customer, or part 

Re: Preliminary query about mainframe "environmentals"

[Tom Mathias]

Rob,

The other environmentals can also be exported.  

Tom Mathias

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