Re: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)

[Paul Gilmartin]

On Sun, 19 Sep 2021 11:53:18 -0500, Hobart Spitz wrote:
>...
>Concerning EXECIO:
>   - Pipes can read from or write to either a DD or a dataset.  z/OS EXECIO
>   can only use a DD.
>  
o Can that DD be allocated to a UNIX file, with FILEDATA any of BINARY, TEXT, 
or RECORD?
o Is it savvy to files tagged with FILEDATA and/or CCSID?
o Does it restrict concurrent use of UNIX files as ISPF does?:
  


>... -   I would be glad to
>   hear from someone knowledgeable that I'm wrong on this and that I missed
>   some access method change that has made the concern unnecessary.
>
As I mentioned earlier, the SPFEDIT member ENQs with DISP=SHR
avoid the need to lock an entire PDS in order to update a single member:


>   - Pipes lets you read member(s) through a DD and names(s) specified in
>   the pipe stage or by feeding member names to certain stages. 
>   you must put the member name on the allocation.  If you've ever read a
>   large number of members from a PDS/E 
>
Does this support mixed concatenations of PDS, PDSE and UNIX directories?
(It should.  This is intrinsic to  BPAM.)  What happens if the UNIX files have
unlike tags?

Does Pipelines support the "other side" of DDNAMEs?  I.e. can Pipelines
output connectors be associated with input DDs of Classic utilities such as
OLD and NEW of ISRSUPC, or SYSUT2 of an arbitrary Classic utility be
associated with a Pipeline input cnonector.  I could do this with a Rube
Goldberg of SYSCALL PIPE, BPXWDYN, SYSCALL SPAWN,  ...
It would be nice to have it in an opaque package.

-- gil

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

Re: registration problem

[Paul Gilmartin]

On Sun, 19 Sep 2021 13:58:01 -0700, Skip Robinson wrote:

>This is my first post since leaving SCE. When I left, I had to give up my
>laptop and all files. So yesterday I set about reestablishing myself on
>IBM-MAIN. I took a lot of tries, but I think I got it right.
> 
Welcome  back.

>While at SCE, I had trouble with IBM-MAIN setup. Folks on the List
>explained that some shops do not handle LISTSERV headers properly. I never
>could get SCE mail folks to support the registration process properly.
>Hence I went as 'Jesse' despite my attempts to change it to 'Skip'. If new
>users are having trouble, I suggest looking at the local LISTSTERV setup,
>which may have changed since working veterans were established long ago.
> 
I remember 'Skip'.

I'd like to view the LISTSERV via either desktop or handheld with different 
display
settings.  Alas, when I change tie View on one it instantly propagates to the
other.  I'd prefer that view-related settings were stored locally in a cookie 
rather
than on the server.  Or in a table keyed by the client ID.

-- gil

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

Re: registration problem

[Skip Robinson]

This is my first post since leaving SCE. When I left, I had to give up my
laptop and all files. So yesterday I set about reestablishing myself on
IBM-MAIN. I took a lot of tries, but I think I got it right.

While at SCE, I had trouble with IBM-MAIN setup. Folks on the List
explained that some shops do not handle LISTSERV headers properly. I never
could get SCE mail folks to support the registration process properly.
Hence I went as 'Jesse' despite my attempts to change it to 'Skip'. If new
users are having trouble, I suggest looking at the local LISTSTERV setup,
which may have changed since working veterans were established long ago.

On Sat, Sep 18, 2021 at 7:08 PM Matt Hogstrom  wrote:

> When you register you get an e-mail with instructions to use the list IIRC
> … including searching the archives
>
> Matt Hogstrom
> PGP key 0F143BC1
>
> > On Sep 18, 2021, at 22:01, Seymour J Metz  wrote:
> >
> > The easiest way to subscribe is to send a subscribe request to the
> address at the bottom of every post. Of course, that's not enough if you
> also want to view the archive.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of J Ellis [020d5fbe36e0-dmarc-requ...@listserv.ua.edu]
> > Sent: Friday, September 17, 2021 2:00 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: registration problem
> >
> > we are trying to get some 'younger' folks registered on this list, they
> get the email to click the link to complete the registration, they can see
> the list of subjects, however when the select IBM-Main, it opens a page and
> tells them they are not authorized to view the archives with the email
> address you used to log in. Which is the email the registration was sent
> to, they have also tried to get / change password, and keep getting the
> same error.
> >
> > so - they can get here :
> https://secure-web.cisco.com/1KAgBXWMQ_wTjXKEP9BC_pf-payG1xiz7biaxXjbsVNH4VkDp_gk5nvqTJZIRv2HSNAJWp865946Ftr6oST09fyunf6ceDix4fVE4rC1KJx-1dRbJ-iXHdhiybWIPEdPY4x65bFWb1ZA6ikF2kCxax-Np-L07Y3WE7Dqa3BqKDpIytQVTqSRLmArFIemm4bw8Er4iW72vMHX2SilADbI0XYsnrKYH7KIEwBOLpm1ODsuhRF-OqAHjXCb440NtXt5bCAarO9uF1uLJ2Fj9PhV-OsdZ0Zq97ZAm1rdeoqo239cwXgOpo7uvekT5aB6tO4ooDsERdQ1egxswi54Lxyb3wpTpMNCgxlKqpXwbcH_lOIo4HChs6b9E70FN8dtnFZfB3EpPrshhC5fsh6pSVbWsU2NX3Wny6BkZOD04J8YuSWaib26-rO4jAxN6DlJF0h2B/https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa
> >
> > but get not valid email message here:
> https://secure-web.cisco.com/11V8oky3EZmdO7GhN9jhPBRGV6nLVfLigCFPt4z6MrTJwz9zZk1En3fld-G2q02xFxiFzvqhL7Z2MSYL2tih3CBgFxLUOmgDHqVvAAmSabhE3RUXH14jwLmaNNZt86MMNtZT5yCUkoIkp8cJJ4NEnS0rZo81z96VOdWe8zjAwRtUjaixKGpQcxlvnGSLvKcK5kp5idasfv443u8muS6WNaxQKLKtMwzt8RLx9c8oZMh4w7Vhxq2lBBan2sI6MoU8dhtfvE8ogXraK9tamsmURtrXsaWSolbG6BlMFjqijgEC7egHBDFADO8ILwxS_Gld-cZ5Ri753y2qD5vPhFj6WhQxQ477rnylirWDiuRX312rsEDIpbiR5hCQzG3xPe1eTh0NXd647E2XEVB6er1LA1ZlNRuqlDJDlC-u9jZs6u6_wHT26hF4bU4vI83sQraBV/https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA0%3DIBM-MAIN.
> ..
> >
> >
> > maybe something obvious, just not seeing it.
> >
> > thanks
>

-- 

Skip Robinson
323-715-0595

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

Re: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)

[Paul Gilmartin]

On Sun, 19 Sep 2021 11:53:18 -0500, Hobart Spitz wrote:
>...
>Once you have Pipes you don't need or want EXECIO.  ...
>  
At times the effort of converting existing art outweighs the benefit.  And  
POSIX
pipes are portable to desktop systems; CMS/TSO Pipelines is not.

>   - Pipes can read from or write to either a DD or a dataset.  z/OS EXECIO
>   can only use a DD.

>   - When a dataset is specified, Pipes defaults to OLD when writing.  This
>   is something that z/OS access methods don't even check.  You could still
>   accidentally shoot yourself in the foot, but it's not obvious in JCL  In
>   Pipes to have to explicitly override the default by coding SHR next to the
>   dataset name.  I don't know why you would want to.  
>
Pipes ought also support the SPFEDIT ENQ:

as FTP and NFS do in order to allow safely updating one member of a PDS by one
job while another job processes a different member, and to allow creating 
different
members concurenttly, supported by PDSE but not PDS.  With "1000s of stages"
a programmer might not easily check for this.

Is there any protection against FANOUT's having downstream stages that 
destructively
update the same data sett?  Does Pipes do "ENQ RET=HAVE"?

-- gil

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

Re: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)

[Hobart Spitz]

Thank you for your relevant and helpful comments.  They are very much
appreciated, as I omitted some topics.  I'll do my best to address them
here.  Pardon the lack of brevity.

Concerning EXECIO:
   Yes, the z/OS and z/VM EXECIO versions are mostly incompatible.
Once you have Pipes you don't need or want EXECIO.  Here's why:

   - Pipes can read from or write to either a DD or a dataset.  z/OS EXECIO
   can only use a DD.
   - TSO Pipes has a format that is syntactically and semantically similar
   to that in CMS Pipes.  It is used with a PDS/E allocated to a DD.
   - When a dataset is specified, Pipes defaults to OLD when writing.  This
   is something that z/OS access methods don't even check.  You could still
   accidentally shoot yourself in the foot, but it's not obvious in JCL  In
   Pipes to have to explicitly override the default by coding SHR next to the
   dataset name.  I don't know why you would want to.  Consider the
   organization that doesn't protect itself from writing with a DISP=SHR in
   JCL, either with education, standards or exits.  OT:  This is why you
   should *always* put DISP= on the first line of a JCL DD and the DSN on a
   continuation.  Otherwise, if someone performs maintenance and accidentally
   ends up with DISP=SHR on an output DD, for a long time there may be no
   errors and it may run fine even in production.  That is, until the day that
   another process writes with SHR or reads while the dataset is in an
   inconsistent state.  There could be a lot of confusion.  I would be glad to
   hear from someone knowledgeable that I'm wrong on this and that I missed
   some access method change that has made the concern unnecessary.
   - Pipes lets you read member(s) through a DD and names(s) specified in
   the pipe stage or by feeding member names to certain stages.  With EXECIO,
   you must put the member name on the allocation.  If you've ever read a
   large number of members from a PDS/E with EXECIO, you know it takes
   forever.  You must go through TSO ALLOC command attach, enqueue, catalog
   search, VTOC search, directory search, and OPEN (to name those I know
   about), and then free and dequeue the entire allocation before starting the
   next member.  (OT:  ISPF services allows you to allocate a PDS/E and then
   process multiple members.  What takes minutes with EXECIO takes seconds
   with ISPF and Pipes.)
   - With Pipes, you don't have to write a loop to process or build records
   in a stem or in the stack.  Since the records are ready available to the
   steam, you process them from there in any way that your application
   dictates.
   - Pipes does parallel enqueues, allocations and opens via its COMMIT
   mechanism.  In a nutshell, during the initialization stage (commit level <
   0), any stage can issue a negative return code.  It stops further regular
   processing and gives stages the opportunity to release any resources
   obtained.  This is similar to what happens with batch JOB JCL.  Recovering
   from an enqueue, allocation. or open failure can be complicated with
   multiple instances of EXECIO.

Concerning GLOBALV:

   I have looked at GLOBALV files and they do not appear to be too
difficult to read and write compatibly with REXX and/or Pipes.  IBM
documents the format.  SESSION values could be saved in a VIO dataset for
performance and tranciency.  Thus writing a GLOBALV for TSO seems highly
practical.  If there was no better option, one could write logic for just
those functions that are used by the CMS code being ported.


Concerning checkpointing:

   - Checkpointing was originally implemented because large organizations
   had regular jobs that ran for hours. If there was an abend and a long
   running job had to be rerun, whole sets of dependent jobs would be delayed,
   throwing weekly payroll, monthly payables, or bill cycle receivables, etc.
   behind schedule.  The company could be put at risk of penalties for late
   payroll, interest charges for overdue payments, or delayed receivables
   income, etc.  Because today's platforms are orders of magnitude faster,
   there are many fewer such jobs today, even given increased volumes.  Many
   checkpointing concerns are moot today.  (This includes for example baring
   temporary datasets in production because a job that now runs in 10 minutes
   or less might have to be restarted when it would have run fine from
   scratch.  It will take that time to review the problem, fix it and set up
   the job for restart.  Too many people are copying JCL or following less
   than well documented standards that they and/or their management don't
   understand.)   The remaining long running jobs are prime candidates for
   being rewritten in Pipes.
   - Rewriting a long running JOB or UNIX piping command in Pipes can cut
   the run time dramatically.  A rule of thumb for the time saved is the total
   I/O time for all intermediate datasets used to pass data from step to
   step.  A one 

Re: ispf edit macro "HX" line command

[Seymour J Metz]

At least in z/OS 2.4, the documentation states that you can't issue a line 
command from a macro. RFE?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Weizman arbel 
Sent: Sunday, September 19, 2021 4:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ispf edit macro "HX" line command

I remembered that
(:) prefix command line (primary command) can execute line command
Command ===> :hx
Command ===> :i
Command ===> :r
etc ...

https://www.ibm.com/docs/en/zos/2.1.0?topic=commands-line
You can enter edit line commands as primary commands on the command line by 
prefixing them with a colon (:) and placing the cursor on the target line. For 
example, if you enter :D3 on the command line and move your cursor to line 12 
of the file, the three lines 12, 13, and 14 are deleted from the file. This 
technique is normally used for PF key assignments.


address isredit
":HX"
Does not work Because it is Not an edit command

How to push command to ZCMD ?

I tried

address ispexec
"control errors return"
Mycmd = ':HX'
"DISPLAY COMMAND(Mycmd)"

It does not work

--
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: ispf edit macro "HX" line command

[Weizman arbel]

I remembered that
(:) prefix command line (primary command) can execute line command
Command ===> :hx
Command ===> :i
Command ===> :r
etc ...

https://www.ibm.com/docs/en/zos/2.1.0?topic=commands-line
You can enter edit line commands as primary commands on the command line by 
prefixing them with a colon (:) and placing the cursor on the target line. For 
example, if you enter :D3 on the command line and move your cursor to line 12 
of the file, the three lines 12, 13, and 14 are deleted from the file. This 
technique is normally used for PF key assignments.


address isredit
":HX"  
Does not work Because it is Not an edit command

How to push command to ZCMD ?

I tried

address ispexec
"control errors return"
Mycmd = ':HX'   
"DISPLAY COMMAND(Mycmd)"

It does not work

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