Re: A Discussion about RLSE on RAID Drives with Chat GPT-4

[Hobart Spitz]

/OS. However, IBM regularly updates and enhances its z/OS
operating system based on customer feedback and technological advances, so
it's possible that they may address these issues in the future.

I would recommend reaching out to IBM or your vendor directly for the most
up-to-date information. Also, participating in user groups like SHARE or
attending IBM technical conferences could provide insights into future
developments and allow you to raise these issues directly with the IBM team.

In the meantime, it would be beneficial to establish internal processes and
guidelines to handle these issues. This could include implementing rigorous
change management and review processes to ensure the SPACE= specifications
are consistent across all steps that handle a dataset. Also, regularly
reviewing your dataset management practices and providing training and
awareness to your team about the implications of the SPACE= parameters and
the extent limitations of datasets can help mitigate these issues.
[image: User]
Me: Is the proposed addition of DISP=ASIS the best solution in terms of
resources, JCL volume, simplicity, etc. or is there a better solution?

Adding a DISP=ASIS parameter could certainly provide a level of dynamic
flexibility that is not currently inherent in JCL, as it would potentially
allow for more streamlined JCL code by not requiring explicit definition of
a dataset's disposition (NEW, OLD, or SHR).

>From a resources and JCL volume perspective, DISP=ASIS could potentially
reduce the amount of JCL code needed for jobs, especially for those jobs
that frequently need to handle rerun scenarios or dynamically determine the
disposition of a dataset.

In terms of simplicity, it could potentially reduce the cognitive load for
programmers and operators by not requiring them to explicitly specify or
change the dataset's disposition. This can reduce the potential for errors
and increase productivity.

However, the introduction of DISP=ASIS would also need to be carefully
planned and managed. The ASIS behavior could lead to unexpected
consequences if not correctly understood or managed, and it would need to
be thoroughly tested in your environment to ensure it behaves as expected
and does not introduce new issues.

Also, existing processes, tools, and possibly even applications that
analyze or generate JCL code would need to be updated to handle the new
DISP=ASIS parameter.

As with any proposed solution, the "best" solution will depend on the
specific needs, constraints, and characteristics of your environment. While
DISP=ASIS could provide significant benefits in terms of reduced JCL code
and increased flexibility, these benefits need to be weighed against the
potential costs and risks associated with its implementation.

Ultimately, a combination of techniques might be necessary for optimal
dataset management. This could include careful use of the SPACE=
parameters, consistent dataset naming conventions, effective use of IEFBR14
to initialize datasets, rigorous change management processes to ensure
consistent SPACE= specifications, and possibly the proposed DISP=ASIS
parameter, if it were to be implemented.


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Sat, Jul 1, 2023 at 8:15 AM Walt Farrell  wrote:

> On Thu, 29 Jun 2023 18:10:06 -0500, Hobart Spitz 
> wrote:
>
> >https://chat.openai.com/share/1718b445-7a89-47a3-ab23-b670aa8c2211
>
> That URL gives a 404 error, for me.
>
> Perhaps you could have your conversation again, and quote the conversation
> here directly next time?
>
> --
> Walt
>
> --
> 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

A Discussion about RLSE on RAID Drives with Chat GPT-4

[Hobart Spitz]

https://chat.openai.com/share/1718b445-7a89-47a3-ab23-b670aa8c2211


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: Unlike data sets concatenation - revised 3

[Hobart Spitz]

I don't see a question, so I'm responding to what I think you want.

It has long been true that BUFSIZE defaults to the largest
available BLKSIZE  The requirement was written in the 1980s.  (It might
depend on your access method.)  So, I very much doubt the the BLISIZE
difference is the problem.

There is no equivalent default for LRECL, so I'm guessing that the first
LRECL being smaller than the second is your problem.  This is a long shot,
but it might work if you code LRECL=230 on the first DD.

Sorry I don't have anything better.


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Mon, May 1, 2023 at 8:27 AM Pierre Fichaud  wrote:

> I have provided the DCB in source and dumped it just before the OPEN.
>
> 1st data set in the concatenation :
>
>  Data Set Name . . . . : PIERRE.VB200.
>  .
>   .
>  .  General Data   Current
> Allocation   .
>  .   Management class . . : **None**
> Allocated cylinders : 1 .
>  .   Storage class  . . . : **None**
> Allocated extents . : 1 .
>  .Volume serial . . . : DISK01
>   .
>  .Device type . . . . : 3390
>   .
>  .   Data class . . . . . : **None**
>   .
>  .Organization  . . . : PS Current
> Utilization  .
>  .Record format . . . : VB  Used
> cylinders  . . : 1 .
>  .Record length . . . : 200 Used
> extents  . . . : 1 .
>  .Block size  . . . . : 1000
>   .
>  .1st extent cylinders: 1
>  .
>  .Secondary cylinders : 1  Dates
>   .
>  .Data set name type  :
>  Creation date . . . : 2023/04/20.
>  .Data set encryption : NO
> Referenced date . . : 2023/05/01.
>  .
> Expiration date . . : ***None***.
>  .
>   .
>  .SMS Compressible  . : NO
>
> 2nd dataset :
>
>.  Data Set Name . . . . : PIERRE.VB230
> .
>  .
>   .
>  .  General Data   Current
> Allocation   .
>  .   Management class . . : **None**
> Allocated cylinders : 1 .
>  .   Storage class  . . . : **None**
> Allocated extents . : 1 .
>  .Volume serial . . . : DISK01
>   .
>  .Device type . . . . : 3390
>   .
>  .   Data class . . . . . : **None**
>   .
>  .Organization  . . . : PS Current
> Utilization  .
>  .Record format . . . : VB  Used
> cylinders  . . : 1 .
>  .Record length . . . : 230 Used
> extents  . . . : 1 .
>  .Block size  . . . . : 1150
>   .
>  .1st extent cylinders: 1
>  .
>  .Secondary cylinders : 1  Dates
>   .
>  .Data set name type  :
>  Creation date . . . : 2023/04/20.
>  .Data set encryption : NO
> Referenced date . . : 2023/05/01.
>  .
> Expiration date . . : ***None***.
>  .
>
>  .SMS Compressible  . : NO
>
>
>   The JCL has just the DSN and DISP.
>  .
>
> .  000183 INFILE   DCB   DDNAME=INFILE,
>   *00164000 .
>  .  000184DSORG=PS,
>   

Re: Q: Where is LISTDSI kept? A: Not where you think.

[Hobart Spitz]

Steve wrote:
>So the question of where LISTDSI is found is moot, in that my
>environment is correct once using "CC = 'LISTDSI' ('SYSUT1 FILE')".

The quotes around LISTDSI serve no function, unless you are inside a
routine with the same name and you don't want recursion.  Since the
interpreter only tokenizes the program once, you will rarely save anything
by skipping the check for an internal routine.

It looks like you still have a blank between your function name and the
left parentheses of the argument list.  In that case you will get CC set to
the string "LISTDSI SYSUT1 FILE", and not a return code.

I prefer CALL LISTDSI "SYSUT1 FILE", which is almost the same as RESULT =
LISTDSI("SYSUT1 FILE").  IMHO, these examples in IBM documentation are
misleading and potentially can result in broken code.  A CALLed routine is
NOT required to return a value and whereas a function invocation MUST have
a value on it's return statement.  If you change a routine from returning a
value, to not returning one, you will get a run time syntax error.
Further, you are adding another variable to the B-tree, while you could
just reuse RESULT.  If garbage collections are an issue, they might be
slightly more frequent.

Keep learning REXX.  At some point you may realize that it is a truly
amazing language.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: Q: Where is LISTDSI kept? A: Not where you think.

[Hobart Spitz]

On Mon, 20 Feb 2023, 17:07 Steely.Mark,  wrote:

> Here is a simple REXX for LISTDSI:
>
> /* A SIMPLE REXX TEST PROGRAM */
> variable = 'data.set.name'
> x = LISTDSI(variable)
> say x
>

Be careful.  If you meant a fully qualified dataset name, you need to code
this.

Variable = " 'data.set.name' "

(I added blanks around the DS name to distinguish apostrophes from
quotation marks.)

One other point which confuses beginners to REXX (myself included at one
time): Anything that is not recognised as part of the REXX language is
assumed to be an expression the evaluation of which is sent to the current
host command environment for execution.  If not the default of TSO, then
ISPEXEC, ISREDIT,  DSNREXX, among many others.

>

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

Re: Q: Where is LISTDSI kept? A: Not where you think.

[Hobart Spitz]

Steve;

You need to brush up on your REXX.

- TSO is the default ADDRESSing environment, in most cases.  Adding or
removing ADDRESS TSO will not make any difference.

- The -3 you are getting means there is no such command found.  The manual
clearly states that LISTDSI is a built-in function under z/OS and whether
or not it will run outside A TSO environment.  You must invoke it
correctly.  It is not a command.

- STEPLIB will not help, ever.  You are barking up the wrong tree, in the
wrong forest, on the wrong continent.

- The syntax you are using is for a host command.  That is incorrect.  You
want to invoke LISTDSI in an expression as a function or using the REXX
CALL instruction..

- Blank(s) are not allowed between a function name and the left parentheses
of the argument list.  So you are still not invoking LISTDSI correctly.

- However, just removing the blank will not work either.  TSO will get only
the return code from LISTDSI, which is also not a valid command.  You might
get your variables set, but TSO will still complain.

Please see also my previous response.

The great thing about REXX is that it's a small, intuitive, flexible
language in which you can do 99 percent of what all other procedural
languages can do, combined, and much, much more..  Unfortunately, this
means that too many people think they know what they are doing, when they
don't.

I hope this helps


On Mon, 20 Feb 2023, 16:02 Steve Thompson,  wrote:

> IRXJCL did not work.
>
> The problem is, I will have to have ISPF because I will be using
> the ISPF Library management routines. This is why I have been
> working with the TSO BATCH environment.
>
> At another site where I worked, I wrote a system for generating
> JCL to do compiles and deal with DB2 BIND, the translators, CICS,
> DB2, PROCOBOL, IDMS, and COBOL, HLASM, C++, EZTRV, Linkedit(s) etc.
>
> So this is not my first time doing this stuff.
>
> Since I got the same -3 when I attempted to do a "LINK" within
> REXX and the STEPLIB was missing the library that had the program
> we wanted linked to, I figured that I must be missing a library
> that contains LISTDSI.
>
> So in Reading The Fine Manual (I went to a church college), I
> removed the ADDRESS TSO and this is what we get:
>
>  34 *-* listdsi ('SYSUT1 FILE')
> >>>   "LISTDSI SYSUT1 FILE"
> COMMAND LISTDSI NOT FOUND
> +++ RC(-3) +++
>
>
> Tomorrow is another day.
> Steve Thompson
>
>
>
> On 2/20/2023 4:10 PM, Mike Shaw wrote:
> > Steve,
> >
> > If you change the EXEC statement to use PGM=IRXJCL instead of
> PGM=IKJEFT01
> > does the result change?
> >
> > Mike Shaw
> > QuickRef Support
> >
> > On Mon, Feb 20, 2023, 2:53 PM Steve Thompson  wrote:
> >
> >> Thankfully this time I can show the code. One needs to
> >> understand, sometimes I'm working on something for a client that
> >> goes ape if I show their code without getting it in writing.
> >>
> >> This is how the second step in a PROC is being done which is
> >> where this code gets invoked:
> >>
> >> //.  EXEC PGM=IKJEFT01,..
> >>
> >> This is a capture of the code leading into the failure:
> >>
> >>
> >>
> >>ADDRESS LINKMVS 'ISPQRY' /* Verify the ISPF environ */
> >>xx = RC
> >>
> >>IF xx > 0 THEN DO
> >>   SAY "ISPQRY did not find a valid ISPF envi
> >>   SAY "Migration System will terminate with
> >>   EXIT xx
> >>END ; ELSE DO
> >>   SAY "ISPQRY found valid ISPF environment."
> >>   SAY "Migration System continues."
> >>END
> >>
> >>PARSE ARG UPPER COMMAND_LINE EXCESS
> >>SAY "COMMAND_LINE=" COMMAND_LINE
> >>SAY "EXCESS PARM =" EXCESS
> >>
> >>
> >>ADDRESS TSO
> >>
> >>listdsi 'SYSUT1 FILE'
> >>XX = RC  /* capture RC */
> >>
> >> *XX is -3 when done. *
> >>
> >> Meanwhile, anyone have a contact for the TSO-REXX list -- Any
> >> email to any address at Marist for me is being rejected.
> >>
> >> Steve Thompson
> >>
> >>
> >> On 2/20/2023 12:29 PM, ITschak Mugzach wrote:
> >>> Show us you code.
> >>>
> >>> בתאריך יום ב׳, 20 בפבר׳ 2023 ב-19:28 מאת Binyamin Dissen <
> >>> bdis...@dissensoftware.com>:
> >>>
>  Does it work out of live ISPF?
> 
>  If so, try running it with TRACE in both environments.
> 
>  On Mon, 20 Feb 2023 11:30:27 -0500 Steve Thompson 
> >> wrote:
>  :>Interesting. I have started ISPF, and I have checked that ISPF is
>  :>active from my REXX code via ISPQRY and comes back with RC=0
>  :>(active).
>  :>
>  :>Later in REXX code I attempt to get INFO on a DD and that is when
>  :>LISTDSI returns -3.
>  :>
>  :>So apparently I need to concatenate some library and I don't have
>  :>any of the install stuff for this environment
>  :>
>  :>I'm not sure that I have access to the CSIs because this is a
>  :>cloned system.
>  :>
>  :>Regards,
>  :>Steve Thompson
>  :>
>  :>On 2/20/2023 11:16 AM, Lars Höglund wrote:
>  :>> You have to start ISPF
>  :>>
>  :>> 

Re: Q: Where is LISTDSI kept?

[Hobart Spitz]

Correction:  That should have been:  F LISTDSI(DSNVAR) = 0 THEN ...


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Mon, Feb 20, 2023 at 3:05 PM Hobart Spitz  wrote:

> LISTDSI is a REXX function,  It is not a host command; ADDRESS has no
> effect on LISTDSI.
>
> Use CALL LISTDSI DSNVAR ...  or IF LISTDSIO\(DSNVAR) = 0 THEN ... , e.g,
> in any mixed case where you have stored the dataset name in DSNVAR or the
> variable of your choice.   (All REXX functions can also be invoked as
> subroutines.)  As with any argument in REXX, it can be a constant, variable
> or expression that evaluates to something that is valid for the specific
> function.
>
> ISPF is not required.  TSO probably is.
>
>
>
> OREXXMan
> Q: What do you call the residence of the ungulate with the largest antlers?
> A: A moose pad.
> :-D
> Would you rather pass data in move mode (*nix piping) or locate mode
> (Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
> with more than a dozen filters, while Pipelines specifications are commonly
> over 100s of stages, and 1000s of stages are not uncommon.
> REXX is the new C.
>
>
> On Mon, Feb 20, 2023 at 2:28 PM Paul Gilmartin <
> 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Mon, 20 Feb 2023 14:53:49 -0500, Steve Thompson wrote:
>> >...
>> >  PARSE ARG UPPER COMMAND_LINE EXCESS
>> ???
>>PARSE UPPER ARG COMMAND_LINE EXCESS
>>
>> But that limits your COMMAND_LINE to only one word; perhaps not what you
>> want.
>>
>> Example from <https://www.ibm.com/docs/en/zos/2.5.0?topic=tef-listdsi>:
>> argument_string = "REXXEXEC VOLUME(PACK1) NODIRECTORY NORECALL"
>> x = LISTDSI(argument_string)
>>
>> --
>> gil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>

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

Re: Q: Where is LISTDSI kept?

[Hobart Spitz]

LISTDSI is a REXX function,  It is not a host command; ADDRESS has no
effect on LISTDSI.

Use CALL LISTDSI DSNVAR ...  or IF LISTDSIO\(DSNVAR) = 0 THEN ... , e.g, in
any mixed case where you have stored the dataset name in DSNVAR or the
variable of your choice.   (All REXX functions can also be invoked as
subroutines.)  As with any argument in REXX, it can be a constant, variable
or expression that evaluates to something that is valid for the specific
function.

ISPF is not required.  TSO probably is.



OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Mon, Feb 20, 2023 at 2:28 PM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 20 Feb 2023 14:53:49 -0500, Steve Thompson wrote:
> >...
> >  PARSE ARG UPPER COMMAND_LINE EXCESS
> ???
>PARSE UPPER ARG COMMAND_LINE EXCESS
>
> But that limits your COMMAND_LINE to only one word; perhaps not what you
> want.
>
> Example from :
> argument_string = "REXXEXEC VOLUME(PACK1) NODIRECTORY NORECALL"
> x = LISTDSI(argument_string)
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Irish data centers....an opportunity?

[Hobart Spitz]

IMHO, the fault lies in the character stream orientation of UNIX, C, HTML
etc.  The shorted-sighted design was motivated by the limited budgets and
underpowered systems of many early UNIX users.

On record oriented systems, (z/OS and z/VM) common operations are faster,
because the needed information is not embedded in the data.  For example:

   - Read/skip-to the next record.
   - Find/check the length of a string.

On byte stream oriented systems, every single character, including the
otherwise uninteresting ones, must go through the CPU for such operations.
Record oriented systems can efficiently add the record length to the
current record address, or compare a target character position to the
length of the record to avoid string overflow (e.g).

It doesn't help that most character oriented systems use 16 bit characters
whereas most work on zSeries is done with 8-byte characters.  The workload,
all other things being equal, is essentially doubled.  As stated above, all
other things are anything but equal.

Note that UNIX (etc.) systems originally used 4K buffers between pipe
stages;  Most such systems now use 64K buffers to support the heavy load of
characters run through the CPU and to reduce costly redispatching.

It may be related that IBM went from two cache levels to four about the
time USS was added.  More hardware manufacturing and heat generation
resulted.

Unfortunately this mistake is so pervasive that it might never be fixed.
The impact is not just on electricity usage, but also on global warming and
climate change due to extra cooling and extra hardware.

Anyone who understands that global warming and climate change are
existential threats and that it may be too late to avoid catastrophic
impacts would be well advised to keep their record oriented systems and
move away from UNIX, Linux, and Windows where feasible.

Just my "buck three eighty", or two cents if you prefer.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Sat, Feb 11, 2023 at 8:37 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Correct. I copied the article from the NYT & then reposted the paragraph
> in the article which discussed the study.
>
>
>
> Heh - I don't think those are rankings - just (former) links from the
> article in whatever publication Bill copied from.
>
>
> > >...
> > >The largest cloud data centers, sometimes the size of football fields,
> > are owned and operated by big tech companies like Google, Microsoft,
> Amazon
> > and Facebook.
> > >...
> > >Over the years, data center electricity consumption has been a story of
> > economic incentives and technology advances combining to tackle a
> problem.
> > >
> > Do they use:
> > o IBM z?
> > o IBM supercomputers?
> > o Others, such as overseas-sourced (specify)?
> >
>
> At one time Facebook published detailed specs for its homegrown PC servers,
> in contrast to the likes of Google, Amazon, and Microsoft, for whom it's
> all trade secrets. I've no idea if they've kept the specs current. Lynn
> Wheeler wrote about this stuff a number of times when he was active on
> IBM-MAIN, though mostly from an available-compute-power perspective rather
> than a power efficiency one.
>
> Tony H.
>
> --
> 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: ISPF macro/script

[Hobart Spitz]

You have these options:
1 - Select the member manually, and invoke your REXX edit macro.
2 - Write another module the invokes the edit service in the library and
member, and runs the edit macro.
3 - Write one dual mode module.  I do not recommend this.

Edit commands are only valid in REXX EXECs that have issued ADDRESS ISREDIT
MACRO which establishes the edit macro environment.

I would Google "ispf edit macro example".

On Monday, February 6, 2023, Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> To be honest ISPF & REXX is not my strong point.
>
> I need the following:
> From PDS(E) member list I type my CMD1, hit ENTER - to start the REXX
> script.
> The script Select new member (name generated from date+consecutive
> character), then issue some edit commands, like COPY TEMPLATE to copy some
> text from the TEMPLATE member.
>
> Any clue?
> Or some similar script to learn by example?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: Having a little difficulty with a REXX command LMOPEN

[Hobart Spitz]

Just taking a guess here:  Most ISPF services run at the same task level as
the invoking user program.  I believe that EDIT (and View) run at a
different task level, and therefore may not have access to the same
parameter pointers.


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Mon, Feb 6, 2023 at 10:32 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 6 Feb 2023 15:29:01 +, Seymour J Metz  wrote:
>
> >It follows TSO command conventions, so in that sense it is a TSO command,
> but it is in an ISPF library.
> >
> So 'ADDRESS TSO  "ISPQRY"' fails if ISPF libraries are not allocated?
>
> Did you mean trimodal?
>
> By "bimodal" I meant ISPF vs. non-ISPF.  There are numerous modes.  I
> start some scripts with:
> ADDRESS ISREDIT MACRO X
> IF RC<>0 THEN PARSE ARG X
>
> I feel that ISPF designers show contempt for REXX in eschewing REXX
> facilitird such as
> PARSE ARG, and especially compound symbols.
>
> 
> From: Paul Gilmartin
> Sent: Monday, February 6, 2023 9:53 AM
>
> On Mon, 6 Feb 2023 04:48:09 +, Seymour J Metz wrote:
>
> >I would probably use ISPQRY, but your usage is shorter.
> >
> But does that require TSO?  I wanted to be TSO-independent:
>
> z/OS 2.5  ISPF Services Guide
> IBM   SC19-3626-50
>
> Under TSO/E REXX that uses ADDRESS TSO you can use:
> "ISPQRY"
>
> (if it's a TSO command, shouldn't it be documented in the TSO COmmanf
> Ref.?)
>
> 
> From: Paul Gilmartin
> Sent: Sunday, February 5, 2023 9:02 PM
> >...
> Thrtr are scripts intended to be bimodal where I have dome:
> ADDRESS ISPEXEC DISPLAY 'MSG(ISRZ002)'
> IF RC<>0 THEN DO  /* ISPF not active.  */
>   say errMsg1
>   say errMsg2;  END
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Having a little difficulty with a REXX command LMOPEN

[Hobart Spitz]

I have a few thoughts.  I still have to guess because you didn't include
all of the relevant code, and your colors didn't come through.

   - Are you missing "LMCLOSE Dataid("Nbkp")".  This might cause an
   exhaustion of LMOPEN resources.  It would be my guess for the best
   candidate solution.
   - Adding TRACE COM, temporarily, might give you (and us) more
   information.  Please send the last screen or two of trace output, including
   the terminating error message (s).
   - As you know, zerrsm and zerrlm give crucial information.  Please share
   those values.
   - It might be worth looking into your log (option 7.5); you must turn on
   the ISPF log.  (I pity the genius who does anything with ISPEXEC/ISREDIT
   commands but doesn't have their log turned on.)
   - It's not clear, but you might have been using SIGNAL EVAC as a GO TO.
   It is not!  This form of SIGNAL unwinds any structures within the current
   procedure before transferring control.  Any active DO loops are removed!
   This might be the reason it appeared that SIGNAL EVAC causes a
   problem, when everything was working as designed.  LEAVE might be what you
   need.  It ends an inner loop, but lets an outer one continue.
   - I have never heard of a "VSAM library", but you may be referring to
   something other than what I'm interpreting the comment to mean.

Other than those, I think you have most of the elements correct and in
place, so I think you are close.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Sun, Feb 5, 2023 at 2:53 PM Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:

> Yep, I am doing LMFREE and LMCLOSE, but I had introduced an error when I
> included an INTERATE command in the middle of a DO/END and so in a specific
> situation, the LMFREE/LMCLOSE would not get executed.
> And then in the subsequent iteration, I would see the LMOPEN error.
>
> I got a return code of 8, but did not see any additional information and I
> completely forgot (old age?) I should be dumping out zerrsm and zerrlm.
> I should ALWAYS execute the REXX statements in green, but when I arrive in
> the yellow code, I skip over the LMFEE/LMCLOSE which causes grief with the
> subsequent iterations.
>
>
>/* Copy all members from VSAM library. No exceptions here */
>"LMMLIST Dataid("Nbkp") OPTION(LIST) STATS(NO)",
>"MEMBER(rComp)"
>If rc >= 4 Then Do
>   errMsg1 = ' Member 'rComp' not found in Backup library.'
>   errMsg2 = ' Data was not replaced.'
>   say errMsg1
>   say errMsg2
>   Iterate* This causes an issue for subsequent
> iterations of the DO/END
>   /*  signal evac */
>End
>Else Do
>   replFl = 'REPLACE'
>   "LMMOVE FROMID("Nbkp") TODATAID("Nlib")",
>   "FROMMEM("rComp") "replFl
>   If rc /= 0 Then Do
>  errMsg1 = "LMMOVE error for "rComp
>  errMsg2 = "Return code was "rc
>  exRC = rc
>  signal evac
>   End
>   Else Do
>  rptRsn = 'Move from N-Backup library complete'
>   End
>    End
>call buildrpt
>"LMMLIST Dataid("Nbkp") OPTION(free)"
>"LMCLOSE Dataid("Nlib")"
>"LMFREE Dataid("Nbkp")"
>"LMFREE Dataid("Nlib")"
> End
>
>
>
> Thanks
>
> …….Cameron
>
> From: IBM Mainframe Discussion List  On Behalf
> Of Hobart Spitz
> Sent: Sunday, February 5, 2023 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Having a little difficulty with a REXX command
> LMOPEN
>
> Are you doing LMFREE, on the dataid from LMINIT, when you are finished with
> each library?
> It sounds like you are exceeding resources for LMINITs.
>
> I don't think FREE/CLOSE is needed. LMINIT and LMFREE are faster, more
> reliable and easier to use.
>
> It also sounds like you are not getting the return code back so you can
> display zerrsm and zerrlm. (Unless you did this and I missed it.) You may
> need to issue SIGNAL OFF ERROR, and/or ADDRESS ISPEXEC "CONTROL ERRORS
> RETURN". Otherwise your program won't be able to report what happened.
>
> Please study and understand Lionell's example. Your outer (library) loop
> should include all of those elements.
>
> We still need to see your code 

Re: Having a little difficulty with a REXX command LMOPEN

[Hobart Spitz]

Are you doing LMFREE, on the dataid from LMINIT, when you are finished with
each library?
It sounds like you are exceeding resources for LMINITs.

I don't think FREE/CLOSE is needed.  LMINIT and LMFREE are faster, more
reliable and easier to use.

It also sounds like you are not getting the return code back so you can
display zerrsm and zerrlm.  (Unless you did this and I missed it.)  You may
need to issue SIGNAL OFF ERROR, and/or ADDRESS ISPEXEC "CONTROL ERRORS
RETURN".  Otherwise your program won't be able to report what happened.

Please study and understand Lionell's example.  Your outer (library) loop
should include all of those elements.

We still need to see your code as written; I'm just guessing from your
description.  There could be something you are doing that I have not
considered.


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Sun, Feb 5, 2023 at 11:51 AM Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks a ton everyone.
> Just a dumb User issue here (me).
>
> I have a DO loop, and at the bottom of the loop I manage the cleanup
> (FREE/CLOSE)
> However, inside the loop I had some code where I would report an
> encountered error, and then issue ITERATE to work with the next input
> library member.
> In this situation I never actually got to the bottom of the Loop and I
> never issued the FREE/CLOSE.
> The next time I tried an LMOPEN on the same library, it failed.
>
> Appreciate the helpful information.
> I did not remember I could dump the zerrsm and zerrlm to get additional
> information.
>
> Thanks
>
> ...Cameron
>
> From: IBM Mainframe Discussion List  On Behalf
> Of Lionel B. Dyck
> Sent: Friday, February 3, 2023 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Having a little difficulty with a REXX command
> LMOPEN
>
> Here is a sample that I wrote awhile ago to better understand how lmcopy
> works - hope this helps - no lmopen required.
>
> /* --- REXX --- *
> * test code for lmcopy *
> *  */
> in = 'hlq.test.pds'
> out = 'hlq.test.pdse'
> Address ISPexec
> "lminit dataid(indd1) dataset('"in"')"
> "lminit dataid(outdd1) dataset('"out"')"
> "lmcopy fromid("indd1") todataid("outdd1")" ,
> "frommem(a*) replace"
> "lmcopy fromid("indd1") todataid("outdd1")" ,
> "frommem(b*) replace"
> "lmfree dataid("indd1")"
> "lmfree dataid("outdd1")"
>
>
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com<
> https://isolate.menlosecurity.com/1/3735928037/https:/www.lbdsoftware.com>
> Github: https://github.com/lbdyck<
> https://isolate.menlosecurity.com/1/3735928037/https:/github.com/lbdyck>
>
> "Worry more about your character than your reputation. Character is what
> you
> are, reputation merely what others think you are."   - - - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of
> Cameron Conacher
> Sent: Friday, February 3, 2023 7:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Having a little difficulty with a REXX command LMOPEN
>
> Good Morning,
> I have a small REXX which essentially copies members of one PDSE to
> another.
>
> It iterates over members of the first PDSE and copies the members to the
> second PDSE.
>
> After about eighty members are copied, my LMOPEN fails with a return code
> of
> 8.
> I checked the manual and a return code of 8 from an LMOPEN means "The
> Dataset cannot be opened."
> 8
> Data set could not be opened.
>
>
> Is there somewhere I can see a bit more detail. Why the dataset could not
> be
> opened?
> I see nothing in the JES Log.
>
> Any thoughts appreciated.
>
> Thanks
>
>
> Cameron Conacher
> Senior Engineer
>
> American Express Canada Inc.
> GCICS
> 2225 Sheppard Avenue East, Toronto, ON M2J 5C2
>
> cameron.conac...@aexp.com cameron.conac...@aexp.com>
> Office: 1-437-836-5265
> Mobile: 1-416-409-5147
>
> https://amex.webex.com/join/cameron.conacher
>
> Note: I will be away from the office on PTO Friday February 3, 2023
>
> 
> American Express made the following annotations
>  This e-mail was sent to you by a
> representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto,
> ON, M1W 3W7, www.americanexpress.ca<
> https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
> If you no longer wish to receive these
> e-mails, please notify the sender by reply e-mail.
>
> This e-mail is solely for the intended recipient and may contain
> confidential or privileged 

Re: I want to cry

[Hobart Spitz]

On Fri, Feb 3, 2023 at 9:00 AM zMan  wrote:

> O my.
>
> I was on a call with a bunch of customers a few years ago. One of them was
> having a very basic problem with a COBOL program calling our product. I
> explained that they needed to put the name of  into a variable
> that gets passed as the first parameter. Silence, then..."What's a
> variable?"
>
> COBOL, and its programmers, use the term "data name", almost exclusively,
instead of the term "variables".  Why?  Because "data name" includes file
definitions, structures, 77 levels, 88 levels, etc., none of which are
variables.

Just because we know a lot of things that few others know, doesn't mean
that others don't know what they are talking about..

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

Having a little difficulty with a REXX command LMOPEN

[Hobart Spitz]

When you get the error, display zerrsm and zerrlm.

We need to see your code.

I think Seymour is asking the right question.

On Fri, 3 Feb 2023, 07:19 Cameron Conacher, <03cfc59146bb-dmarc-
requ...@listserv.ua.edu> wrote:

> Good Morning,
> I have a small REXX which essentially copies members of one PDSE to
> another.
>
> It iterates over members of the first PDSE and copies the members to the
> second PDSE.
>
> After about eighty members are copied, my LMOPEN fails with a return code
> of 8.
> I checked the manual and a return code of 8 from an LMOPEN means "The
> Dataset cannot be opened."
>  8
> Data set could not be opened.
>
>
> Is there somewhere I can see a bit more detail. Why the dataset could not
> be opened?
> I see nothing in the JES Log.
>
> Any thoughts appreciated.
>
> Thanks
>
>
> Cameron Conacher
> Senior Engineer
>
> American Express Canada Inc.
> GCICS
> 2225 Sheppard Avenue East, Toronto, ON  M2J 5C2
>
> cameron.conac...@aexp.com
> Office: 1-437-836-5265
> Mobile: 1-416-409-5147
>
> https://amex.webex.com/join/cameron.conacher
>
> Note: I will be away from the office on PTO Friday February 3, 2023
>
> 
> American Express made the following annotations
> 
> This e-mail was sent to you by a representative of Amex Bank of Canada,
> P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca.
> If you no longer wish to receive these e-mails, please notify the sender by
> reply e-mail.
>
> This e-mail is solely for the intended recipient and may contain
> confidential or privileged information. If you are not the intended
> recipient, any disclosure, copying, use, or distribution of the information
> included in this e-mail is prohibited. If you have received this e-mail in
> error, please notify the sender by reply e-mail and immediately and
> permanently delete this e-mail and any attachments. Thank you.
>
> American Express a fait les remarques suivantes
> Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du
> Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7,
> www.americanexpress.ca. Si, par la suite, vous ne souhaitez plus recevoir
> ces courriels, veuillez en aviser les exp?diteurs par courriel.
>
> Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des
> renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le
> destinataire pr?vu, toute divulgation, duplication, utilisation ou
> distribution du courriel est interdite. Si vous avez re?u ce courriel par
> erreur, veuillez en aviser l'exp?diteur par courriel et d?truire
> imm?diatement le courriel et toute pi?ce jointe. Merci.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

zPipe -Misc. Updates - CBT Tape File 1035

[Hobart Spitz]

All;

Your feedback has been appreciated.

Here is the plan for the next update, tentatively for Feb. 1.  Please let
me know if there is anything important I missed.

*2023/02 Update (as planned) *
*  Additional filters and functions (Any case is OK.):   *
*$README   - This member.*
*APPEND- Place arg output at end of stack.   *
*BROWSE- Fill-screen display using ISPF browse   *
*B2C()*- Binary to character conversion. *
*B2D()*- Binary to decimal conversion.   *
*CHANGE- Change all occurrences of one string to another.*
*CHANGSTR()- Change all occurrences of one string to another.*
*C2B()*- Character to binary conversion. *
*DUPlicate - Make copies of each record. *
*D2B()*- Decimal to binary conversion.   *
*FIND  - Select records by exact string in col. 1.   *
*INSTORE   - Write stack elsewhere and return token. *
*ISEQ()*   - Case-insensitive compare.   *
*ISONEOF()*- Case-insensitive wordpos(). *
*LISTPDS   - List member names of a PDS.  (zPLstPDS) *
*NFIND - Select records by exact string not in col. 1.   *
*OUTSTORE  - Write data to stack by INSTORE token.   *
*PREFACE   - Place arg output at top of stack.   *
*SHOW  - Full-screen display using ISPF browse, edit, or view.   *
*SUBFLS()* - Sub-field(start, len, sep) Defaults: len=1, sep='05'x   *
*  ()  - Function, not a filter. *
*  *   - Included in Spex, PickIf, and Call for CEXEC perf.  *
*  - Lower case characters in names are optional. *
*  Improved error handling for stage routine not found.  *
*  Add missing modules DDUNIQ for STACKIO ... dsn, and VIO.  STACKIO
DDname=yourddn still works.*
*In the interim, you can use STACKIO from the presentation for*
*dataset names and EXECIO for DD I/O *




OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: Piping for z/OS

[Hobart Spitz]

On Sat, Jan 7, 2023 at 8:10 PM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 6 Jan 2023 15:33:44 -0600, Hobart Spitz wrote:
> >
> >https://www.cbttape.org/updates.htm
> >
> >
> https://docs.google.com/presentation/d/1C7htK9I4rL-4pUZcdhfeA4-IY2Kjxm-HJQ4fuljMs3I/edit?usp=sharing
> >
> Glancing at that, I see no mention of "connector", a feature of CMS
> Pipelines that
> I used, for example in a FANINANY stage.  Does zPipes have a similar
> facility
> with a different name?
>

At this time *: is a synonym for STACK, because the function is the same in
zPipe.  I think a FANINANY stage will never be in zPipe, due to the
design.  zPipe is not meant to be a replacement for Pipelines, rather a
stepping stone to it.  To quote/paraphrase Melinda Varian, "Most people do
a lot with single stream pipes before they ever need multi-stream piping."

If people really understood what the BatchPipes PIPE command does, it would
be a complete no-brainer to get BatchPipes just for the PIPE command, even
if they never used all the extra stuff that comes along.  At the very
least, IBM should offer the TSO Pipe command as a separate offering.

>
> Some programmers will have existing z/OS UNIX filters that they'd prefer
> not to
> refactor as zPipes.


I agree.  I think that writing simple stages, like h*ead, tail, cat,* etc.,
in REXX using the stack as shown might be easy, for people who want the
flexibility to go either way.  Head and tail in REXX might perform better,
since you are just dropping pointers.


> Does zPipes provide a UNIX interface.  I suppose that could
> be achieved with Rexx plumbing, connecting stdin to input connector;
> stdout and
> stderr to output connectors 0 and 1 (CMS Pipelines jargon) and SYSCALL
> spawn.
>

I haven't worked with USS to any real extent, so I can't say for sure.
That said, if you can allocate it to a DD, this should read it and convert
it to EBCDIC.

*"zPipe < ddname=unixinfl | split '0d0a'x | call translate '"**EBCDIC"' |
stack" *

That is, assuming I have the right hex code for CRLF, and you set the
variable EBCDIC to map ASCII as the second parameter to the REXX
TRANSLATE() function.  When you provide two parameters to TRANSLATE(), the
third is assumed to be 256 characters, 00-FF.  (See the code for the zPipe
CALL stage.)

As it stands now there is only one input and one output stream in zPipe.  I
don't know how to think about handling stdout and stderr.  REXX has its own
mechanism for error messages.

I think it might start something like this:

*EBCDIC = left('00'x || "" || '05'x, 32)"
!""#$&'()*+,-./0123456789"* ...

In other words, you list all the ASCII characters in their numeric order.
I left a bunch of blanks where I don't know the equivalents off the top of
my head.

>
> Could such a stage operate concurrently with other stages?  Difficult in
> CMS
> because of the CMS single processor single address space paradigm;
> restrictions not afflicting z/OS.
>

There is no concurrency built into zPipe.  Each stage is invoked only once,
and processes the stack in its entirety, queueing the output to the bottom
of the stack. If you could write a loop that repeatedly issued zPipe to
read from a USS file, you *might *be able to get that to work, but I'm
really sticking my neck out on that one.  The file (UNIX pipe?) would have
to be written to by a separate asynchronous process.  It would be a bit of
a kludge.

Paul, thanks for the great questions!!

Let me know if there is anything else I can do to help.


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

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

Re: Piping for z/OS

[Hobart Spitz]

On Sat, Jan 7, 2023 at 11:17 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 6 Jan 2023 15:33:44 -0600, Hobart Spitz wrote:
> >
> >
> https://docs.google.com/presentation/d/1C7htK9I4rL-4pUZcdhfeA4-IY2Kjxm-HJQ4fuljMs3I/edit?usp=sharing
> >...
> >Would you rather pass data in move mode (*nix piping) or locate mode
> >(Pipes) ...
> >
> How does locate mode deal with a FANOUT stage?
>

Great question Paul.

In Pipelines, the pointer to each record is sent to each output stream in
turn.  Each output stream sees the same buffer as input.  If data is
changed by a downstream stage, a new pointer to a new buffer is created.

In zPipe, the plan is to duplicate the stack the required number of times.
The effect is analogous, but different:  One copy of each data record in
the heap is pointed to two or more times by entries in different stacks.
Each stack can be processed i independently, when it reaches the top.  If
data is changed, new space in the heap is used, and a new pointer to it,
created.

I have a zPipe implementation of LOOKUP that reads the top stack into a
stem as detail records, does a delstack, and reads the next stack as a
master reference.  Then the lookup process proceeds.

I hope this helps.

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

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

Piping for z/OS

[Hobart Spitz]

zPipe is a piping facility for z/OS.  It's available on CBT Tape file1035
on the updates page.

https://www.cbttape.org/updates.htm


The CBT file contains fuller code and more modules than in the presentation
below.

Here is the presentation about it.

https://docs.google.com/presentation/d/1C7htK9I4rL-4pUZcdhfeA4-IY2Kjxm-HJQ4fuljMs3I/edit?usp=sharing



OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

zPipe - z/OS Piping Available as CBT File 1035

[Hobart Spitz]

This is an initial version of zPipe and includes some of the most important
modules.  The primary goal being to get feedback on the approach.  The rest
of the 100 modules are more Pipelines compatible and I hope to add them to
the CBT distribution after I convert them to this technique and finish
testing.

https://www.cbttape.org/ftp/updates/CBT1035.zip


Enjoy!

Oh, and this puts some teeth into the statement, "REXX is the new C."

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: Ad 33rd Rexx Language Symposium coming up next week (September 12th - September 14th 2022)

[Hobart Spitz]

Dr. Rony;

I hope this reaches you in time for a response.

According to my reading of the Symposium schedule, registration should be
starting now.  I don't see an active link for even the "General Meeting."
If I've mis-read or there was a technical issue, please let me know how to
adjust my plans for CDT, Dallas.  As of this writing it is 18:33.

Thanks.

All the best.

- Hobart Spitz
(USA, cell) 443-297-7879



OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Wed, Sep 7, 2022 at 4:48 AM Rony G. Flatscher 
wrote:

> This year's International Rexx Language symposium takes place digitally
> (via Zoom) next week from
> Monday, September 12th, to Wednesday, September 14th.
>
> This year the presentations are scheduled to fit the US American time-zone
> the best. Here the
> easiest way to get there: go to <https://www.rexxla.org/> then click the
> button entitled "2022
> Schedule" on the upper right hand corner.
>
> Note: the presentation schedule times are given in the timezone your
> browser reports, so they are
> displayed in your own local time-zone.
>
> One remark ad those who work in Java here and wish to be able to implement
> Rexx command handlers in
> Java (or NetRexx for that matter): there are two presentations that
> explain and showcase how to
> implement Rexx exit handler and Rexx command handlers in Java. You will
> see that it is fairly
> straight-forward to implement Rexx handlers in Java, allowing one to add
> new command handlers (but
> also replace existing command handlers by new implementations).
>
> And the symposium is *the* opportunity to ask questions in person to all
> the presenters e.g. to Mark
> Hessling (Regina) and anyone else there.
>
> ---rony
>
>
>
>
>
> --
> --
>
> __
>
> Prof. Dr. Rony G. Flatscher
> Department Wirtschaftsinformatik und Operations Management
> Institut für Wirtschaftsinformatik und Gesellschaft
> D2c 2.086
> WU Wien
> Welthandelsplatz 1
> A-1020  Wien/Vienna, Austria/Europe
>
> http://www.wu.ac.at
>
> __
>
> --
> 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: rexx and IDCAMS functions

[Hobart Spitz]

I missed the "authorized" part the first time around.

I don't think anyone has mentioned the TSOEXEC command.  It runs an
authorized command (authorized) from an unauthorized environment.  (No, I
didn't leave out a blank.  TSOEXEC is the full 7 character command name.
Google it.)




OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Wed, Aug 24, 2022 at 1:08 PM Walt Farrell  wrote:

> On Mon, 22 Aug 2022 16:16:06 -0500, Paul Gilmartin 
> wrote:
>
> >Why is there an AUTHPGM NAMES list at all?  Why shouldn't it just be
> >* (everything)
> >???
> >
> >I can imagine several reasons:  Even some authorized programs might not
> >be trusted not to modify the WAITing TSO task (IKJEFTT09?), perhaps by
> >ALLOCATE REUS of a file TSO uses.  Or by modifying TSO storage.  Or
> >by monopolizing a scarce resource (such as a tape drive) during
> programmers'
> >think time.  BTDT; alas no distinction is made between real tapes and
> virtual
> >tapes which are more likely to be plentiful.
> >
> >Is the motive one of these, or something similar?
>
> I cannot provide a definitive answer to that, as I was not involved in any
> of the design for that function.
>
> I can, though, guess that they did not want to assume that every
> APF-authorized program would behave properly when invoked authorized but in
> an unexpected environment, and therefore chose to restrict them unless IBM
> or a customer had specifically listed them as "safe".
>
> >
> >This feels like something that should be programmer-specific , such as a
> RACF
> >profile allowing Lizette but not me the facility.
> >
>
> I don't see a need for saying "program X can run APF-authorized under TSO
> if Lizette runs it, but not if Paul runs it. That is not a function that
> exists when you run a program in batch, for example, and if it were to be
> meaningful in TSO it would also be meaningful in batch.
>
> You can control which users can run which programs (PROGRAM control in
> RACF, though that came later than AUTHPGM), and if an APF-authorized
> program is doing something that should be restricted further, it can do its
> own restource checking (as AMASPZAP does when zapping a VTO).
>
> --
> Walt
>
> --
> 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: rexx and IDCAMS functions

[Hobart Spitz]

IDCAMS commands, like RACF commands are TSO commands.  No need for LINKMVS;
I 've never done it, so it might not even work.

Be sure to follow TSO dataset name syntax: Fully qualified names in
apostrophes or unqualified names without.

"listc ent(ispf.ispprof)"

for example.

On Tue, 16 Aug 2022, 16:36 Paul Gilmartin, <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 16 Aug 2022 14:18:54 -0700, Lizette Koehler  wrote:
>
> >I am going to write a process in REXX using things like DCOLLECT  LISTC
> >etc..
> >
> >I am running into S913-70
> >
> Have you looked at: <
> https://www.ibm.com/docs/en/zos/2.3.0?topic=messages-iec150i>?
>
> >I am trying to figure out what I need to do to resolve it
> >
> >Something in RACF? Pads  IKJTSOxx??
> >
> More details?  What is your code so far?
>
> Is this something that can't be done with ADDRESS LINKMVS IDCAMS?
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Command execution through OUTTRAP giving rc -1645

[Hobart Spitz]

I don't think VARSTORAGE(HIGH) is the best approach.  I would stick with
LOW.  The message suggests that RACF is running out of storage. .OUTTRAP
knows nothing about userlists, so it's probably not an OUTTRAP
message.  Further, the return code is not from OUTTRAP, it is from the
command being executed.  So I would not have thought this is an OUTTRAP
issue..

RACF does not use the same storage as REXX for data.  In fact, they could
compete and lead to an out of space condition, such as you might have here,
with a small REGION= or some other space constraint situation.

FYI:  The following statement is false:
>When you output data to a REXX stem and you use that same
>tem over and over again, the storage for the stem is not reused by REXX.
>In other words, every time you use the same stem name, new storage is
>allocated, the old storage for the stem is not freed

When you give a new value to a variable, a compound variable or a stem, the
old value(s) become/s inaccessible in the data heap.  Individual compound
variables (tails) of the same stem can be widely scattered depending on how
they were allocated, how they were reassigned values, and what else was
going on.  So, it's best not to think of a stem as a block of storage, or
even that consecutive elements have monotonic addresses.

Inaccessible data is called "garbage" and is subject to reclamation via
garbage collection.  After garbage collection, everything accessible is
moved to the beginning of the heap, and the free space is consolidated at
the end.  New data is assigned consecutive addresses as in a stack, until
the space runs out, and garbage collection is needed again.

I don't know how REXX chooses the initial heap size or if a larger heap is
requested as an out-of-space recovery.

So the space for a variable, etc. that is assigned a new value is never
lost.  It is made available again when space runs out and garbage
collection is performed.  It is true that values that are not replaced
continue to take up space unless explicitly or implicitly DROPped.

It is true that values that are not replaced continue to take up space.  If
you assign values to 100 elements of a stem, and then assign new values to
10 of them (without DROPping the stem or changing the default value), the
remaining 90 elements will still exist, take up space, and be accessible by
their tails.  It matters not if the tails are numeric or otherwise.

If you have some pathological case where you have a large stem of many
megabyte strings, using DROP when you are done with it will turn the data
into collectable "garbage" (inaccessible space).  However, if you have a
lot of local variables, compound variables and/or stems, using PROCEDURE [
EXPOSE ... ] will be a tad faster and probably more maintainable.

For example:

UserIdList:

  procedure
  signal on error name RACFNonZeroRC

  call outtrap "RACFOut."

  "Your RACF command"

  call outtrap "off"

  UsrLst = ""

  do iR = 1 to RACFOut.0

  parse var RACFOut.iR /* some pattern to extract a value into UId . */

  UsrLst = UsrLst UId

  end iR

  return Usrlst /* Stem gets dropped implicitly as part of the return. */

RACFNonZeroRC:

  say "RACF command ended with RC" RC

  exit RC


Everytime the function/subroutine returns, the space used by the stem is
made available for reclamation by garbage collection.  The same goes for
UId and iR, in this case.

I hope this helps.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Fri, Apr 8, 2022 at 8:02 AM Seymour J Metz  wrote:

> Unless there is a gateway from the bit.listserv.* news group to the
> listserve, Usenet articles will not be visible on the list. IBM-MAIN used
> to have a unidirectional gateway from listserv to Usenet; that may be true
> for TSO-REXX as well.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Vaid Laturkar [vnath2...@gmail.com]
> Sent: Thursday, April 7, 2022 12:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Command execution through OUTTRAP giving rc -1645
>
> Bob, not sure about it. I have written in group bit.listserv.tsorexx.
>
> On Thu, Apr 7, 2022 at 7:01 PM Bob Bridges  wrote:
>
> > Vaid, I haven't seen this post on TSO-REXX yet, just so you know.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* Hmmm, I found a strange piece of plastic on the floor that looks like
> > it broke off of something, but I have no idea what.  Better save it in
> the
> > junk drawer until I die. */
> >
> > -Original Message-
> > 

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Hobart Spitz]

I think it's worth mentioning that the reason that SET must be
unconditional is that JES has to issue ENQs after, AFAIK, the initial JCL
scan and before execution starts.  If a dataset has an embedded symbolic,
doing the correct ENQ when the value might change at execution time could
cause all kinds of problems, not the least of which is not ENQing on the
intended data set name.

REXX is the new JCL.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Fri, Jan 7, 2022 at 11:50 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote:
> >
> >... I was just
> >working on some JCL and I had just assumed that I
> >could set symbolics using IF THEN ELSE ENDIF:
> >
> >// IF (STEP1.RC = 0) THEN
> >//  SYMB=GOOD
> >// ELSE
> >//  SYMB=BAD
> >// ENDIF
> >
> >but I found out that BOTH SET statements are executed
> >no matter what the return code is .
> >
> Even as in assembler it doesn't work to BC bypassing a SETC.  The JCL
> Ref. is perhaps to specific in listing instructions that are not subject
> to IF ... ENDIF rather than describing which control the Converter and
> which control the Initiator.
>
> >It also appears to me that I cannot put just one DD
> >within an IF statement. It looks an entire step has
> >to be in there... I think...
> >
> And it's truly confusing that if a DD statement is in a step bypassed
> by IF (or COND=) allocation, deletion, or cataloging is not performed
> but the ENQ SYSDSN is still issued.
>
> Would it be a favor to programmers to make misiplacing IF, etc.
> within a job step, or SET within IF ... ENDIF a syntax error?  The
> effect is probably not what the programmers intend.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Using the JOBNAME system symbol in a batch job

[Hobart Spitz]

I've found the REXX function sysvar("symdef", "jobname") words well in more
than one site.


OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, Dec 30, 2021 at 7:21 AM Peter Relson  wrote:

>  and  are not system symbols in the proper usage of the
> term.
> They are symbols that begin with "SYS". They are provided, I presume, by
> JES.
>
> System symbols are well-defined as the set of system-defined static
> symbols (, , , , , ) plus
> the set of system-defined dynamic symbols (of which  is one) plus
> the symbols defined by the customer.
>
>  is defined as being the jobname of the running job, so that using
> it within JCL is not going to give you the name of the job that is going
> to be run, as should be pretty clear from its definition.
>
> System symbols are displayed by DISPLAY SYMBOLS. System symbols are
> processed by the ASASYMBM module. System symbols are initially defined in
> parmlib member IEASYMxx.
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: EAGREX0500E Error 5 . Machine storage exhausted or request exceeds limit in REXX

[Hobart Spitz]

AFAIK, the interpreter uses 31 bit addresses.

The default is LOW probably to ensure compatibility with 24 bit programs.

On Tuesday, December 14, 2021, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 14 Dec 2021 18:38:44 -0600, Hobart Spitz wrote:
>
> >I don't think anyone has suggested PROFILE VARSTORAGE(HIGH).
> >
> Why is that an option, not even the default, in this 21st Century?
>
> What supported interfaces are affected by this?
>
> VARSTORAGE (HIGH)
> indicates that CLIST variables and REXX OUTTRAP variables
> containing output from authorized commands invoked by REXX
> can be kept in storage above the 16M line.
>
> Has this any effect on non-authorized commands?
>
> Is there an above-the-bar variant?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: EAGREX0500E Error 5 . Machine storage exhausted or request exceeds limit in REXX

[Hobart Spitz]

I don't think anyone has suggested PROFILE VARSTORAGE(HIGH).

On Tuesday, December 14, 2021, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 14 Dec 2021 23:14:10 +, Gibney, Dave wrote:
>
> >Can you stop with the non-breaking space failing html
> >
> It's not exactly HTML.  I see:
>
> Content-Transfer-Encoding: base64
> Content-Type: text/plain; charset="gb18030"
> ...
> From: =?gb18030?B?aWJtbWFpbg==?= <...>
>
> But still, something was lost in translation.
>
> >> -Original Message-
> >> ...
> >> REGION=0Misstilllikelytobesu
> >> bjecttosystemwidelimits.
> >> IsitpossibletohaveREXXput&
> >> nbsp;STEMandotherstuffinto64bi
> >> tmemory
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: Replacement for TM instruction

[Hobart Spitz]

Opps:  NC


OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, Dec 9, 2021 at 3:15 PM Hobart Spitz  wrote:

> XC
>
> OREXXMan
> Would you rather pass data in move mode (*nix piping) or locate mode
> (Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
> with more than a dozen filters, while Pipelines specifications are commonly
> over 100s of stages, and 1000s of stages are not uncommon.
> REXX is the new C.
>
>
> On Thu, Dec 9, 2021 at 3:11 PM Ituriel do Neto <
> 03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Hi all,
>> I would like advice because i have a situation where i need to check a
>> bit of a storage area, usinganother storage area as a pattern and not an
>> immediate.
>>
>> I have something like this :
>> A   DCX'1C'B   DCX'08'
>>  TMA,x'08' JOX
>> But instead of using x'08', i need to use the variable B in the
>> comparison, because the content of B may change.So, i would need something
>> like this:
>>  TM  A,B
>> How can i do that ?
>> Thanks in advance.
>> Best Regards
>>
>> Ituriel do Nascimento Neto z/OS System Programmer
>>
>>
>>
>> --
>> 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: Replacement for TM instruction

[Hobart Spitz]

XC

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, Dec 9, 2021 at 3:11 PM Ituriel do Neto <
03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote:

> Hi all,
> I would like advice because i have a situation where i need to check a bit
> of a storage area, usinganother storage area as a pattern and not an
> immediate.
>
> I have something like this :
> A   DCX'1C'B   DCX'08'
>  TMA,x'08' JOX
> But instead of using x'08', i need to use the variable B in the
> comparison, because the content of B may change.So, i would need something
> like this:
>  TM  A,B
> How can i do that ?
> Thanks in advance.
> Best Regards
>
> Ituriel do Nascimento Neto z/OS System Programmer
>
>
>
> --
> 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: DFSORT- SORT OUT FILE Sequence is not in order

[Hobart Spitz]

Really  How is your solution a single instruction?

Here are single instruction solutions.

"pipe < ddname=sortin | sort unique | > ddname=sortout"
or
"pipe < your.data | sort unique | > your.output
or
// EXEC PGM=PIPE,PARM='< your.data | sort unique | > your.output'

People really need to stop thinking in terms of JCL and old, slapped
together utilities.

Don't have the PIPE command?  It's included with BatchPipes.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, Nov 11, 2021 at 6:50 AM Ron Thomas  wrote:

> Thanks a lot Massimo. It worked like a charm :)
>
> Thanks,
> Ron T
>
> --
> 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

Piping under ISPF

[Hobart Spitz]

Cross posted to IBM-MAIN, TSO REXX, and Pipelines.

 The ISPF stacking character can be set to "|", but TSO tries to execute
the passed stack data after each command.  If that could be disabled, data
could be passed from program to program, providing a stack based piping
capability.
Does anyone know how to disable stack data being executed?
Could it be a viable requirement candidate to have two command
delimiters, one that executed the stack and one that didn't?

Thanks!!

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

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

Re: automated SMS Storage pool management

[Hobart Spitz]

Years ago, before HSM, I wrote some code to deal with issues like this.
IIRC, it went something like this.

   - About 4 times a day a job would run to identify problem packs
   (volumes) by relative ranking, noting the 4 worst of each.  IIRC, it used
   the LSPACE(?) macro.
  - Low free space.
  - Many high extent datasets.
  - Many over allocated datasets.
  - High fragmentation.  (Probably not needed today at most sites.)
  - etc.
   - The collected statistics and problem flags were stored in ISPF tables,
   one per volume.  An ISPF dialog allowed review of the chronological
   movement of the state of each volume.  The information allowed day and
   shift when a problem began.  A DASD manager could manually flag additional
   volumes for specific mitigation(s).
   - At about 3 AM, a second job would run to process the list of "problem
   children" and submit various DFDSS jobs to address the specific problems
   identified on the specific packs.
  - Defrag fragmented packs.
  - Compress high extent PDSs.
  - Free unused space on over allocated datasets.
  - Migrate dataset high extent datasets from fullis packs to high free
  space packs.
  - etc.

This was before the SCHEDULE JCL statement, ISPF LMDINIT/LMDLIST, and REXX
on z/OS, so it should be a piece of cake to do something like this today
today.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, Nov 4, 2021 at 8:08 AM kekronbekron <
02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:

> Hi Dave,
>
> What you've mentioned will work.
> A cyclic automation rule that runs a REXX which does the following:
> 1. D SMS,SG(ALL) and parse its output (or maybe individual commands for
> just the SGs you're interested in, to simplify parsing)
> 2. Check for availability of DISNEW volumes
> 3. V SMS command to ENABLE the volume
> https://www.ibm.com/docs/en/zos/2.4.0?topic=command-changing-sms-status-storage-group-volume
> 4. Email about the performed action and maintain a simple status file
>
>
> - KB
>
> ‐‐‐ Original Message ‐‐‐
>
> On Thursday, November 4th, 2021 at 4:30 PM, Dave Jousma <
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> > All,
> >
> > I'm sure someone has solved this. I'm now managing DASD management at my
> shop. One thing that bothers me is my guys getting off-shift calls because
> some active storage pools fall below a % threshold of freespace. We arent
> skimpy on provisioning, but dont want to over-provision either. We are IBM
> system automation shop, and I asked IBM if there was any "out-of-the-box"
> automation for SMS we could start with and tailor to our needs. Nothing.
> Not looking to fully automate storage pool management, but something along
> the lines of having some number of volumes in DISNEW status, that could be
> enabled via automation - saving that middle of the night call-out, but to
> follow-up on next business day.
> >
> > Anyone doing anything like this, case to share?
> >
> > Thanks in advance, Dave
> >
> >
> 
> >
> > 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: Question about negative indexes

[Hobart Spitz]

AFAIK, RXY format instructions support negative offsets just fine.

LHY 5,-1(0,12)

On Sun, 24 Oct 2021, 7:55 am Peter Relson,  wrote:

> Eric R posted (from the PoP):
> 
> When, during the generation of the address, an
> address is obtained that exceeds the value allowed
> for the address size (2^24 - 1, 2^31 - 1, or 2^64 - 1), one of
> the following two actions is taken:
>
> 1. The carry out of the high-order bit position of the
> address is ignored. This handling of an address
> of excessive size is called wraparound.
>
> 2. An interruption condition is recognized.
>
> ...
>
> Addresses generated by the CPU that may be virtual
> addresses always wrap.
> 
>
> That post omitted this phrase from the PoP that follows shortly after:
>
> For CPU table entries that are addressed by real or absolute addresses, it
> is unpredictable
> whether the address wraps or an addressing exception is recognized.
>
> Paul G wrote:
> 
> An interrupt condition is *never* recognized "during generation of [an]
> address."
> 
>
> Therefore we conclude that this statement is not correct for the case of
> CPU table entries addressed by real or absolute addresses.
> (I don't know exactly what a "CPU table entry" is in this context.)
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

TSO Pipe command (Was: Re: [EXTERNAL] Re: Mainframe Modernization)

[Hobart Spitz]

Ed, Johnathan;

You guys are *so *lucky.

A few quick notes to get you started:

   - Unlike Unix piping, terminal output from the last stage is not
   implied.  (You'll find this makes sense later.)
   pipe < some.dsn | count words lines | term
   - The <, >, and >> are filters on their own, also unlike Unix.  (You'll
   see this makes sense later.)
   - Pipes I/O is better than execio.  You can read and write both datasets
   and DD names:
   "pipe < ddname=sysut1 | translate lower | > lower.case"
   - Pipes is integrated with REXX.  You can use variables and stems:
   "pipe var fred | split | stem fredwords."
   -
   - Stay with single stream piping for now.  You can do a lot with single
   streams before you need to go to the next level.
   - Stages can be aware of their position in the stream.  Some stages
   behave differently depending where they appear, especially in first
   position.  (You'll also see that this makes sense later.)
   - *pipe help   count* and/or *pipe ahelp translate* is a full-screen
   resource.   *pipe help*  for a menu.

Take a look at the marist.edu pipeline site, especially Melinda Varian's
introduction to pipes.

Be prepared to blow the minds of your coworkers and your management

I'll be happy to help in any way I can.

When I first tried Pipes, not giving a pipe specification just gave an
obscure syntax error.

Good luck.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, Oct 21, 2021 at 10:59 AM Ed Jaffe 
wrote:

> On 10/21/2021 8:18 AM, Nash, Jonathan S. wrote:
> > ... I just tried TSO PIPE and it worked
>
>   READY
> pipe
>   BPW00256I Enter a pipeline specification
>   READY
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> 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

Comparison of UNIX piping, Pipelines (and JOB) ALU usage.

[Hobart Spitz]

Cross posted to IBM-MAIN and CMSTSO-Pipelines lists.

Overview:

   1. An ALU (Arithmetic Logical Unit) load estimation shows CMS/TSO
   Pipelines is orders of magnitude more ALU efficient than UNIX piping.
   2. UNIX piping is significantly better than JCL step-to-step data
   passing and, consequently, Pipelines is also better.  (P>U, U>J, therefore
   P>J.)
   3. It will take a lot of pressure to get TSO Pipes or BatchPipes into
   the z/OS base.
   4. Customers will only bring pressure if they have good reason, for
   example, by using BatchPipes, which includes TSO Pipes..
   5. Installing BatchPipes is one way to experience Pipelines and the
   benefits of BatchPipes fittings in JCL
   6. A few successful pilot programs might break the ice and make this
   "piping-on-steroids" tool available to all z/OS users.

Details::

Below is the output from a program estimating the ALU usage of Pipes versus
that of UNIX command piping.  I chose to estimate the number of characters
reaching the ALU (Arithmetic Logical Unit)  because the measure might be
less affected by hard to account for factors, like system load, instruction
pipelining, out of order execution, and caching behavior.  If there were
just a few referenced fields in a record and they were close to each other,
only one or two cache lines might need to be loaded in Pipes.  Conversely,
if there were many referenced fields and they were widely spread around the
record, more cache lines might need to be loaded.

Comparison of UNIX piping vs. CMS/TSO Pipelines based on
estimated characters reaching ALU.
Fraction of bytes used by average Pipes stage: 0.25
UNIX piping ALU usage / Pipelines ALU usage
+---++++
|   |__ Record Sizes __|
|Stages | 25 |250 |   2500 |
+---++++
|10 | 55 |134 |157 |
|   100 |548 |   1342 |   1570 |
|  1000 |   5479 |  13423 |  15699 |
+---++++
Note:  UNIX performance drops with both more stages and longer records.
Working set size was not taken into account.
Accounting for working set size would involve 64K*Stages for UNIX.
That would increase the Pipes advantage even further.


0.007000 elapsed seconds.


Note that both increasing the number of stages and increasing the logical
record length independently improved Pipelines performance.  This is not
surprising as, in UNIX, data must be copied from the input buffer to the
output buffer at each and every stage.  In Pipelines, such copying rarely
occurs and only referenced data need reach the ALU.  File size has no
significant bearing on this calculation.  As noted, taking working set size
into account probably would show even better numbers for Pipelines.

These calculations are guesstimations.  That they show an
orders-of-magnitude difference means that exact numbers are not important.
What is important is that a 100 fold or 1000 fold improvements are
possible.  Here is a snippet showing the basics.  The rest was formatting.:

...
/* Est. Bytes used (10%) + changed rcds (10%) + delayed rcds (5%).*/
PipesBytesUsedFract = 0.25
/* In other words, fraction of file bytes that actually enter ALU.*/
...
/* Estimate number of bytes per record that are used by the ALU.  */
/* Account for UNIX DBCS, UNIX stage write, and Pipes structures. */
UNIX:
  return LR.iLR * Stages * 2 * 2


Pipes:
  /* Parm pointer (4) + #Record descriptor (8)*/
  return LR.iLR * PipesBytesUsedFract + 12
...


Consider the cell in the middle row and the middle column (1342).  If a
process ran for an hour with heavy UNIX piping, it could take as little as
2 seconds (3600/1342=1.937) using Pipes.  (If it was I/O bound, it might
take longer.)  On the other hand, what takes multiple UNIX piping commands
might be just a single Pipe command.  Real world testing would be best.
That said, ALU usage is tied to working set size, cache load and
CPU usage.  (CPU usage includes the whole instruction pipeline.  ALU is
just the final stage, which operates mostly in parallel with the rest of
the instruction pipeline.)  Further, this might explain why IBM suddenly
added multiple additional cache levels at the same time they were pushing
UNIX and C.

If you could get the Flash on your baseball team, wouldn't you have him
running bases?  (Hmmm.  I've never liked the names BatchPipes and
BatchPipesWorks.  It's as if someone wanted to doom the products by giving
them awful names.  How about FlashBatch and FlashPipes?)

These huge numbers might explain some of the IBM resistance to Pipes in the
z/OS base.  Major revenue leveling could be a valid concern (but a windfall
for customers).  Realistically, it would depend on the rate of adoption and
reimplementation to Pipes, and could be mitigated by appropriate marketing
efforts to attract new customers.  Could there be a legal argument that,
since hardware revenue growth would be reduced and/or global warming
mitigated, making 

Re: The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[Hobart Spitz]

Gil wrote:
>On Mon, 27 Sep 2021 07:26:51 -0500, Hobart Spitz wrote:
>>I'm going to pivot here.  I'm putting my support behind putting BatchPipes
>>in the z/OS base (rather than just Pipes).  If you agree, please
>>write/support such a requirement and/or educate your management to get
>>interested.  BatchPipes includes BatchPipesWorks, a not so current, but
>>still highly useful, version of TSO Pipelines.
>>
>Is an RFE for an update required?  Conway's Law.

Great question.  I guess it would depend on whether the were a lot of
current BatchPipes customers needed the missing builtin stages and/o
fix(es) or whether it was more important to get BatchPipes in the z/OS
base.  It might also depend on how much additional work would be required
to get a more current version of Pipes into BatchPipes, and whether the
staff, skills, and funding were available.  IMHO, the update would delay
the benefits of BatchPipes in the base (especially global warming
mitigation), and not be important to current BatchPipes customers.  In my
estimation, BatchPipesWorks has 90% of the needed stages and 99% of the
fix(es) as would be in an up to date version of TSO Pipelines.  I find the
IBM decision making process obscure, so these may not be the considerations
that affect the final decision.

AFAIK, there is only one person now working on Pipes, so I must be missing
something in applying Conway's law.

> Does BatchPipes support connecting two Classic modules with an intervening
> small Pipeline filter?  How?  Is a coordinated third job needed?

Let me clarify some terms, answer you questions in the process, and clarify
my previous post:


Inter-JOB pipe - This is a ppe that let's two JOB pass records from one to
the next thru memory.  The BatchPipes subsystem(s) is/are required.
AFAIK:  There are no obvious limitations to the topology.  You can have
multiple JOB connected in a single "stream", split and/or join streams, or
even have loop(s).  In this respect, it is similar to the PIPE command,
except that the record flow with split and rejoined streams may not be
predictable between JOBs.

Half Pipe Fitting or Intra-STEP pipe - This is a series of Pipes stages
that operate between a program in a step and the storage medium.

Intra-JOB pipe - This would be similar to VIO; it doesn't exist otherwise.
I think it would be a great feature.  Hence I incorrectly used the term to
refer to Half Pipe Fittings in a generic sense.  Apologies for any
confusion.


AFAIK, and if I understood your question, connecting two classic programs
in the same step with a series of Pipes stages may not be  possible now, at
least without resorting to Assembler.  I think the main reason is the
potential for DD name conflict, both in the TIOT (DD name table) and in
JCL.  Most COBOL programs require SYSOUT, so the output could be
intermixed.  Much less tolerable, I suspect, would be a common DD (e.g.
OUTPUT) conflict.  Putting a record that doesn't belong between two records
that must be consecutive would probably be a disaster.

That said, it may be possible for a REXX filter to start two COBOL (e.g.)
programs as subtasks (address attach ... , etc.) and feed and receive their
records via an Assembler(?) Pipe Fitting.  You would have to resolve any DD
name conflicts.  I don't think anyone has contemplated the capability for
creating multiple TIOTs in a single step, let alone how to reference them
in JCL.  I think such things have been done under CMS using Assembler.

Also:

pipe - a generic connection, in memory, between two processes or tasks.

Pipes - the TSO/CMS Pipelines software, singular.

Pipe - a specific instance of Pipes.

PIPE - the command that runs Pipes.


OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
IBM has been looking for an HLL for program products; REXX is that language.


On Mon, Sep 27, 2021 at 9:10 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 27 Sep 2021 07:26:51 -0500, Hobart Spitz wrote:
>
> >I'm going to pivot here.  I'm putting my support behind putting BatchPipes
> >in the z/OS base (rather than just Pipes).  If you agree, please
> >write/support such a requirement and/or educate your management to get
> >interested.  BatchPipes includes BatchPipesWorks, a not so current, but
> >still highly useful, version of TSO Pipelines.
> >
> Is an RFE for an update rrequired?  Conway's Law.
>
> Does BatchPipes support connecting two Classic modules with an intervening
> small Pipeline filter?  How?  Is a coordinated third job needed?
>
> >The reasons are:  [Snip!  See the archive.]
>
> -- gil
>
> ---

The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[Hobart Spitz]

I'm going to pivot here.  I'm putting my support behind putting BatchPipes
in the z/OS base (rather than just Pipes).  If you agree, please
write/support such a requirement and/or educate your management to get
interested.  BatchPipes includes BatchPipesWorks, a not so current, but
still highly useful, version of TSO Pipelines.

The reasons are:

   1. The audience that could benefit from BatchPipes in the base is much
   larger than that of TSO Pipes in the base.  The former includes
   organizations that:
  - Have a limited batch window or want to reduce JOB run times.
  - Are constrained on developer resources.
  - Want to reduce hardware requirements.
  - Require quick resolution to production problems.
  - Have a policy to reduce their carbon footprint and/or their
  contribution to the climate crisis.
   2. It is unrealistic to expect wide buy-in for TSO Pipes since most z/OS
   sites are highly dependent on JCL.
   3. BatchPipes in the z/OS base would be the biggest enhancement to JCL
   since it (JCL) came into existence.
   4. BatchPipes in the base would improve the competitiveness of z/OS.
   5. IBM, vendors, and customers would benefit from the capability by
   being able to write quicker running, more general, less complicated JCL,
   knowing that BatchPipes would be available on all target systems.
   6. All parties could potentially benefit from having the PIPE command
   available on all target systems.
   7. BatchPipes fittings could enhance and extend existing programs and
   utilities with a consistent, intuitive, and uncomplicated control
   language.  Too many utilities have unique, inconsistent, and/or complex
   control languages.
   8. Contribute to global warming mitigation by reducing electricity usage
   due to processors, storage hardware and cooling.  This is more significant
   with BatchPipes as there is likely to be a larger impact in a shorter
   amount of time than with just Pipes alone.  The latter would be adopted
   more slowly and less broadly.  Climate crisis mitigation efforts may be
   exempt from the rumored requirement that IBM is legally barred from
   offering software at a loss.  (IMHO,  the huge number of competitors to IBM
   in today's market, suggests that any such requirement is obsolete and
   should be removed.)
   9. There would be some portability between z/VM and z/OS.
   10. Despite wide support, Pipes requirements have not budged for
   decades  .

Anyone so inclined, is welcome to submit such a requirement, adapt my Pipes
requirement, and/or work with me on a new requirement.  Of course, if you
agree, vote for the requirement.  Can the current Pipes requirement be
construed to support BatchPipes?  Is it too much to expect BatchPipes to be
added to the z/OS base without the delay of waiting for requirement(s),
voting, and acceptance.

Alternatively, BatchPipes and the REXX Compiler, possibly along with other
software, could be packaged together as a combined product, perhaps with a
performance or global warming mitigation theme .  Another possibility would
be to offer BatchPipes Light, where the intra-JOB piping was offered free
or in the base.  Half pipe fitting might be a loss-leader to attract
customers to the full product.

As a developer, I love REXX and I love Pipes.  Together, they are
programmer heaven, more so than OO.  Whenever I write something new,
whether in z/OS or z/VM, I write a REXX EXEC.  Under z/OS, I SPAWN the EXEC
when I want to run it in batch.

I have used BatchPipes only briefly, but I know Pipes fairly well.  Pipes
are the language of BatchPipes fittings, which essentially is an
enhancement that allows Pipes stages to run on most DDs between the program
and the storage media.

I don't like BatchPipes.  They require opsys or sysprog assistance and are
too much trouble to use.  They support inter-JOB piping which requires a
subsystem and makes the real valuable part (Half Pipe Fittings) complicated
and hard to use.  Since I almost never use JCL, I have no use for them.  I
can, however, see their use and, as listed above, their value to the z/OS
community as a whole.

That said, for the rest of this note, I will PRETEND to be someone with
production support responsibilities.  If some of these things have no
connection to anything that any site would actually do, I apologize.  I'm
just a color-blind painter trying to paint a picture that will give you the
idea.


In an imaginary future, some production control person may write:

I love BatchPipes!  Since we started using it, our batch production run
time has steadily dropped and is now just 20% of what it was.  We were able
to shorten the run-times of the longest running JOBs to a small fraction.
The DBAs love that they can start their maintenance and backups earlier and
with plenty of time to spare.

Much of the time, instead of writing a new 

The Business Case for **BatchPipes** in the z/OS Base

[Hobart Spitz]

As a developer, I love REXX and I love Pipes.  Together, they are
programmer heaven.  Whenever I write something new, whether in z/OS or
z/VM, I write a REXX EXEC.  Under z/OS, I SPAWN the EXEC when I want to run
it in batch.

I have used BatchPipes only briefly, but I know Pipes fairly well.  Pipes
are the language of BatchPipes Fittings, which is essentially an
enhancement to allow Pipes stages to run on most DDs.

I do not like BatchPipes.  They require opsys or sysprog assistance and are
too much trouble to use.  They support inter-JOB piping which makes the
real valuable part (intra-step piping) complicated and hard to use

That said, for the rest of this note, I will PRETEND to be someone with
production support responsibilities.  If some of these things have no
connection to anything that any site would actually do, I apologize.  I'm
just a color-blind painter trying to paint a picture that will give you the
idea.


In an imaginary future, some production control person may write:

I love BatchPipes!  Since we started using it, our batch production run
time has steadily dropped and is now just 20% of what it was.  We were able
to shorten the run-times of the longest running JOBs to a small fraction.
The DBAs love that they can start their maintenance and backups earlier and
with plenty of time to spare.

Much of the time, instead of writing a new step or a new JOB, we can
accomplish the same thing with no new code, other than a JCL change.  We
just put a pipe fitting on a DD.  It can be a temporary override or a
permanent change.

Did we get a dataset with the wrong DCB?  Add a pipe fitting to the DD.  No
need to copy over the dataset.

Did we get raw, unconverted  ASCII data in transmission?  No problem.  Pipe
fitting!

Did the developer forget to add record counts to the summary report ?
Easy-peasy!  Add pipe fitting to the DDs.

It doesn't matter if it's too big for ISPF EDIT.  The size of the files
that we can fix are not limited to available memory.  There seems no
noticeable increase in resource usage or run time when we address a
production problem this way..

One of our developers had this crazy idea to convert all our JCL and COBOL
to REXX and Pipes.  That's not happening.  On the other hand, I'm going to
propose that special approval be required to develop and put into
production any new JCL streams or COBOL programs.  That guy had taken a
600+ line COBOL program and rewrote it in a Pipe command of a dozen lines.
Granted it had been over-maintained and had lot's of unreachable, fossil
code.  That's the problem with JCL and COBOL.  There are not enough real
comments and it's all too verbose to understand the big picture.

BatchPipes Fittings are the greatest enhancement to JCL since the first
days of OS/360 JCL in the 1950s.

I'm so glad IBM put BatchPipes and the REXX compiler in the z/OS base.
It's made my job so much easier.  No panic fixes or work-arounds.  No
complicated control cards.  No OPENs, READ-WRITE loops, EOF logic or
CLOSEs.  Just simple, reliable changes, done right the first time.  We
haven't needed to use the REXX Compiler, but we're glad to have it in case
we need a Plan B.

End of "production control person" comments.


Granted, it 's not the most entertaining fiction ever written, not by a
long shot.  I hope it got the idea across.


OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
IBM has been looking for an HLL for program products; REXX is that language.

--
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]

Martin wote:
>I'm not familiar with FANOUT but if it writes a record to, say, two
destinations, it's got to copy one of them.

Actually not.  I know it sounds like magic, but there is still only one
copy.  I'll give you my best rendition of what I think is happening.  Don't
worry if you don't get the whole picture.  I had to work with Pipes for
many years before I understood this.

Pipes manages the storage for records.  When a new record is created (or
modified) Pipes allocates the space for it.  That pointer is what a stage
gets when it asks for an input record.  When an input record is no longer
needed by a stage, Pipes is informed.  This is referred to as "consuming"
the record.  In fact, the record is not "consumed", as in grinding with
teeth and digesting, rather it is how a stage tells Pipes that it's done
with the record.

Changes are made to new storage at a new record address.  Changing a record
means getting new storage and building a new record, with the changes.  The
input record is not changed, and it can be inspected by other streams via
FANOUT or any multiwrite stage.  When the storage area of a record is no
longer used by any stage, i.e., no stage has a pointer to it, that storage
can be reclaimed by Pipes.

I don't know the exact mechanism, but that's it at a high level.  No matter
how many streams and stages use a record, there is only one copy. DUP, for
example, could just write the record over and over using the same pointer.
(I don't know that for a fact, but John Hartmann is a lot smarter than I.)

The majority of Pipes building stages do not modify their input records.
(With REXX user written stages, there always is a new copy on output, even
if no changes were made to the data.)


OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
IBM has been looking for an HLL for program products; REXX is that language.


On Thu, Sep 23, 2021 at 9:44 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 23 Sep 2021 09:30:43 +0100, Martin Packer wrote:
>
> >I'm not familiar with FANOUT but if it writes a record to, say, two
> >destinations, it's got to copy one of them.
> >
> It could be deferred; Copy-on-Write, optimizing for what Hobart earlier
> calledd the "typical case" of stages that don't modify the data.
> But incurring the complexity of a responsibility count.
>
>
> >From:   "Hobart Spitz"
> >Date:   23/09/2021 04:18
> >
> >>  I'm guessing the atypical case is a stage such as FANOUT which
> >> necessarily copies the data.
> >
> >Not sure what you mean by atypical.
> >
> I apologize; I trimmed your earlier mention of "typical case".
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

[Hobart Spitz]

Phil, thanks again for the helpful feedback and the great food for thought.

Your point is well taken.

I'll try to break it down as best I can:  MIPS or CPU usage, main memory or
working set, and input/output operations.  (I'd be happy if someone else
has better information.)

MIPS is dependent on at least three things:  Arithmetic Logical Unit (ALU)
usage, instruction pipeline activity, and cache misses.  With Pipes, ALU
and instruction pipeline usage would be more intense, while cache misses
would be less so.  Many characters, ones that the Pipes stages never even
look at, won't even enter the cache and ALU.  Some data can be processed
through thousands of stages and only be cache missed a few times, because
stages are typically dispatched one after the other to process the same
record.  Compared to UNIX piping, where every character of a text file must
go through every stage, even if it is going to be ignored, Pipes is much
faster.  As Melinda Varian says (approximately):  This is an advantage of
file structure aware operating systems.  I could include Pipes as
systems software.

Main memory (i.e., non-cache) and working set affect how fast instructions
can be executed.  As with characters, records can enter and leave the
working set just a few times, and still be processed by thousands of
stages.  So the working sets of Pipes will mostly tend to be much lower.
Stages like TAKE and DROP can do their work without ever referencing a
single byte of the records being processed.  (With UNIX head and tail,
every character must be inspected by the CPU.)

Finally, there is I/O, which is where Pipes and even UNIX piping really
shine.   The fastest input and output operations are the ones that never
take place.  Records moved from program to program in memory skip I/O.  I/O
generally involves some kind of mechanical movement, and which is far
slower than the CPU, caches or real memory.

Taken together, a set of Pipes stages, whether in a TSO PIPE command or in
a BatchPipes Fitting on a DD, \will have a smaller average working set and
spend less time in the system than alternatives.  If we estimate costs as
WS*ER (working set size times elapsed residency), even a conservative 50%
reduction in each would mean about a 75% reduction in hardware usage.
(WS*0.5)*(ER*0.5) = WS*ER*0.25.

If you have been paying attention, I have purposely glossed over some
details.  Unreferenced characters may be cache loaded because they reside
on the same cache line as referenced characters.  Also, record length and
blocking factor, among other things, affect how fast data can reach main
memory, the caches, and then the ALU.  On the average, I don't think these
two details change the relative effects of Pipes processing versus
conventional processing..

I suspect that UNIX piping was the inspiration for Pipes (A.K.A. CMS/TSO
Pipelines and BatchPipesWorks) both in suggesting in-memory "I/O" as well
as improvements to the concept.

I hope this helps.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
IBM has been looking for an HLL for program products; REXX is that language.


On Mon, Sep 20, 2021 at 8:10 PM Phil Smith III  wrote:

> Hobart Spitz wrote, in part:
>
> >This is a great comment.  I hadn't given that much thought to the
> question.
>
> >Not to split hairs, but I didn't say MIPS, I said hardware.
>
> >If I had to guess, MIPS usage might actually increase slightly, because
> the
> >Pipes dispatcher has to switch between stages twice for every record that
> >is passed.
>
>
>
> Sure, just sayin' you'd want to be very clear about what you do mean.
>
>
>
> I'm not quite sure what you mean by "more MIPS but less hardware", though?
>
>
> --
> 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: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)

[Hobart Spitz]

Mike wrote:
>Could something be developed similar to a SORTOUT exit that implements
this switch?
BatchPipes fittings are like sort exits on steroids:  They can be applied
to almost any DD, can use most Pipes filters, do not require compiled code,
and they are not restricted to a single program.  I plan to say more
later.  In a nutshell:  I think BatchPipes, including the Pipe command,
should be in the z/OS base.  It would be the biggest enhancement to JCL
ever, and would be of much more interest to production oriented management
who care about stability.


OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
IBM has been looking for an HLL for program products; REXX is that language.


On Mon, Sep 20, 2021 at 7:11 PM Mike Schwab  wrote:

> So, in a sense, instead of pipes, the programs could be modified so
> that instead of outputting a record, call the next program passing the
> record as input.
>
> Could something be developed similar to a SORTOUT exit that implements
> this switch?
>
> On Mon, Sep 20, 2021 at 4:27 PM Hobart Spitz  wrote:
> >
> > Phil;
> >
> > This is a great comment.  I hadn't given that much thought to the
> question.
> >
> > Not to split hairs, but I didn't say MIPS, I said hardware.
> >
> > If I had to guess, MIPS usage might actually increase slightly, because
> the
> > Pipes dispatcher has to switch between stages twice for every record that
> > is passed.  Access method overheard would drop.  Buffered access methods,
> > in most cases, only have to increment the pointer into the block buffer,
> > check for end-of-buffer and return to the caller.  I don't know for sure
> > which is larger.  Maybe someone more knowledgeable than I can shed some
> > light.
> >
> > I would say the real savings would be in elapsed run time and working set
> > size.  Run time, due to eliminating something like 80-95% of I/O
> operations
> > for intra-JOB datasets.  Working set reduction would save on real memory.
> > (See below.)  Run time is probably more of a concern to customers,
> > especially those with tight batch windows.  That said, working set size
> > reduction would mean that processors would likely spend more, if not all,
> > time pegged at 100% busy, because so many more address spaces (TSO and
> JOB)
> > would be in a swapped-in and ready state than before.  Depending on what
> > metrics the capacity planners are looking at, CPU sales might actually
> > increase.  As I think about it more, if thru-put increases, new data
> could
> > be generated more quickly and other times of hardware could be more in
> > demand during peak load times.  I just don't know enough to say for sure.
> >
> > Phil and others know what follows.
> >
> > For those who don't know, in the typical case, a record passes through
> all
> > possible stages before the next record begins the same trip.  Each record
> > stays in the working page set, at least partially, during the entire
> time.
> > Parts that are referenced have a good chance of staying cache resident
> > between stages.
> >
> > Think of it this way:  You can visualize UNIX piping as a series of
> > hourglasses open at both ends and connected in a tower.  Each grain of
> sand
> > must stop at every "stage" and wait its turn to go through the narrow
> > opening at the waist of each hourglass.  In Pipes, most stages have no
> > delay and it's like a single tall hourglass tube with only one narrow
> > point.  My best guess is that Pipes, in this analogy, would have only
> > 5%-15% of the narrow openings as an equivalent UNIX piping command,
> meaning
> > that the data (sand) would flow 85-95% faster in the Pipes "hourglass".
> >
> >
> > OREXXMan
> > Would you rather pass data in move mode (*nix piping) or locate mode
> > (Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
> > with more than a dozen filters, while Pipelines specifications are
> commonly
> > over 100s of stages, and 1000s of stages are not uncommon.
> > IBM has been looking for an HLL for program products; REXX is that
> language.
> >
> >
> > On Mon, Sep 20, 2021 at 12:48 PM Phil Smith III  wrote:
> >
> > > Hobart Spitz wrote, in part:
> > >
> > > >The case *for *Pipes in the z/OS base.:
> > >
> > > > 2. Hardware usage would drop for customers.
> > >
> > >
&

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

[Hobart Spitz]

Paul said:
>  I'm guessing the atypical case is a stage such as FANOUT which
necessarily
copies the data.

Not sure what you mean by atypical.  FANOUT is typical in the respect that
it doesn't create an actual copy of the input record.  It just looks like
it.  FANOUT, and non-record-changing stages, pass the same input record
pointer to their downstream stage(s).  This is what makes Pipes so
efficient.  No working set expansion and less reloading of just purged
cache data.



OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
IBM has been looking for an HLL for program products; REXX is that language.


On Wed, Sep 22, 2021 at 3:13 AM Martin Packer 
wrote:

> Conversely a pipe as input is not necessarily a good input medium for a
> sort. 10 years ago I contributed to a Batch Modernization Redbook on this,
> emphasising the need for BatchPipes input to DFSORT to be accompanied by a
> FILSZ / AVGRLEN estimate pair.
>
> Bringing it back to pipes, I wonder if it's feasible to tell a sorting
> stage (whether DFSORT (yes please Sri Hari) or otherwise) the input size.
> Otherwise we could have blow ups or bad performance at scale.
>
> BTW I'm all in favour of pipes as a first class citizen but note I have
> little influence in this regard.
>
> Cheers, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://anchor.fm/marna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   22/09/2021 03:50
> Subject:[EXTERNAL] Re: The Business Case for Pipes in the z/OS
> Base (was: Re: REXX - Interpret or Value - Which is better?)
> Sent by:"IBM Mainframe Discussion List" 
>
>
>
> On Tue, 21 Sep 2021 21:03:14 -0500, Mike Schwab  wrote:
>
> >If a SORT (or other similar temporary data store) program is one of
> >the pipe programs, when the EXEC PGM= program closes the output file
> >then the program holding the data needs to output the stored data to
> >output ddnames (pipe or output files).
> >
> Are you thinking of MS-DOS pseudo-"pipes" where the upstream program
> wrote a temporary file under-the-covers and the downstream program
> processed it?  A pipe in syntax only.  Even Windows is better nowadays.
>
> SORT is a bad conceptual example for Pipethink because SORT can't
> write its first output record until it has read its last input record.
> Better
> to envision a filter which re-formats log records from a long-running (or
> never-terminating) program, writing a file to be browsed with SDSF or
> tail -f in real time.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> 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 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: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)

[Hobart Spitz]

Phil;

This is a great comment.  I hadn't given that much thought to the question.

Not to split hairs, but I didn't say MIPS, I said hardware.

If I had to guess, MIPS usage might actually increase slightly, because the
Pipes dispatcher has to switch between stages twice for every record that
is passed.  Access method overheard would drop.  Buffered access methods,
in most cases, only have to increment the pointer into the block buffer,
check for end-of-buffer and return to the caller.  I don't know for sure
which is larger.  Maybe someone more knowledgeable than I can shed some
light.

I would say the real savings would be in elapsed run time and working set
size.  Run time, due to eliminating something like 80-95% of I/O operations
for intra-JOB datasets.  Working set reduction would save on real memory.
(See below.)  Run time is probably more of a concern to customers,
especially those with tight batch windows.  That said, working set size
reduction would mean that processors would likely spend more, if not all,
time pegged at 100% busy, because so many more address spaces (TSO and JOB)
would be in a swapped-in and ready state than before.  Depending on what
metrics the capacity planners are looking at, CPU sales might actually
increase.  As I think about it more, if thru-put increases, new data could
be generated more quickly and other times of hardware could be more in
demand during peak load times.  I just don't know enough to say for sure.

Phil and others know what follows.

For those who don't know, in the typical case, a record passes through all
possible stages before the next record begins the same trip.  Each record
stays in the working page set, at least partially, during the entire time.
Parts that are referenced have a good chance of staying cache resident
between stages.

Think of it this way:  You can visualize UNIX piping as a series of
hourglasses open at both ends and connected in a tower.  Each grain of sand
must stop at every "stage" and wait its turn to go through the narrow
opening at the waist of each hourglass.  In Pipes, most stages have no
delay and it's like a single tall hourglass tube with only one narrow
point.  My best guess is that Pipes, in this analogy, would have only
5%-15% of the narrow openings as an equivalent UNIX piping command, meaning
that the data (sand) would flow 85-95% faster in the Pipes "hourglass".


OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
IBM has been looking for an HLL for program products; REXX is that language.


On Mon, Sep 20, 2021 at 12:48 PM Phil Smith III  wrote:

> Hobart Spitz wrote, in part:
>
> >The case *for *Pipes in the z/OS base.:
>
> > 2. Hardware usage would drop for customers.
>
>
>
> From IBM's perspective, that might not be a positive argument. It should
> be-they're hopefully not fooling themselves that they have a lock on
> enterprise computing any more, so anything that makes life more palatable
> for the remaining faithful at low cost to IBM should be A Good Thing-but I
> can easily imagine someone saying, "We estimate this will reduce MIPS
> purchases by x%, that's bad, don't do it".
>
>
>
> Just sayin'.
>
>
>
> ...phsiii
>
>
> --
> 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: 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 

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

[Hobart Spitz]

IMHO, the Business Cases on Pipes in the z/OS Base are as follows.  (Pipes
is already available as part of BatchPipes.)

The case *for *Pipes in the z/OS base.:

   1. Development costs would drop for customers, vendors, and IBM, since
   everyone could use Pipes in their software.
   2. Hardware usage would drop for customers.  In addition to avoiding
   I/O, Pipes uses a record address-and-length descriptor.  A record can
   flow from stage to stage with the only data movement being for changed
   records.  Potential data needed by a stage could have already been in the
   working set and/or cache-loaded by the previous stage.  (A methodology for
   identifying the cost/benefits by JOB and application would allow the best
   to be reworked first.  Thus Pipes would pay for itself in the shortest
   amount of time.)
   3. Product efficiency for vendors (IBM and others) would improve.
   (Arguably it's the other side of the coin in #2.)
   4. Tight integration with REXX, CLIST and JCL.
   5. Portability to and from z/VM.  This breaks down differently for
   different groups:
  - Customers: Cheaper porting to/from z/OS.  (Porting to other IBM
  Series is expensive and time-consuming, AFAIK.)
  - Vendors:  Write once for both platforms.
  - IBM:  Rather than customers moving to non-IBM platforms, when z/OS
  or z/VM don't meet their needs, those customers would have another option
  to stay with IBM.
   6. You can process both RecFM F records and RecFM V records with the
   same stages.
   7. Pipes can be used on both EXEC and DD JCL statements.  This is
   primarily for REXX-a-phobes.  Pipe commands in REXX are amazing; I've used
   the combination on both z/OS and z/VM (and predecessors).  Pipes with
   CLISTs is almost as good, AFAIK.
   8. Increased competitiveness for IBM hardware and software.  This would
   especially apply to UNIX customers who have exceeded the capabilities of
   their platforms.
   9. CMS/TSO Pipes is better than UNIX piping, and REXX is better than C.
   With today's processors, C's performance advantage over REXX is not
   significant, and dwarfed by low developer productivity (your bullet, your
   gun, your foot) of C.  Strategically using Pipes with REXX, can give better
   performance that UNIX piping and C.
   10. Since both C++ and Pipes are internally pointer based, you could get
   similar benefits by using OO techniques exclusively.  How are you going to
   convert a COBOL and JCL application to C++?  Not as easily as going to REXX
   and Pipes.
   11. z/OS is a file-structure-aware operating system.  It does not
   use embedded control characters in text files or impose record boundary
   knowledge in binary files.  Pipes reads and writes byte stream data by
   converting to and from record address-and-length descriptor format.  This
   means that, in most cases, any sequence of stages perform equally well on
   RecFM F, RecFM V, byte stream text data and deblocked UNIX binary files.
   12. Addresses staff shortages due to baby-boomer retirements and CoViD
   impacts.
   13. Reduces batch window requirements.  With less I/O, JOBs finish
   faster.
   14. It's my understanding that there are people inside IBM who are
   behind Pipes going into the z/OS base.  Pipes is part of the z/VM base.
   Can z/OS be that far behind?
   15. Is consistent with policies for combating global warming of
   customers, vendors and the public.  Fewer CPU cycles wasted means less heat
   to be dissipated and less electricity to be produced.  The UNIX stream and
   C string models are obsolete in this light; every character must go through
   the CPU to get to the end of a record or string.   Not so in Pipes or SAM
   access methods.  Rarely do you see a UNIX command with more than a dozen
   filters; Pipes commands go into the 100s or 1000s of stages.  In general,
   the more stages the better the efficiency, since you are doing more work
   with the same amount of I/O.  If one reads the tea leaves, it seems
   inevitable that there will be some kind of restriction on activities that
   cause global warming; whether it's a tax, regulation, cap-and-trade, etc.,
   I can't guess.  The point is that it is likely that many heavy resource
   using applications and processes will have to be converted to Pipes-like
   mechanisms, on all platforms to fight global warming.  The question is, do
   you want to start now when it can be done as part of a well thought-out
   cost-effective plan or do it in a rush later, when the costs and risks have
   ballooned?

The case *a**gainst *Pipes, IMHO:

   1. Short term loss of revenue to due better hardware utilization for the
   same work.  Because of improved competitiveness the dip should be short
   lived if it happens at all.  Not all customers will embrace Pipes at the
   same rate or at the same time.  On the other hand, there is always the
   chance that a few successes turn into a snowball.
   2. From the customer perspective, 

Re: Anyway to save ISRDDN output?

[Hobart Spitz]

To the OP, have you considered the ISRDDN command SAVE?

On running ISRDDN in batch, you can make it work if you can skip
full-screen displays.  These approaches come to mind:
1 - Use CONTROL NONDISPL ... .
2 - ISPSTART has options to execute commands.
3 - ZSTART can be set to execute commands on startup.
4 - Create a panel that sets ZCMD to something like save;end and then
selects ISRDDN.
5 - Copy the ISRDDN panel and tweak it to skip the full-screen display.

Individually, or in combination, these should get you started.

On Thu, 18 Feb 2021, 3:40 pm Paul Gilmartin, <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 18 Feb 2021 20:26:15 +, Jeremy Nicoll wrote:
> >...
> >I can't see how any command that dumps its output into a file, which you
> >then send to auditors is any good.  How do they know that the file hasn't
> >been created by hand, or edited between being produced and sent?
> >
> Grant those auditors access to (e.g.) ISRDDN?
>
> But see:
>
> https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
>
> (It's a real PITA to strip Google's tracking info off a URL returned
> by a search.  I have a scripr that does it.  Sometimes.)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Build and submit proc

[Hobart Spitz]

Ignoring the wrong and/or irrelevant comments, anyone who is having trouble
running REXX, TSO, or ISPF in batch, please write to me directly.  Chances
are, I've been there and done that.  (See below.)

To get you started

   1. Create a JCL PROC to start TSO in batch:  You can do one of these.
  - If you can execute your logon proc in batch, this step is mostly
  done.
  - or, under SDSF look at your TSO session or a timed out one.  Do an
  SE on the JCL; ((10, c all xx '//', etc. and you have JCL that
mimics your
  logon proc.
  -
  - or, start with // EXEC PGM=IJKEFT01.  Include DDs for SYSTSPRT and
  SYSTSIN,
 - use DDLIST with what you want in your batch environment, and
 type SAVE.  That will generate a CLIST with all your allocations.
 - Execute the generated CLIST with PARM= or from SYSTSIN.
  2. Allocate or DD ISPPROF to a UNIT VIO, CYL SPACE 1,1,1.  Model the
   DCB after your own profile dataset.
   3. Use ISPLOG DD SYSOUT=* or ALLOCATE DD(ISPLOG) DATA(*).  IIRC, the DCB
   is RECFm=VA, LRECEL=137.  Check youR ISPLOGn.LIST dataset.
   4. Create a REXX exec to start ISPF in batch.  I always do this so I
   don't have to worry about what needs ISPF or not.  See my previous work on
   the very rare ISPSPROF ENQ and the very common getting the return code to
   the JCL level with ZISPFRC.
   5. Write a REXX EXEC to wrap any TSO command in JCL to invoke the above
   (1 and 4), adding a JOB card and anything else you need.  Since the early
   1990s, I've used the name SPAWN, as it does what SPAWN on other platforms
   does.
   6. Arrange for your "spawn" to take an argument which it adds to the job
   and for that argument to be passed to the EXEC from #5 above.
   7. (Optional) To make your "spawn" really robust, have it add any stack
   contents to the end of the job.  This will let you add any DDs for datasets
   that need deadlock ENQing protection, or anything else.

This should get you started.

Now, anytime you want to execute a TSO command, including REXX EXECs, in
batch use:

   - [TSO] %Spawn %myrexxex myarg..."
   - or from REXX:  "%Spawn %myrexex myargs..." or call Spawn "%myrexex
   myargs..."

It's not exactly trivial to do it right.  It is worth doing.

If you want to have some real fun, try emulating JCL in the foreground.
*-D  I've done it.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Tue, Dec 22, 2020 at 3:33 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2020 15:05:47 -0600, Hobart Spitz wrote:
> >
> >Still not enough?  Write (or get your favorite assembler programmer to
> >write) a CMS SLEEP like program.  There might be one on a CBT tape or on
> >the web.
> >
> Assembler!?  CBT tape!?  What rock have you been under for the few
> decades that bog standard OS/390 Rexx has had:
> address SYSCALL 'sleep' 
>
> >99% of what JCL does for you can be done in REXX.  99% of what you can do
> >with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
> >wrong or is too lazy to do a little extra work that saves a lot of work
> >later.  Work smart, not hard.
> >
> I settled on a synthesis: code allocations, the JCL 1% as JCL DD statements
> and the 99% heavy lifting in IRXJCL Rexx or IKJEFT01 Rexx. I wash my hands
> after writing the JCL.
>
> Mr. Natural sez, Use the right tool for the job.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Build and submit proc

[Hobart Spitz]

On Tue, Dec 22, 2020 at 2:11 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2020 13:14:07 -0600, Hobart Spitz wrote:
>
> >You can do it in batch REXX.
> >
> >Stop being brain-dead and thinking about everything in terms of JCL.
> >
> >I've don't write JCL anymore.
> >
> >JCL causes brain-damage.
> >
> Be nice, or at least stay on-topic and ad-rem, not ad-hominem.
>

This was and iis me being nice, on-topic, etc.  People need to use their
brains.

>
> JCL and the Initiator provide protection against ENQ deadlock
> not available with Rexx.
>

False:  TSO alloc or sysdsn() can protect against most situations.

One simple, more general, solution is to do all critial allocations up
front.  If any fail, free all, wait a bit, and retry.

There are many alternatives,depending on the requirement.  E.g., If a
dataset is not available, skip it and do it later.

Still not enough?  Write (or get your favorite assembler programmer to
write) a CMS SLEEP like program.  There might be one on a CBT tape or on
the web.

99% of what JCL does for you can be done in REXX.  99% of what you can do
with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
wrong or is too lazy to do a little extra work that saves a lot of work
later.  Work smart, not hard.

>
>
> >On Tuesday, December 22, 2020, Jousma, David wrote:
> >
> >> I would build the JCL, and then FTP it with the filetype below.   That
> >> will submit and run the job.
> >>
> Why is this preferable to just writing directly, or via IEBGENER to INTRDR?
>
> >> SITE FILEtype=JES NOJESGETBYDSN
> >> put your.modified.jcl.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Build and submit proc

[Hobart Spitz]

You can do it in batch REXX.

Stop being brain-dead and thinking about everything in terms of JCL.

I've don't write JCL anymore.

JCL causes brain-damage.


On Tuesday, December 22, 2020, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> I would build the JCL, and then FTP it with the filetype below.   That
> will submit and run the job.
>
> SITE FILEtype=JES NOJESGETBYDSN
> put your.modified.jcl.
>
> 
> _
> Dave Jousma
> AVP | Director, Technology Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Fred Kaptein
> Sent: Tuesday, December 22, 2020 12:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Build and submit proc
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> Hello,
> I would like to build a JCL batch job called BACKUPS, that does the
> following:
> 1) STEP01
> Create a JCL proc in MYLIB.PROCLIB(BKUP)
> 2) STEP02
> Execute the proc MYLIB.PROCLIB(BKUP)
>
> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was
> built prior to submitting job BACKUPS.
>
> Is there a way to do these two steps in one job and not two?
>
> Thanks
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.

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

Re: JCL PARM issue

[Hobart Spitz]

Had a similar problem.  I used this solution.

http://billlalonde.tripod.com/back/stup006.htm

On Monday, December 14, 2020, Seymour J Metz  wrote:

> Yes - you only have one level of expansion.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
> Sent: Sunday, December 13, 2020 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL PARM issue
>
> On Sun, 13 Dec 2020 19:46:34 +, Seymour J Metz wrote:
>
> >You have a double substitution. Take the parameter you want to pass,
> double the apostrophes, put apostrophes around it, double the apostrophes
> and put apostrophes around that. The way you coded it, the first exapnsion
> there is a blank outside of the apostrophes, making the rest of the string
> a comment.
> >
> >Maybe it's time for an RFE to include comments in the substitution JCL.
> >
> It's time for an RFE for the equivalent of HLASM's DOUBLE BIF.  No "Maybe".
>
> Does PARMDD handle this better?
>
> >
> >From:  Ze'ev Atlas
> >Sent: Sunday, December 13, 2020 2:31 PM
> >
> >What am I doing wrongI have doubled every single quote within the string,
> that should be:'''abc�*' PCRE2.TESTLIB(GRPIN)''
> >|||�|�+-+
>  |||++|+--+where
> the external quotes are the enclosing quotes.So the actual PARM field
> looked like:
> >// EXEC RUNGREP,TEST='-- Test 15 -',//
> PARM1='abc�*'' PCRE2.TESTLIB(GRPIN)'''
> >++TEST8 EXEC PGM=PCR2GREP, ++  PARM=
>IEFC653I SUBSTITUTION JCL -
> PGM=PCR2GREP,PARM=''abc�*'
> >Why does JCL drop the rest of PARM1?Thank you all
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.

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

Re: Silly question - can one force IDCAMS PRINT to show printable lower case characters?

[Hobart Spitz]

REPRO?

On Saturday, December 12, 2020, Seymour J Metz  wrote:

> CCSID would determine which characters were treated as valid. I would not
> expect IDCAMS to second guess the user's InfoPrint parameters.
>
> Ideally there should be a common print validation service and every
> utility would have a parameter to pass it.
>
> As long as the utilities attempt to redact "unprintable" data, they should
> allow the user to control that redaction, regardless of how many other
> places have a CCSID option. Especially a CCSID parameter documented as
> being applicable only to tape.
>
> How is DASD an excuse for translating characters that the user considers
> valid to periods? I don't care if it's legacy DASD, SYSOUT or Unix path,
> the user should be able to control the translation.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
> Sent: Saturday, December 12, 2020 7:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Silly question - can one force IDCAMS PRINT to show printable
> lower case characters?
>
> On Sat, 12 Dec 2020 23:40:52 +, Seymour J Metz wrote:
>
> >I might believe lost in the world of 3211; the 3211 is older than IDCAMS.
> Shirley it's time to add a CCSID operand.
> >
> What would CCSID do?  What implementation do you envision?
> Would it interface to InfoPrint?  Shouldn't every utility have one?
> But that's redundant; it should be an option on DD SYSOUT.
> DD, EXEC, and JOB already have a CCSID option.  Is that enough?
>
> And if SYSPRINT is DASD, it should just pass the data unfiltered.
>
> BitSavers reinforces my conjecture.  Something you don't want in a
> production job:
> http://secure-web.cisco.com/1WhhAX4GjxhomdW3zmNfgT472Yr6nQ
> hRZO040EgqFcFvPBMsDPxogfvqMO12NQs36E2Lf8gEmkDkccMSTqwEn22FDx
> fabOAdb9sSzzpmB-xLwJnTd8s0I4b9wVTIf0YIGlbUnRiA
> zzGGuj70uPltjgBdpcAQD3hM1RWi8kVLFAnzpfZI1-qtzSoC0tniJheFaqIvC82btQ5mIONu
> QYT_xpuDWMvGGdUjRSGL9FImMDx_75jgCFL2ZMBBktTpOE9u1wCgOPfs_
> 9yaGHJ-C-WuKzYLleg8tqOQOg-XcMKs15NG3euVyj0GQw2OiD2ueoIZW
> J7M0XyKZpOPrBTvXbLGr9WXF93UHmZ3y5NjnJZpxcjkFG8_3iC6cs8Jn3Ud4f-
> CCsiRjoKzqaHZ7tXHzsMIikG1gcxJ0BUwzivOPmilFUZ7RuB7rHgBZdogbSO
> d9bt9X/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%
> 2F1403%2FGA24-3073-8_1403_printer.pdf
>
> Data Check (Sense Bit 4)
> Data check indicates that a code in a data record sent to the printer does
> not match a code in the Universal Character
> Set (UCS) feature storage. Printing does not occur in the
> print position to which the unmatching code applies. The entire line
> (except for the data check position) OIr only a portion of the line may be
> printed. Therefore, the last
> printed line may contain erroneous data and/or an incomplete record. Data
> check usually indicates that the UCS storage
> was improperly loaded or that a data record code (other than blank or
> null) does not compare to any code in the UCS storage.
> Provide an operator message and exit from this error- recovery procedure.
> The operator should then:
> 1. Accept the record and indicate that the application
> program is to proceed without further retry of the
> command, or
> 2. Restart the application program from a logical
> point.
> If the error persists, a call should be made to a service
> representative.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.

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

Re: Improve OMVS cp performance?

[Hobart Spitz]

CMS/TSO Pipes!!!

On Sat, 14 Nov 2020, 8:26 pm Mike Schwab,  wrote:

> You have to remember that S/360 was the first 8 bit computer.  Prior
> computers used 4 bits for a digit and 6 bits for a character.  They
> designed EBCDIC to be easily converted for use with existing 7 track
> tape drives, printers, card and tape readers and punches.  There was a
> proposed ASCII code that was put on documentation but dropped for the
> 370 virtual memory bit in the PSW.
>
> On Sat, Nov 14, 2020 at 6:39 PM Seymour J Metz  wrote:
> >
> > I doubt that IBM custumers would have been happy with an 8-bit code page
> with only 128 valid code points. International considerations would still
> have forced IBM to device incompatible code pages for different countries.
> >
> > Obviously 8859 is another Tower of Babel; why do you think I described
> it as "a dollar short"?
> >
> > No,, IBM could not have implemented full Unicode, or even the full MLP,
> back in the 1960s. But it could certainly have implemented a basic subset
> for all customers and selected additional pages for international
> customers. Had Unicode and UTF-8 been around at the time, I'm certain that
> IBM would have gone that route.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> > Sent: Saturday, November 14, 2020 6:22 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Improve OMVS cp performance?
> >
> > On Sat, 14 Nov 2020 23:00:00 +, Seymour J Metz wrote:
> >
> > >Because there was no standard 8-bit code at the time. IBM did push for
> an 8-bit ASCII,
> > >
> > That's not an obstacle.  DEC PDP-8 stored ASCII characters one per
> > 12-bit word.  IBM could have simply declared the top bit "reserved"
> > as they are so often wont to do.
> >
> > >but it never happened except for a mapping between octets and punch
> combinations on cards. Had Unicode been around at the time they would
> probably have jumped at it.
> > >
> > >ISO 8859 was a day late and a dollar short.
> > >
> > ISO-8859-* is afflicted with the same babel as EBCDIC code pages
> > because of the "*" you elided.
> >
> > UTF-8 is the norm nowadays because of a peculiar upward compatibility
> > with ASCII.  But the mebibytes and megahertz to support it came a day
> late.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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: SORT question: How to both remove records from a file AND write removed records to a 2nd output?

[Hobart Spitz]

Incorrect.

You use a pipe-fitting on the JCL DD, something like "bpread | sysout q | >
dd=out2 | > dd=out3" for as many outputs as you like.

I'm iffy on the exact syntax for specifying the stream separator, but the
fanout stage can do the same:
   "(end ?) bpread | fo: fanout | sysout q ? fo: | dd=out2 ? fo: | dd=out3"

If you wanted to remove ASA page feeds from, say the last output.
   "(end ?) bpread | fo: fanout | sysout q ? fo: | > dd=out2 ? fo: |
change 1 /1/ / | > dd=out3"

In other words, you have all of CMS/TSO Pipelines available to your, except
full-screen I/O.

Use PipeThink.  You'll never go back.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Wed, Sep 23, 2020 at 1:23 PM Martin Packer 
wrote:

> No, that would have to be another job, also specifying eg SUBSYS=PIPE. And
> scheduled to run alongside the sort.
>
> Cheers, Martin
>
> Martin Packer
>
> Systems Investigator & Performance Troubleshooter, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://anchor.fm/marna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   23/09/2020 17:18
> Subject:[EXTERNAL] Re: SORT question: How to both remove records
> from a file AND write removed records to a 2nd output?
> Sent by:IBM Mainframe Discussion List 
>
>
>
> On Wed, 23 Sep 2020 16:01:08 +0100, Martin Packer wrote:
>
> >Right. That example used BatchPipes/MVS pipes - but it's not essential to
> >the use of OUTFIL SPLIT. The reason it used pipes was to enable cloning
> to
> >balance a pipe.
> >
> OK.  I looked at your example (z/OS 2.1; not too misty).  But what
> mystifies
> me is where to code the Pipeline specification.  Suppose I want to, for
> example to direct OUT1 (or an added OUT3) to a stage such as
> DIGEST MD5.  Could I just code:
>...,SUBSYS='PIPE,DIGEST MD5',...
> ??? if not, how?  And can I further direct that digest to SYSOUT?
>
> >-Original Message-
> >From: IBM Martin Packer
> >Sent: Wednesday, September 23, 2020 4:31 AM
> >...
> >Something also from the mists of time, by no coincidence, is this:
> >
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/ice2ca_Example_11._Sort_with_Pipes_and_OUTFIL_SPLIT.htm
>
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> 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 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: Batchpipes (was: SORT question: ...)

[Hobart Spitz]

They find each other via the name of the pipe.


OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Wed, Sep 23, 2020 at 2:19 PM Martin Packer 
wrote:

> The pipe name is a data set name.
>
> The scheduling problem is real: How to ensure two jobs run at the same
> time. I would propose common predecessors and common successors. Some of
> these might be dummy operations.
>
> Actually, sorts are nice cases as they often read data that has been
> freshly created or create data that is just about to be read sequentially.
>
> Cheers, Martin
>
> Martin Packer
>
> Systems Investigator & Performance Troubleshooter, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://anchor.fm/marna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   23/09/2020 20:04
> Subject:[EXTERNAL] Batchpipes (was: SORT question: ...)
> Sent by:IBM Mainframe Discussion List 
>
>
>
> On Wed, 23 Sep 2020 19:23:33 +0100, Martin Packer wrote:
>
> >No, that would have to be another job, also specifying eg SUBSYS=PIPE.
> And
> >scheduled to run alongside the sort.
> >
> Eek!  How do they find each other?  And perhaps more important, what
> if several programmers unknown to each other concurrently submit
> job using SUBSYS=PIPE; how do they avoid mistaken identity?
> Must a scheduler sort it out?
>
> I've had corresponding problems with sockets and dynamically assigned
> ports: someone needs to note the port number and communicate it to
> the other.
>
> >>-Original Message-
> >>From: IBM Martin Packer
> >>Sent: Wednesday, September 23, 2020 4:31 AM
> >>...
> >>Something also from the mists of time, by no coincidence, is this:
> >>
> >
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/ice2ca_Example_11._Sort_with_Pipes_and_OUTFIL_SPLIT.htm
>
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> 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 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 Pipes (and BatchPipes)

[Hobart Spitz]

If there are any z/VMers subscribed, it would be interesting to also
compare the PIPE Q output under CMS.

Thanks.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Wed, Apr 22, 2020 at 10:57 AM Lionel B Dyck  wrote:

> I don't have access to TSO Pipes other than what is included with
> BatchPipes
> but it seems that it is a tad dated - it is actually old enough to drink:
>
>
>
> BPW00086I BatchPipes/MVS BatchPipeWorks, 5655-065/SCPSP 1.0109
> (Version.Release/Mod) - Generated 12 Oct 1996 at 13:59:00
>
>
>
> If someone has the non-BP version of TSO Pipes it would be interesting to
> see the results of the PIPES Q command showing the date.
>
>
>
> For those of you who would like to encourage IBM to release TSO Pipes as
> part of the z/OS base please go to this URL and vote
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
> <
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699
> > _ID=47699  (note the current vote is 188 which places it at the  top
> in
> the z/OS area).
>
>
>
> Having TSO Pipes as a native part of the z/OS distribution would help
> everyone as software developers would then be free to use it when
> developing
> applications, products, and tools knowing that every site has it available.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
> --
> 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: SHARE requirement: Address Temporary Dataset and USS Piping Issues

[Hobart Spitz]

port, and I’m pretty
> sure that it will be rejected. They have a limited staff these days (their
> unfortunate decision in my mind) and almost nobody left in the REXX/TSO
> areas.
>
Even an old version of the TSO PIPE command would be a fantastic
improvement.  It is my understanding, from various sources, that CMS
Pipelines has (almost) always been ready to run on TSO, with only trivial
changes.  John Hartmann's Author's Edition on Pipelines specifically
documents the few builtin stages that are not available on TSO such as
READER and PUNCH.  It also describes the stages that are only available
under TSO.

>
>
> I also was not able to help you with even your first draft because this is
> way over my head. I know that I’ve heard people say that pipes are
> wonderful and I also know that several people tried to get IBM to stop
> charging for BatchPipes, so I was supporting of you trying to get a SHARE
> requirement. But again, I could not begin to help you make it more concise
> because I don’t fundamentally understand pipes and haven’t programmed in 30
> years.
>
I'd be happy if IBM kept charging for BatchPipes.  It's just the TSO PIPE
command that needs to be free.

>
>
> I think that SHARE should follow its normal policy and open it for voting
> to see what current feelings are at the time. Other hot spots have come up.
> If IBM doesn’t accept it, then I think you should post it as a regular RFE
> and post something on IBM-Main that asks people to go vote on it like
> Lionel does.
>
Good idea.  However, Mike seems like a nice guy caught between a rock and a
hard place.  I'm not sure he or SHARE should be subjected to any resulting
blow-back.

>
>
> I would NOT try to sell it using assertions that COVID-19 victims would
> sue IBM. That will not will you any supporters. I recently tried to talk
> IBM management in extending the EOS dates for COBOL V5 and z/OS 2.2 due to
> the hardships of COVID-19 and hit a brick wall. And that wouldn’t have cost
> them anything! Frank used to tell me that it could take a year to get a
> decision changed in IBM, and I feel that he’s right. It’s quite frustrating
> for us too.
>
Yes, my statement was a mistake.  The pandemic, economic impacts,
isolation, and extra protection measures may have resulted in a temporary
lapse of judgement.  Then there is IBM's lame excuse for not doing the
right thing.  Considering that it's been almost 3 decades since i first
submitted this kind of request, I guess it's at least 25 years overdue.
Given that, I'm adding IBM-MAIN to the cc: list.

>
>
> The only other thing I would try is to make a much smaller requirement
> that simply asks for BatchPipeWorks to be made available separately at
> no-charge. Knowing IBM, that will be rejected as well.
>
Gee.  I thought that what I was doing.  You do make my point about the
confusing names.

>
>
> I’m sorry that I haven’t been able to help you with this. I hope you’re
> staying safe and healthy.
>
No apologies necessary.  If you know anyone who can help, please get us in
contact or share this email.

>
>
> Best regards,
>
> Cheryl
>
>
>
> =======
>
> Cheryl Watson
>
> Watson & Walker, Inc.
>
> 1661 Ringling Blvd, PMB 49886
>
> Sarasota, FL 34230
>
> Text/cell: 941-266-6609
>
> www.watsonwalker.com
>
> ===
>
>
>
>
>
> *From:* Hobart Spitz 
> *Sent:* Sunday, April 12, 2020 8:28 AM
> *To:* Rob van der Heij ; Cheryl Watson <
> che...@watsonwalker.com>
> *Subject:* Fwd: SHARE requirement Address Temporary Dataset and USS
> Piping Issues
>
>
>
>
> OREXXMan
>
> JCL is the buggy whip of 21st century computing.  Stabilize it.
>
> Put Pipelines in the z/OS base.  Would you rather process data one
> character at a time (Unix/C style), or one record at a time?
>
> IBM has been looking for an HLL for program products; REXX is that
> language.
>
>
>
> -- Forwarded message -
> From: *Hobart Spitz* 
> Date: Sun, Apr 12, 2020 at 7:27 AM
> Subject: Re: SHARE requirement Address Temporary Dataset and USS Piping
> Issues
> To: Mike Shorkend 
>
>
>
> Mike;
>
>
>
> I'll try to make this brief.  I will make it polite, since I don't know
> you.  The IBM guy is giving you bad information either out of ignorance, an
> illegitimate agenda, or both.  He should be ashamed and embarrassed for
> even suggesting such things.  I apologize to you on his behalf for his
> misleading you.  I was level III support for CMS Pipes, and have used both
> TSO Pipes, and BatchPipes  I know what I am talking about.
>
>- The premises are false.  BatchPipes and BatchPipesWorks are two 99%
>unrelated products that should never have bee

Re: Utility to parse fullword delimited flat file

[Hobart Spitz]

Pipes.

On Thu, 28 Mar 2019, 2:11 pm Kirk Wolf,  wrote:

> You could do it with Co:Z Batch + Dataset Pipes without creating a
> temporary file:
>
> //SHELL EXEC PGM=COZBATCH
> //IN  DD DISP=SHR,DSN=...
> //OUT DD DISP=(NEW,CATLG),DSN=...,
> //   DCB=(RECFM=VB,LRECL=27994),SPACE=
> //STDIN DD *
>   fromdsn -b //DD:IN  |
>  todsn -b -l l4  //DD:OUT
> //
>
> Now, if you meant "flat file" as a Unix file, then just:
>
> //STDIN DD *
> todsn -b -l l4 //DD:OUT < /path/to/my.flat.file
> //
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> --
> 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: part of TSO commands are no RESPONSE from PGM=IKJEFT01

[Hobart Spitz]

I think you need to give us some more information.  I'm not familiar with
XQUERY and it's quirks.  What kind of response are you expecting?  Is the
output dataset empty?

That said, it's been so long since I've run anything in batch without REXX
I don't recall if vanilla TSO reports non-zero return codes.

You may want to find/tweak a mainframe version of REXXTRY, and add
PARM=REXXTRY to your EXEC.  Be sure to have a SYSEXEC DD for the library
where you put REXXTRY.  In addition to return code reporting REXXTRY let's
you use most REXX features.  E.g., you can set a variable to the DSN and/or
VOL if the change between runs. Put your commands in quotation marks, and
follow REXX syntax.

It looks like you might benefit from writing a batch REXX EXEC to do that
work.

See these documents for more information.

  e741ba69-356d-4ffc-84dd-91ae1e883fb1.pdf


  Modernizing z/OS Batch Processing







On Sun, 24 Mar 2019, 8:43 pm Jason Cai,  wrote:

>
> Hi all
>
>   We issue a lot of TSO  commands ( XQUERY NP2XRE DATASET('XXX.TST')
> DISP(MOD) VOLUME(BJ2817) DETAIL )
>
> by PGM=IKJEFT01 .The sample is blow:
>
> //S1EXEC PGM=IKJEFT01,REGION=0M
> //SYSTSPRT DD SYSOUT=*
> //SYSPRINT DD SYSOUT=*
> //SYSTSIN  DD *
>  XQUERY NP2XRE DATASET('XXX.TST') DISP(MOD) VOLUME(BJ2817) DETAIL
>  XQUERY NP2XRE DATASET('xxx.TST') DISP(MOD) VOLUME(BJ2897) DETAIL
>  XQUERY NP2XRF DATASET('xxx.TST') DISP(MOD) VOLUME(BJ2917) DETAIL
>
>
> We found there are just  part of this commands responsed.
>
>
>
> Any thoughts/comments/suggestions would be greatly appreciated
>
>
>
>
>
> Best Regards,
> Jason Cai
>
>
> --
> 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: Question ABout ISPF Panels

[Hobart Spitz]

Peter cover it well.
A DISPLAYd panel cannot invoke a CLIST.
A SELECTd panel can invoke any command, CLIST, REXX EXEC, or PGM, by
setting 

On Sun, 19 Aug 2018, 12:36 am Jesse 1 Robinson, 
wrote:

> I have an app that imbeds REXX code in a panel. The REXX code happens to
> be in the )Init section, but I think it could be )Proc. It has a marked
> beginning and end:
>
> *REXX(*,shopcsij,shoptgtj,zedsmsg,zedlmsg)
>
> TRACE N
>
> IF LEFT(shopcsij,1) = "4" THEN DO
>   shopcsij = shopcsi1
>   shoptgtj = shopc1tg
>   RETURN
> END
> ...
> RETURN
>
> *ENDREXX
>
> I wrote this partly to see if I could. It works, but I don't think I'd do
> it again.
>
> .
> .
> 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 CM Poncelet
> Sent: Saturday, August 18, 2018 8:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Question ABout ISPF Panels
>
> The Clist or program should be invoked from the )PROC section in the
> panel, as the value of  E.g.
>
> )BODY WIDTH() EXPAND(//)
> %---/-/-
> !OPTION %===>¯ZCMD )PROC
>= TRANS( 
> B,'CMD(%ZBROWSE )'  /* Clist */
> T,'PGM(ISRPTC)'/* Program */
> U,'PANEL(ISRUTIL)' /* Panel */
> *,'' )
> )END
>
> Your 'PAULD01.SPEX.CLIST' should be in your SYSPROC concatenation, unless
> you want to invoke a SYSPROC Clist that issues its own EX
> 'PAULD01.SPEX.CLIST(XGETSYS)'.
>
> To invoke XGETSYS from a panel, code:
>
> )PROC
> IF ( = ABX3 )
>  = 'CMD(%XGETSYS)'
>
> else see the above " = TRANS(  " to include multiple panel
> options.
>
> Chris Poncelet
>
>
>
> On 18/08/2018 14:18, esst...@juno.com wrote:
> > Hi,.I am trying to find examples of invoking a CLIST and a Program
> > from the )PROC Section of a ISPF PANEL .
> > I consistently get a syntax error.
> > .
> > For example:
> > )PROC
> > IF (   = ABX3 )
> >EX 'PAULD01.SPEX.CLIST(XGETSYS)'
> > .
> > My first question would be, is it legitimate to invoke either a CLIST
> > or Assembler Program from the )PROC section of a PANEL ?
> > .
> > And secondly could some one post an example of each ?
> > .
> > .
> > Paul
>
>
> --
> 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: Need help with ISPF Dialogue Manager and VGET

[Hobart Spitz]

Keep in mind that if you do VDEFINE(s), you MUST do VDELETE(s) for the same
variables, before you FREEMAIN (e.g.) and/or exit.  Otherwise, enjoy
tracking down mysterious S0C4s, etc.  ISPF will think that the storage is
still allocated to the function pool variable(s) and may read from or write
to it/them.

To clarify what was already said, you don't need VDEFINE if your assembler
program is not interacting with the data.  For example, if you are
displaying a panel that, implicitly or explicitly, does all needed VGETs,
VPUTs and operations for some variables, no VDEFINEs are needed for those
variables.

If you are only inspecting or setting a particular variable once, VCOPY or
VREPLACE will do just as well, without the need for VDELETE.

Less clear cut is when a program is invoked by SELECT.  It would seems that
all function pool variables are deleted, along with their reference
addresses, lengths, etc.  I'm not sure; YMMV.

That said, unless you are writing a program product (and maybe even then),
you are better off using ISPEXEC from assembler.  It is easier to write and
maintain, and also offers variable substitution:

CALL ISPEXEC,(BUFLEN25,BUFFER25),VL
...

Buffer25 dc c'display panel(abc)'

Buflen25 dc a(l'Buffer)


In fact, this could all be nicely packaged into an assembler MACRO.

Compiled REXX, CLIST (see note), and the Pipes/ISPF stages will give you
better performance than interpreted REXX, without the productivity
downsides of assembler.  (AFAIK, ISPF has it's own internal copy of the
CLIST interpreter that loads and/or runs faster than the usual CLIST
interpreter; call a CLIST only via SELECT.)  ISPF dialogs with only ISPLINK
require lots of extra coding, more detailed knowledge of the business
requirements, perfect comments for future victims, and full understanding
of dialog services.

Finally, the TSO variable lookup routine IKJCV441 can only get or set once
variable at a time.  With TBxxx services this is a burden; a requirement to
address this was never approved.

I hope this helps.


On Thu, 2 Aug 2018, 1:04 pm Seymour J Metz,  wrote:

> When last I had access to ISPF I used them heavily. Not as good as a
> full-fledged syntax directed editor, but still very helpful.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Edward Finnell <000248cce9f3-dmarc-requ...@listserv.ua.edu>
> Sent: Wednesday, August 1, 2018 4:38 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Need help with ISPF Dialogue Manager and VGET
>
> Anybody use MODEL commands for anything anymore?
>
>
> In a message dated 8/1/2018 1:55:00 PM Central Standard Time,
> lionel.d...@va.gov writes:
>
>
> o make it easy check out
>
> http://secure-web.cisco.com/1aCvaZTPAJO1cr0bBILltD9dwI1WmoCvWWhozu3I5u48ZM15ylQIGanv_Trrk6O5VuRGJJswyxcYz9vRomNgklq_m_j0s771svDk7WUeYqwl1uuj1d3L0IpAP99Mwac4LtJjboIVoqgiN2VoxeeOXVWrkNSAJ8j_heA3jX0DN-HWTAl4EZoG079JyQfdUKxE89gRHnPAOZE4GK-dkswWoeIfb2zLBHL_rgCSTYNMsaiXrYtx1b0DsQl9-oQG5qM4JDe1lTPm3VIpwY9E3n-gzDQ2BhMnoQHrZcbLoraJl3fMpTz1UdkrD4eX0UU75u403yRandjrU5Bvb-MH0MgDt8Gg3UhqUI2OG7XVjTxlsZZxZLk7h6MgGbUS0MsShNul6/http%3A%2F%2Fwww.cbttape.org
> and FILE 803 - it is a collection of ISPF macros that I ran across in the
> last millennium that make it very easy to code ISPF dialogs in assembler.
>
> --
> 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: Symbol syntax (was: Using system sysmbols in a procedure)

[Hobart Spitz]

Substring?

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Mon, Jul 16, 2018 at 2:41 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> (Can't anyone spell "Symbols" correctly in a subject!?)
>
> On Mon, 16 Jul 2018 13:08:04 +, Allan Staller wrote:
>
> >SYSSYM=ALLOW in JES2 jobclass definition.
> >
> These two threads (with different misspellings of "Symbols") piqued my
> curiosity.  I read in the JCL Ref.:
>
> Using symbols before fixed code
>   A period is required after a symbol when the code that follows
>   the symbol is fixed and begins with:
> ...
>   o A left parenthesis, when it is at the start of the designation
> of a relative generation of a generation data group (GDG) that
> does not contain a plus or minus sign.
> ...
>   For example, if  resolves to SY1, type DSNAME=PROD.(0)
>   if the desired data set name is PROD.SY1(0). If a plus or minus sign
>   is included, the period is optional: DSNAME=PROD.(+0) and
>   DSNAME=PROD.(+0) are both acceptable.
>
> So, I can code:
> PROD.SY1(0)
> PROD.(+0)
> PROD.(0)
>
> But not:
> PROD.(0)
>
> Why not?  And what does the prohibited form mean?
>
> I hate JCL!
>
> --gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Weirdest. Acquisition. Ever. Broadcom buys CA Technologies . The Register

[Hobart Spitz]

I think there are positive ways to view this.

   - According to one report Broadcom has a history of buying troubled
   companies and turning them around.
   - If prices go up, some sites will be forced to drop products that are
   not used much, or are otherwise not earning their keep, in favor of
   alternatives.  This would, IMHO, strengthen the quality of competitors'
   offerings, since there is more potential cash flow at higher prices.


OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Fri, Jul 13, 2018 at 11:32 AM, Mike Shaw 
wrote:

> On 7/13/2018 8:45 AM, Phil Smith III wrote:
> 
>
>>
>> Goal was acquired by Legent, which itself was formed when Morino
>> Associates
>> and Duquesne Systems merged. They didn't use my suggested name for that
>> merger: Dorito.
>>
>> I was at Morino Associates when the merger with Duquesne and subsequent
> renaming to 'Legent' occurred. 'Legent' is just an anagram of 'Gentle'; the
> rumor was that the company paid $100k to some firm to come up with that
> name and the new 'skid mark' Legent logo...
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
>
> --
> 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: [External] Re: Broadcom to buy CA?

[Hobart Spitz]

It is typical in buyouts for the buyer's stock to go down and the company
being bought to go up, with exceptions.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Thu, Jul 12, 2018 at 1:12 PM, Edward Finnell <
000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> Don't know if this is gonna fly after all. Broadcom's stock is down 19 and
> CA's is up 16. Bloomberg reports large shareholders are citing 'lack of
> focus'.
>
>
> In a message dated 7/12/2018 8:44:25 AM Central Standard Time,
> rpomm...@sfgmembers.com writes:
>
>
> I didn't know Broadcom bought Brocade - turns out it happened back in 2016
>
> --
> 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: Deleting all members of a PDS

[Hobart Spitz]

pipe listpds 'your.pds' | cons | chop 3 | insert /delete 'your.pds' / | tso
| cons

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 11, 2018 at 3:13 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 11 Jul 2018 14:59:15 -0400, Hobart Spitz wrote:
>
> >You're in TSO.  Add this line, or equivalent, before the DELETE.
> >
> >listd 'your.pds' mem
> >
> What about the TOCTTOU hazard?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: REXX as JCL replacement

[Hobart Spitz]

Sorry John.  I know how businesses work.  My comment was rude, sarcastic,
and uncalled for.  I should not have sent it.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 11, 2018 at 2:48 PM, John McKown 
wrote:

> On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz  wrote:
>
> > John;  So the production schedules set policy in your shop.  Do they pay
> > the bills too?
> >
>
> ​Well, they run the jobs which keep the company running which pays my
> salary. But if you want who, at least in the past, sets policy -- it was
> the end user departments. They demand, we supply. The most precious
> employees are the sales agents. No sales, no money. No money, no company.
> It runs down hill from there. I.e. the departments support the sales force.
> We support the departments. So we are at the bottom of the support list. ​
>
> --
> There is no such thing as the Cloud. It is just somebody else’s computer.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Deleting all members of a PDS

[Hobart Spitz]

You're in TSO.  Add this line, or equivalent, before the DELETE.

listd 'your.pds' mem

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 11, 2018 at 2:56 PM, Scott Barry  wrote:

> On Wed, 11 Jul 2018 10:43:42 -0700, Sri h Kolusu 
> wrote:
>
> >>>but I'm curious if there's some additional keyword that will ignore the
> >SHR enqueues. I have not found anything.
> >
> >Skip,
> >
> >You need to use FILE keyword on IDCAMS delete like shown below
> >
> >//DELALL   EXEC PGM=IDCAMS
> >//SYSPRINT DD SYSOUT=*
> >//PDS  DD DISP=SHR,DSN=Your.PDS
> >//SYSINDD *
> >  DELETE 'Your.PDS(*)' FILE(PDS)
> >/*
> >
> >Thanks,
> >Kolusu
> >
> >
>
> With the use of "splat" and "delete all members" request, sadly the
> IDC0553I message doesn't provide a list of the members deleted, instead
> only mention "ALL MEMBERS IN DATA SET  DELETED".
>
> Now no Auditor-type would go for that -- heck, I even would appreciate
> knowing what I just deleted !!
>
> Still like the enhanced functionality permitting various DSN-mask
> specifications, similar to TSO/ISPF DSLIST (option 3.4).
>
> Scott Barry
> SBBWorks, Inc.
>
> --
> 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: REXX as JCL replacement

[Hobart Spitz]

John;  So the production schedules set policy in your shop.  Do they pay
the bills too?

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 11, 2018 at 2:09 PM, Seymour J Metz  wrote:

> You keep missing the point that REXX does not currently provide the
> serialization that is available through JCL. Rewriting the job as a REXX
> script that does not do the necessary serialization is a CLM. That's why I
> suggested a parallel allocation facility usable from REXX.
>
> I don't like JCL, but I don't see any way forward other than incremental
> improvements.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Hobart Spitz 
> Sent: Wednesday, July 11, 2018 1:30 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: REXX as JCL replacement
>
> Skip;
>
> What you say is true.  Massive replacement would not be justified.  No one
> is advocating such an effort.
>
> What needs to happen is for people to stop writing new JCL (or copying old
> JCL, especially the bad stuff) and work as if it were the 21st century.
>
> In addition to not writing new JCL, there are some prime replacement
> candidates to consider now:
>
>- PROCs are executed frequently.  The improvements, whether functional
>or performance, would be multiplied across all JOBs that EXECute those
>PROCs.
>-
>- PROCs that only use utilities and/or batch TSO, combining all into one
>step.
>- Replacing frequently executed IEFBR14s that sometimes create a dataset
>just to delete it, or that delete perfectly good dataset.  Are all those
>ENQs, RESERVEs, catalog searches and updates, and VTOC searches and
> updates
>really worth it just because DISP=MOD can't change DCB info?
>- JOBs with complex parameter or restart requirements.
>- JOBs that run frequently.
>- JOBs that need special serialization.  Invoke the program(s) in a REXX
>loop.  Serialization problems gone.
>- Applications that do updates primarily in DB2 and/or PDSEs.
>- Applications that need more generalized automation.  Drop the
>expensive third-party software.  You play by your rules, not someone
> else's.
>- Any process that has complex or hard to maintain JCL.
>
> There are more.
>
> Once you understand the benefits, to vendors and customers, the choice is
> clear.
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.  Stabilize it.
> Put Pipelines in the z/OS base.  Would you rather process data one
> character at a time (Unix/C style), or one record at a time?
> IBM has been looking for an HLL for program products; REXX is that
> language.
>
> On Wed, Jul 11, 2018 at 1:00 PM, Jesse 1 Robinson  >
> wrote:
>
> > This thread is entertaining but largely cherry-pie-in-the-sky. While it
> > might be a nice exercise for sysprogs and architects, what's missing so
> far
> > is a compelling business case to justify the pain and agony of actually
> > replacing JCL in a real world environment. For a mature shop with
> thousands
> > of jobs to manage--most of which work very well most of the time--it
> would
> > be a very hard sell to justify resources to build a replacement that
> would
> > mostly work better most of the time.
> >
> > I'm reminded of the old saw about teaching a dog to walk on its hind
> legs.
> > What's compelling is not that the dog does it well but merely that she
> can
> > walk that way at all. Worth maybe admission to a vaudeville show but not
> a
> > reason to turn your life upside down.
> > .
> > .
> > 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 Hobart Spitz
> > Sent: Wednesday, July 11, 2018 9:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: REXX as JCL replacement
> >
> > Gil wrote:
> > >SORT is quasi-batch:
> > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can
> run
> > SORT(s) to completion completely independently of the main pipe, to name
> > just two possibilities.  The terminology in 

Re: REXX as JCL replacement

[Hobart Spitz]

Gil wrote:
>SORT is quasi-batch:
A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run
SORT(s) to completion completely independently of the main pipe, to name
just two possibilities.  The terminology in the PIPElines documentation is
"delaying records".  Most built-in filters don't delay records, others
might delay some records some of the time, and others, like SORT delay, of
necessity, all records.  Any filter that has to hold on to a record and
"think about it" before producing the corresponding result is said to
"delay the record".

Any sequence of filters, each of which don't delay the record, when
combined in a single stream, will not delay the record.  So much of the
time, you don't have or don't care about record delay.

Delaying records doesn't into play until you get into non-trivial
multiple-stream PIPElines, where you have split a data stream into two and
then later combine them.  In order for the right records to arrive at the
desired time at the joining point, you may need to take record delay into
account.  This is something that is impossible in UNIX (at this time),
because UNIX piping data flow is not deterministic.

Beginning pipers don't usually run into the issue.  For one, there is so
much you can do with REXX and single stream PIPElines.  For another,
multi-stream PIPElines require a small additional level of knowledge
concerning functionality and syntax.  Melinda Varian has written some
excellent papers and talks on PIPElines.  She was a long time advocate and
champion of PIPElines, especially under z/VM and CMS.   You can find her
papers and more at

http://vm.marist.edu/~pipeline/

The author's edition, the primary source of PIPElines information, can be
found at.

http://www-01.ibm.com/support/docview.wss?uid=pub1sl26001805

You need only read the first few chapters before you will start drooling to
have the product.  No joke.  You'll begin to realize how much your
productivity has been hampered by not having better tools at your disposal.

I capitalize PIPElines this way because, apparently, there is a UNIX pipe
command which has no connection or similarity to the TSO/CMS product.


OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 11, 2018 at 11:54 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote:
>
> >Using pipelines could require a lot of programming changes.
> >Historically, programs tend to be designed to process batches, not
> records.
> >
> >Most shops will not have the bodies to do the changes needed.
> >
> Many programs process data sequentially and are well suited to using pipes,
> which merely bypass temporary files and require no other changes.
>
> In ancient, main-storage-constrained environments pipes might actually
> degrade performance: having multiple programs co-resident caused
> paging I/O that overwhelmed any benefit of less temp file I/O.
>
> SORT is (too) often given as an example of a pipe stage.  It can be
> inappropriate because SORT is quasi-batch:  SORT can not write the
> first record to SORTOUT until it reads the last record from SORTIN.
>
> >I like the idea of REXX as a JCL replacement. It can provide a lot
> >better logic. I don't know that it will make many inroads due to lack of
> >man-power, but it can be a method to the future.
> >
> >One of our staff looked seriously at JOL and rejected it.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: REXX as JCL replacement

[Hobart Spitz]

It may be a long, slow process, generally and/or at some sites, but if
enough people do it,  JCL will become the exception.  IBM and site
management will get it, and additional needed tools/solutions or something
even better will be made available.   Eventually.

Try it.  Use what works.  Refine what doesn't.



OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 11, 2018 at 11:03 AM, Tony Thigpen  wrote:

> Using pipelines could require a lot of programming changes. Historically,
> programs tend to be designed to process batches, not records.
>
> Most shops will not have the bodies to do the changes needed.
>
> I like the idea of REXX as a JCL replacement. It can provide a lot better
> logic. I don't know that it will make many inroads due to lack of
> man-power, but it can be a method to the future.
>
> One of our staff looked seriously at JOL and rejected it.
>
> Tony Thigpen
>
> Hobart Spitz wrote on 07/11/2018 08:37 AM:
>
>> The JOL effort is commendable, but replacing JCL is about much more than a
>> nicer syntax or easy movement between foreground and background.
>>
>> At the risk of repetition, other reasons are (1) to eliminate the
>> separation between scripting code and application code and (2) to
>> interface
>> with other software/data (files, DB2, ISPF, etc.).
>>
>> Resistance to replacing JCL comes from the fact that "everybody knows JCL"
>> (which they don't really).  Everybody (in the target audience) knows REXX,
>> if not directly, then because REXX has many well-know features of other
>> languages.  JCL resembles only mainframe assembler.
>>
>> Add in PIPElines and you get a productivity and performance improvements
>> unlike any other option available.  Charles's example in REXX and
>> PIPElines
>> might look like this.
>>
>> 1. "pipe (end ?) ? < trans | v: validate | g: gate",
>> 2.   "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
>> 3.   "? <" GDG("payroll.master(0)") | u:"
>> 4.
>> 5. if RC = 0 then
>> 6. "submit job2"
>> 7. else
>> 8. "delete" GDG("payroll.master(0)")
>>
>>
>> I tried to stay true to Charles's example.  If you can to skip invalid
>> transactions, but still process valid ones (a reasonable approach), you
>> can
>> eliminate the GATE and combine the first two streams.
>>
>> GDG() is a function that I've previously written.
>>
>> Note that zero intermediate files are needed, saving those I/O operations.
>>
>> I haven't read the details of JOL, so I might be missing something.  I'm
>> happy to be educated.
>>
>>
>> OREXXMan
>> JCL is the buggy whip of 21st century computing.  Stabilize it.
>> Put Pipelines in the z/OS base.  Would you rather process data one
>> character at a time (Unix/C style), or one record at a time?
>> IBM has been looking for an HLL for program products; REXX is that
>> language.
>>
>> On Wed, Jul 11, 2018 at 6:40 AM, David Crayford 
>> wrote:
>>
>> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>>>
>>> Don't know about that! I always think that IBM has some of the best
>>>> people and concepts.  Pity IBM didn't push PL/I instead od allowing C to
>>>> rule the world.
>>>>
>>>>
>>>> They did, but something that's free will always be more attractive.
>>> Multics was originally written in PL/I but the UNIX devs didn't think it
>>> was suitable for operating systems.
>>>
>>> However, there's an interesting IBM lab in Perth that has some excellent
>>>
>>>> people. Not many people know about it.
>>>>
>>>>
>>> Not any more! They all got the push when IBM recently cut their
>>> workforce.
>>> A few of them moved to HCL with the PD products. The rest of them are
>>> looking for 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
>>
>>
>>
> --
> 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: Using JCL Symbld and TYPRUN=SCAN

[Hobart Spitz]

ld as JCL.  That needs to change.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Mon, Jul 2, 2018 at 9:56 AM, John McKown 
wrote:

> On Sun, Jul 1, 2018 at 12:12 PM Hobart Spitz  wrote:
>
> > )Why don't we just skip the JCL, and write our jobs in REXX?  The two
> >
> > Here, here!!   Actually, there is one thing that is critical to retiring
> > JCL.  It's a host command that allows a REXX program to list and wait for
> > all it's datasets and their enqueues to be available. This is not
> trivial,
> > so that's why no installation has taken it on.  I don't know why IBM
> keeps
> > shoe-horning new features with big astonishment factors into JCL.  z/OS
> is
> > the only major platform with a separate batch-only language.
> >
> > Anyone want to write sn RFE?
> >
> >
> ​I very much agree that JCL needs to be retired. It has a long and
> not-so-lustrous ​career. However, at least for me, one major thing which
> needs to be a critical consideration is restarting a "batch process" (aka
> REXX program, shell script). There needs to be someway which will, like
> CA-11 for instance, track what DSNs / UNIX files were created so that they
> can be automatically deleted when it is necessary. The new process must
> have a monitor which will keep track of which "step" equivalent has
> executed and be able to do something like a CA-11 restart. This becomes
> very complicated if the new processor can do looping. I can envision a REXX
> like environment where you can something like:
>
> /* REXX batch process */
> ADDRESS BATCH /* activate the BATCH environment */
> DSNPATTERN='SOMEHLQ.PROCESS.**.INPUT'
> "FINDDSNS (DSNPATTERN) (STEM DSN."
> /* Above does a catalog search for the DSNs described in DSNPATTERN */
> /* DSN.0 == Number of DSNs found */
> /* DSN.? (1 to DSN.0) == DSN found */
> "ENQDSN (ISTEM DSN. OSTEM DDN. TIMEOUT 3600"
> /* Above does a SYSDSN enqueue on all DSNs in the stem, waiting up to 3600
> seconds -- 1 hour */
> /* ISTEM is a REXX "array" of DSNs which are input to the ENQDSN
>OSTEM is a parallel REXX "array" of DDNs which are allocated to
>  the corresponding ISTEM input DSN.
> */
> IF RC <> 0 THEN DO; /* ENQ FAILED -- nothing allocated */
>SAY "ENQ TIMED OUT -- ABORTING"
>EXIT 16 /* END BATCH PROCESS WITH CC OF 16 */
> END
> DO DDN_NUM = 1 TO DDN.0
>"REALLOC SYSIN " DDN.DDN_NUM
>/* The above does a FREE on SYSIN (unless OPEN) and reallocates
> DDN.DDN_NUM
>   to the DDN of SYSIN -- assumes DDN is harded coded in the program
>*/
>ADDRESS ATTACH "SOMEPGM PARM TO SOMEPGM" /* standard BATCH parameter
> list */
>"CKPT" /* tell the BATCH environment to "checkpoint" somewhere */
> END
>
>
> ​The above is just some "off the cuff" thoughts and a simple example of how
> something _might_ look. The BATCH environment is the replacement for JCL.
> It somehow communicates either with the JES system record checkpoint
> information for "restarting" the batch process if something happens. I
> didn't go into this because I simply don't have any good ideas. ​
>
>
> --
> There is no such thing as the Cloud. It is just somebody else’s computer.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: REXX as JCL replacement

[Hobart Spitz]

The JOL effort is commendable, but replacing JCL is about much more than a
nicer syntax or easy movement between foreground and background.

At the risk of repetition, other reasons are (1) to eliminate the
separation between scripting code and application code and (2) to interface
with other software/data (files, DB2, ISPF, etc.).

Resistance to replacing JCL comes from the fact that "everybody knows JCL"
(which they don't really).  Everybody (in the target audience) knows REXX,
if not directly, then because REXX has many well-know features of other
languages.  JCL resembles only mainframe assembler.

Add in PIPElines and you get a productivity and performance improvements
unlike any other option available.  Charles's example in REXX and PIPElines
might look like this.

   1. "pipe (end ?) ? < trans | v: validate | g: gate",
   2.   "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
   3.   "? <" GDG("payroll.master(0)") | u:"
   4.
   5. if RC = 0 then
   6. "submit job2"
   7. else
   8. "delete" GDG("payroll.master(0)")

I tried to stay true to Charles's example.  If you can to skip invalid
transactions, but still process valid ones (a reasonable approach), you can
eliminate the GATE and combine the first two streams.

GDG() is a function that I've previously written.

Note that zero intermediate files are needed, saving those I/O operations.

I haven't read the details of JOL, so I might be missing something.  I'm
happy to be educated.


OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 11, 2018 at 6:40 AM, David Crayford  wrote:

> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>
>> Don't know about that! I always think that IBM has some of the best
>> people and concepts.  Pity IBM didn't push PL/I instead od allowing C to
>> rule the world.
>>
>>
> They did, but something that's free will always be more attractive.
> Multics was originally written in PL/I but the UNIX devs didn't think it
> was suitable for operating systems.
>
> However, there's an interesting IBM lab in Perth that has some excellent
>> people. Not many people know about it.
>>
>
> Not any more! They all got the push when IBM recently cut their workforce.
> A few of them moved to HCL with the PD products. The rest of them are
> looking for 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: z/OS JCl vs. VSE JCL: VSAM files

[Hobart Spitz]

John wrote:
>it is not the default but is the only correct way to access a vsam file.
>disp=shr,dsn=.vsam (possible bufno,bufni,...etc)
Does any one know it that also applies to PDSEs?  AFAIK, they are VSAM
datasets.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Tue, Jul 10, 2018 at 6:33 PM, John Clifford  wrote:

> it is not the default but is the only correct way to access a vsam file.
> disp=shr,dsn=.vsam (possible bufno,bufni,...etc)
>
> Never disp=new or delete.   Disp=old can be used if you need to make sure
> you are the only one accessing the file but if it is open in CICS it will
> hang.
>
> On Tue, Jul 10, 2018 at 6:07 PM, Tony Thigpen  wrote:
>
> > So, DISP=SHR is not the default, as I thought was implied by John's
> > statement that "Z/os VSAM is always accessed as DISP=SHR."
> >
> > Tony Thigpen
> >
> > Gibney, Dave wrote on 07/10/2018 05:49 PM:
> >
> >> If DISP=SHR (that is if not DISP is provided), then the JCL Default of
> >> (NEW,PASS) would happen and the job would fail
> >>
> >> -Original Message-
> >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >>> On Behalf Of Tony Thigpen
> >>> Sent: Tuesday, July 10, 2018 2:43 PM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
> >>>
> >>> Then, why does every VSAM DD for every z/OS site I have worked with,
> >>> always include DISP=SHR?
> >>> (I guess, because it's a habit from non-VSAM files and nobody told them
> >>> they
> >>> did not have to do it.)
> >>>
> >>> Tony Thigpen
> >>>
> >>> John Clifford wrote on 07/10/2018 04:16 PM:
> >>>
>  Z/os VSAM is always accessed as  DISP=SHR.
> 
> >>>
> >>> --
> >>> 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
>

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

Re: DYNALLOC

[Hobart Spitz]

It beats the alternative.  The more I proofread, the more improvements I
make and the longer my posts get.  8-D

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Tue, Jul 10, 2018 at 2:41 PM, Peter Hunkeler  wrote:

> >> A minute AFTER I hit "send" for my message I saw the error.
>  >>
> >I do my best proofreading *after* I press the  key...
>
>
> I'm excellent at finding my typos when I read my post after it is echoed
> back to me.
>
>
> --
> Peter Hunkeler
>
>
>
> --
> 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: Primary & secondary space values in DFSORT's dynamic work space allocation.

[Hobart Spitz]

It might be worth pointing out what might be a little known fact.  Any
allocation, primary or secondary, can be done in up to 5 extents.  That
means that, on a highly fragmented pack, SPACE=(CYL,(5,5)) might only get
16 cylinders (in 16 extents) before running out of extends.  Fragmentation
at this level is unusual on modern systems, but I wouldn't assume that all
allocations were in single extents.  If you have significant fragmentation,
perhaps because work packs are not managed like other packs, you may be
dealing with a different problem then you think.

If you think specifying FILSZ might help, have you considered adding a REXX
EXEC that issues a CALL LISTDSI or a SQL SELECT COUNT(*) ... and that
calculates a crude estimate of space from that information.  The result
could then be passed to the COBOL program, either as a parm or in a VIO
dataset, and the COBOL program could pass that to sort.

Have you tried it and are getting some kind of negative result, or are you
just in the planning stage?



OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 4, 2018 at 3:36 PM, Peter Hunkeler  wrote:

> Some background, first.
>
> I was asked to help a COBOL application calling DFSORT internally via
> INPUT / OUTPUT PRODECURE (E15/E35) interface. The input data size is
> unknown, but varying greatly. FILESZ cannot be supplied. So, DFSORT has no
> way to calculate the required disk work space.
>
>
> The application was asked to change from JCL allocated SORTWKnn to
> dynamically allocated sort work space.
>
>
> DFSORT options DYNALLOC, DYNAPCT, and DYNSPC are the options used to help
> DFSORT optimally allocate the sort work space. Some extracts from the
> manual are listed below.
>
>
> I read the relevant parts in the Installation & Customization, the
> Application Programmer, and the Tuning Guide, but still I'm not sure I
> understand how and when the work space data set are allocated. The disk
> space allocated is of special interest here.
>
>
> Suppose: DYNALLOC=(,8),DYNAPCT=50,DYNSPC=2400
>
>
> Now here are the statements with a lot of uncertainty, and question marks.
> I'd appreciate confirmation, or correction where I'm wrong.
>
>
> a) DFSORT will allocate 8 initial work data sets with primary space, and
> 50% of that, i.e. 4 reserve data sets with zero space initially. The total
> amount of primary space is the equivalent of 2400 MB. The manual says this
> is the total over *all* work data sets.
>
>
>
> b) So, the primary space for each of the 12 work data sets is 200MB, but
> only the 8 initial ones are allocated with that primary amount. The 4
> reserved data sets are initially allocated with 0 space, but 200 MB will be
> allocated once DFSORT decides it needs them.
>
>
>
>
> c) The secondary space is said to be 20% of the primary, i.e. 480MB. It is
> not clear to me, whether this means any secondary extent is 480MB, or
> whether the secondary value is 480MB / 12, i.e. 40MB. This greatly
> influences the theoretical total amount of workspace.
>
>
>
>
> d) When DFSORT decides it needs more space, will it extend one, some, or
> all of the additional work data sets? At this time, the initial work data
> set have probably been extended to their maximum size (1 x primary + 15 x
> secondary). Will the additional data sets be extended by the primary amount
> only, and will grow later as needed?
>
>
>
>
> e) The first extension amount used with d) will be the primary amount
> calculated above, i.e. 200MB, right? Later, these additional data sets can
> be expanded by the secondary extent value, up to 15 times. Correct?
>
>
>
>
>
> Extracts from the Application Programmer's Guide:
>
> DYNAPCT=x
>
> specifies additional work data sets to be dynamically allocated with zero
> space. DFSORT only extends these data sets when necessary to complete a
> sort application.
>
> x specifies the number of additional work data sets (y) as a percentage of
> the maximum number of dynamically allocated work data sets
> (DYNALLOC/DYNALOC n value) in effect.
>
> DYNSPC=n
>
> DYNSPC=n temporarily overrides the DYNSPC installation option, which
> specifies the total default primary space allocation for all of the
> dynamically allocated work data sets when the input file size is unknown.
>
> ..., DFSORT uses the DYNSPC value in effect as the approximate amount of
> primary space. DFSORT uses 20% of the primary space as secondary space.
> Although the primary space is always allocated, secondary space (up to 15
> extents) is only allocated as needed.
>
> n specifies the total default primary space, in megabytes, to be allocated
> for all dynamically allocated work data sets (n is not the primary space
> for each data set).
>
>
> --
> Peter Hunkeler
>
> 

Re: REXX as JCL replacement

[Hobart Spitz]

Steve, thanks for the kind words.

One afterthought that might improve the use of the TSO PROC, if one is so
inclined.  Use //   EXEC TSO,CMD=REXXTRY ,  Put REXXTRY into one of the
SYSEXEC/SYSPROC libraries, if it's not already there.  It gives access to
most of REXX to the SYSTSPRT records.  REXXTRY is roughly to REXX what csh
is to C.  If you don't have REXXTRY, you can find the source on the web.  I
would recommend one of the IBM versions.

For example (untested):

   1. *//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
   2. *// JCLLIB ORDER=(MY.JCL.LIB) Optional*
   3. *//   EXEC TSO,CMD=REXXTRY*
   4. *//SYSTSIN  DD *  Recommended DD to avoid conflicts with SYSIN
   use.*
   5. *Trace = "e" /* Unique to REXXTRY. Show error commands. You may
   prefer "c". */*
   6. *"profile"*
   7. *call outtrap "Lines."*
   8. *"st myjobname"*
   9. *call outtrap "off"*
   10. *parse var Lines.1 "(" JESNum ")" /* cutting some corners here in
   interest of brevity */*
   11. *"%myrexpgm"*
   12. *OutDSN = "out.data(results)"*
   13. *DSStat = sysdsn(OutDSN)*
   14. *if DSStat == "OK" | DSStat == "MEMBER NOT FOUND" then **DSOptions =
   "shr"*
   15. *if DSStat == "DATASET NOT FOUND" then **DSOptions = "new
   catalog cyl space(10 10) dsntype(library)"*
   16. *if var("DSOptions") == "LIT" then do;** say time() Lines.1 OutDSN
   "-" DSStat; **exit 20; **end*
   17. *"alloc reuse dd(sysut2) dsn("OutDSN")" DSOptions*
   18. *if RC <> 0 then exit RC*
   19. *"alloc reuse dd(sysin) dummy"*
   20. *"alloc reuse dd(sysut1) shr dsn('my.in.data')"*
   21. *"call *(iebgener)" /* Trace = "e" reports failures; GENER stops if
   SYSIN/SYSUT1 missing/invalid. */*
   22. *"free dd(sysut2, sysin, sysut1)"*
   23. *//*

Here we can use SHR with our output PDSE if it already exists.

You must put ALLOCs, TSO CALLs, FREEs, and any other commands with
parentheses or characters that REXX is sensitive to, in quotes or quotation
marks.  Quotation marks ( " ) are prefered if you have fully qualified
dataset names with quotes.  See line 20.

Lines 12 thru 18 could form the basis of a common, external routine, since
it may be needed often.

Personally, I think this approach is so much better that I might set
REXXTRY as the default  value in the PROC.  On the other hand, you
don't have multil-line commands, continuations, the ability to supply
internal routines or SIGNAL handlers, so at some point it becomes
preferable to make a long sequence of commands into a program of its own.

Maybe this is what a JCL replacement could look like.  Add in some commands
for compatibility (e.g. JCL DD, JCL STEPEXEC, JCL SET, etc.), and things
look rosier and practical.

Caution:  DD DDNAME=... and "alloc ddname(...)" are two completely
different animals.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Mon, Jul 9, 2018 at 12:56 PM, Steve Smith  wrote:

> I'd like to point out that Hobart Spitz's long post is a great overview of
> the practical and useful way that at least some JCL could be replaced with
> REXX.  The details can be nit-picked eternally (and no doubt will be).
>
> sas
>
> --
> 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: REXX as JCL replacement

[Hobart Spitz]

On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz  wrote:

>  1. I don't recall anybody on IBM-MAIN claims that JCL is good.
>
There were such statements as "I like JCL", or similar.

>
>  2. Creative solutions are good if they solve the actual problem, not
> just an imaginary or irrelevant one.
>
I don't think anything I said was either.

>
>  2. Sleep does not address the deadly embrace problem.
>
I didn't claim that.  It is needed to do your up front ENQs in REXX.  You
still might have to exit with an error COND CODE if you can't get the ENQ
you need.  A single ALLOC does not give the TSU a message or time to free
up the dataset.

>
>  3. PDSE does not solve the problem.
>
You'll have to explain that.  From my reading of the doc., you can have
multiple readers and writers, in the same step or different JOBs opening
different members at the same time, provided the same member is not open
for OUTPUT by two different DCBs or JOBs/TSUs.  All this with SHaRed
access, i.e. no DISP=OLD or equivalent.  Note that I said, perhaps not
clearly enough, that the entire application, all foreground and background
accesses, must be SHaRed.  What am I missing?

Thanks.

>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ____
> From: IBM Mainframe Discussion List  on behalf
> of Hobart Spitz 
> Sent: Monday, July 9, 2018 8:46 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: REXX as JCL replacement
>
> Ward wrote:
> >What are the problems (perceived or real) that will be resolved by
> replacing JCL with REXX?
>
> I think that it's important to first understand the characteristics on
> which many people base their thinking that JCL is good and may never go
> away.  The point is important, and the basis is a valid concern.  The
> conclusion is wrong.  All it takes is understanding the problem and coming
> up with creative solutions.  As I describe below, DB2 based applications
> and those that use only PDSEs are likely to be good starting points.
>
> One valuable feature of z/OS batch processing is that all ENQs for the
> entire JOB are obtained before any step execution actually starts.  This is
> done to prevent a deadly embrace:  JOB A has exclusive access to dataset X
> and needs exclusive access to dataset Y.  JOB B has access to Y and needs
> exclusive on X.  Neither JOB can proceed until one is canceled, resulting
> in lost production.  Despite this being a useful service, there is no TSO
> equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
> SLEEP mechanism to allow for retries.
>
> Other repliers have answered Ward's question well, I was going to cut some
> of the text out of my draft, but didn't.  I think it is important to
> understand what z/OS batch processing does, and where possible, why, so we
> don't trivialize the effort or miss easy opportunities.  I'll share my best
> educated guesses with respect to the subject at hand.
>
> When a batch JOB becomes eligible for execution these actions, relevant to
> our subject, happen in this order:
>
>1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
>merged with the submitted JCL.  These are necessary for #2 below.
>2. Substitutions are processed.  This is needed for #3; if DSNs could
>change later, via substitution or IF, the ENQs would be incorrect.
>3. ENQs are obtained on all datasets.
>4. The EXECs for PGMs are processed, in order, one at a time.
>
> So any REXX implementation would have either to forgo do initial ENQs, or
> commit to not changing DSNs during processing, or observe certain
> conventions.  These conventions could include the following, one or the
> other may be appropriate depending on the applications' needs:
>
>- Perform ENQs in a consistent order.  (Left as an exercise for the
>reader.  :-)  )
>- Do all ALLOCations up front, and free all exclusive allocations before
>a second set of ENQs is requested.
>- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
>or ALLOC failure, and taking appropriate action to
> recover/restart/suspend
>processing.  Initial ENQs are not required.  If implemented via a common
>routine, either site or vendor provided, this could be more viable.  A
>little additional coding to support automated restart might be needed;
> see
>also below on my first attempt at using REXX instead of JCL.
>- Something else.
>
> It might be helpful to know if, with all the changes and advancements,
> deadly-embraces are still the issue it was in the 1960s-1980s.  As I
> explain below, an application that does not update any sequential datasets
> or PDSs, does not have this as a major concern. 

Re: REXX as JCL replacement

[Hobart Spitz]

Ward wrote:
>What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away.  The point is important, and the basis is a valid concern.  The
conclusion is wrong.  All it takes is understanding the problem and coming
up with creative solutions.  As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts.  This is
done to prevent a deadly embrace:  JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y.  JOB B has access to Y and needs
exclusive on X.  Neither JOB can proceed until one is canceled, resulting
in lost production.  Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.

Other repliers have answered Ward's question well, I was going to cut some
of the text out of my draft, but didn't.  I think it is important to
understand what z/OS batch processing does, and where possible, why, so we
don't trivialize the effort or miss easy opportunities.  I'll share my best
educated guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to
our subject, happen in this order:

   1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
   merged with the submitted JCL.  These are necessary for #2 below.
   2. Substitutions are processed.  This is needed for #3; if DSNs could
   change later, via substitution or IF, the ENQs would be incorrect.
   3. ENQs are obtained on all datasets.
   4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions.  These conventions could include the following, one or the
other may be appropriate depending on the applications' needs:

   - Perform ENQs in a consistent order.  (Left as an exercise for the
   reader.  :-)  )
   - Do all ALLOCations up front, and free all exclusive allocations before
   a second set of ENQs is requested.
   - Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
   or ALLOC failure, and taking appropriate action to recover/restart/suspend
   processing.  Initial ENQs are not required.  If implemented via a common
   routine, either site or vendor provided, this could be more viable.  A
   little additional coding to support automated restart might be needed; see
   also below on my first attempt at using REXX instead of JCL.
   - Something else.

It might be helpful to know if, with all the changes and advancements,
deadly-embraces are still the issue it was in the 1960s-1980s.  As I
explain below, an application that does not update any sequential datasets
or PDSs, does not have this as a major concern.  E.g. an application where
all data updates are done to DB2 tables and PDSEs.  Replace sequential
datasets and PDSs with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available
during execution time, there can be no initial ENQs, since the dataset name
is not known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically,
lock in current customers due to the cost of porting and lack of equivalent
features elsewhere.  Some smart developer may come to understand this and
provide the missing service.  Some smart lawyer at a competitor might just
decide to take legal action on an anti-competitive basis.  Either scenario
could represent an exposure to IBM (competitive or legal) and potential new
costs to customers.  At the same time that existing customers are locked
in, new customers are locked out for the same reasons.

I'm going to provide some background, because, in some cases there are no
barriers to using REXX in batch.

That said, if your application does not update sequential or partitioned
datasets (in any JOB), then you can use REXX batch today, without any
significant risk of deadly-embrace or other problems.  This would most
likely apply DB2 base applications, where all the DDs are for DB2 libraries
reference with DISP=SHR.

Give it a try.  If you get down to just a fraction your previous
conventional JOBs, your management might get the idea that you are
onto something and change any fossilized mind-set about JCL.

If all your DISP='s are SHR, you may already have the opportunity to
streamline your application.  This is not theory.  I have done it, as I
describe in the next paragraph.  AFAIK, you can code SHR for PDSEs in the
common cases.  REWRITE/UPDATE in place is the main exception; you at 

Re: DFSORT - a quick way to compare two huge files

[Hobart Spitz]

How about something like:

*/* REXX */*
*...*
*"pipe (end ?) ? < file1.data | g: gather | join | pick 1.1500 /== 1501-*",*
*  "| c: count lines | literal Mismatched record pairs: | cons",*
*  "? < fileb.data | g:",*
*  "? c: | var BadCount"*

*exit BadCount*

It works like this:

   - < reads a file.
   - GATHER reads from the two input streams, alternately, one record at a
   time.
   - JOIN concatenates each pair of records, one from each file, into a
   single record.
   - PICK passes mismatches, by comparing the first 1500 bytes to the
   second 1500.
   - COUNT records the number of records is sees, and, at EOF, writes it to
   it's secondary output, which is connected to VAR.
   - VAR stores it's record into a REXX variable.
   - LITERAL labels the output.
   - CONS writes the output to the terminal; substitute > if you prefer.
   - ? starts a new stream.
   - G: and C: make connections to secondary streams.

If you want just 0 or 1 in in the return code, replace COUNT with FANOUT,
and use EXIT SYMBOL("BadCount") == "LIT".  FANOUT will remove itself from
the pipe as soon as the first mismatch is found.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Fri, Jul 6, 2018 at 8:52 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Last time I checked SUPERC (even the "advanced" version delivered in the
> HLASM Toolkit) is pretty useless beyond LRECL=200.  It wouldn't even show
> the differences in bytes beyond 176, IIRC.  It seems to me that SUPERC's
> design point is source-code file comparisons, and even there not so much
> for really-long-line-length-allowed languages.
>
> The commercial compare products (Comparex, INSYNC, FileMaster, etc.) do a
> pretty good job even on really large data files, if your employer is
> already paying for them.  Comparex was always my favorite for the ability
> to compare files with random-order (or at least not fully sorted) keys.
>
> But Sri's DFSORT example is impressive, as usual.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of retired mainframer
> Sent: Friday, July 6, 2018 10:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT - a quick way to compare two huge files
>
> EXTERNAL EMAIL
>
> Is there some reason SUPERC is not appropriate for this task?
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of R.S.
> > Sent: Friday, July 06, 2018 4:04 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: DFSORT - a quick way to compare two huge files
> >
> > We have two output files, rather huge ones (rather gigabytes than MB's)
> > with LRECL~1500, FB.
> > The goal is to compare them and find different records.
> > While I have some ideas how to do it (even ISPF Compare or ICETOOL) I
> > don't think it would effective.
> --
>
>
> 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 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: REXX as JCL replacement

[Hobart Spitz]

I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX.  That way, you
don't have to reinvent or do without all the things that REXX brings to the
table, both as a language and as something that interfaces with many parts
of z/OS.  I.e., DB2, JES, ISPF, TSO, etc.

I think CA also has a similar product.  I don't know anything about it, or
if it is used much.

The existence of JOL and the CA product suggest that there is a wider need
than realized to upgrade z/OS batch processing to more modern methods.
Historically, IBM has had more scripting languages than platforms (z/OS:
REXX, CLIST, JCL.  z/VM: EXEC, EXEC2, REXX.  AS/400: OCL.), and z/OS is the
only major platform where the batch scripting language (JCL) can't run in
foreground, and the foreground scripting languages can be useful in
background, but aren't.  z/VM has never had a separate batch scripting
language, and it still can do things that z/OS was never designed for.

I think Ward's question was well answered.  I might add a few things later
that were missed.  (I have a long draft that is mostly redundant.)

All that said, I'd like to come back to the primary, perhaps only, reason
why REXX is not used more in batch:  "Parallel ENQs", or the lack thereof.
I use quotation marks because I am skeptical that anything like this can
actually be truly simultaneous.  On the other hand, the time scale on which
ENQs are typically held means that near simultaneous is fast enough.

BTW, if all updatable application data is stored in DB2 tables (e.g.)
and/or all DISPs are SHR, there is no reason not to use REXX in batch.  If
DISP=OLD is never used there can be no deadly embrace.  This is not
theory.  In the early 1990s, I did just such a project, replacing more than
300 JOB streams with less than 10 much smarter ones that began by invoking
a REXX program.  All updated data was in DB2, and we used a REXX-to-DB2
interface.

Let's consider what a "Parallel ENQ" routine might look like.  This should
allow the approach to be explored and refined, proving/disproving the
concept to site management and vendors, and help formulate the most
appropriate RFE.

Here a first draft, untested, for an external, preferably compiled routine:


*AllocMlt:*

*/* REXX - Allocate dataset(s) to files(s).  Retry and recover if needed.
*/*

*/* Arg syntax:  DDName BeforeDisp[","NormDisp] Dataset... [")" options]
*/*

*/* Abnormal Disp to be handled by return code check and FREE in caller.
*/*

*/* We let ALLOC report problems with ENQs of concatenated datasets.
*/*

*/* Stop on the first failure; if we could send msgs. in fut., keep
going.*/ *



*Alloced. = 0   /* Track successes
*/*























*do iA = 1 to arg() until RC <> 0parse upper value arg(iA) with DDName
Disp DSN/* Code RecFM, LRecL, DataClas, Space, etc. after DSN and ")".
 *//* ALLOC allows concatenation via a list of dataset names.
 */  /* DSN may be a list if Disp not NEW or MOD. */parse var
Disp BeforeDisp "," NormDisp /* Like JCL. */Status = sysdsn(word(DSN,
1))if BeforeDisp = "ASIS" then BeforeDisp = word("new old",
(Status = "OK") + 1)/* Allows skipping archaic use of IEFBR14. */
  if wordpos(BeforeDisp, "OLD SHR") > 0 thendo iTry = 1 to 5 while
Status = "DATASET UNAVAILABLE"say time() DSN "unavailable,
retrying."/* Would be important to send message to ENQ holder,
esp. TSU. */call sleep "10 sec" /* SLEEP may need to be
written. */Status = sysdsn(word(DSN, 1))end iTry
select when Status = "OK" & wordpos(BeforeDisp, "OLD SHR") > 0
thennopwhen subword(Status, 2) = "NOT FOUND" & *
*wordpos(BeforeDisp, "NEW MOD") then*

















*nopotherwise /* Status incompatible with BeforeDisp,
or other error. */say "Attempting" arg(iA)", status"
Status"." leave iAend "allocate reuse
file("DDname")" BeforeDisp NormDisp "dataset("DSNAlloced.iA = (RC = 0)
  end iAif iA > arg() then /* Success */exit 0/* Failure */do iA2 = 1
to iAif Alloced.iA2"free file("word(arg(iA2), 1)end iAexit
-iA*



Any thoughts?  Anyone want to try it out and post the results?

SYSDSN() having the relatively new DATASET UNAVAILABLE value means there
are other, possibly more creative ways to handle ENQ conflicts.



OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 4, 2018 at 9:14 PM, zMan  wrote:

> >
> > >What would it take for IBM to allocate just a couple of people to make
> it
> > available as a supported product?
> >
>
> Having someone left in POK who knows how to code. Not sure 

Re: REXX as JCL replacement

[Hobart Spitz]

This probably doesn't need to be said, but all(/most?) Access Method
Services (IDCAMS) commands are TSO commands.

Under TSO, it's enough to write:
 ...
call outtrap "CmdOut."
"listcat cluster"
call outtrap "off"
...

or

...
"pipe listcat | stem CmdOut."
...

In PIPElines, LISTCAT is a built-in stage.  I am not sure about using
cluster here.



On Tue, 3 Jul 2018, 12:24 pm Paul Gilmartin, <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2018-07-03, at 08:58:26, Tony Thigpen wrote:
>
> > *PLEASE* don't re-invent the wheel. z/VSE has had this for 15+ years. We
> have had time to shake out the issues.
> >
> Yes, but would it be feasible to port these to z/OS?  Something like
> the enhancements to DYNALLOC that Shmuel discusses.  It can't be done
> entirely by enhancements to the Rexx interpreter.
>
> Does z/VSE perform multiple allocations with no deadlock hazard?
>
> > We also have ways to provide SYSIN and capture SYSLST:
> > CALL OUTTRAP idcams_output.
> >
> > CALL REXXIPT idcams_input.
> >
> For generality, these should have a DDNAME operand; an
> enhancement such as:
>
> call outtrap "sysprint_stem. (dd sysprint"
> call outtrap "sysut2_stem.   (dd sysut2"
>
> call rexxipt "sysin_stem.(dd sysin"
> call rexxipt "sysut1_stem.   (dd sysut1"
> (I certainly recommend quoting symbol names to prevent evaluation.)
>
> address LINKMVS "IEBGENER"
> (Neither LINK nor LINKPGM provides a z/OS compatible plist.)
>
> Would Pipelines provide an alternative to (enhanced) OUTTRAP
> and REXXIPT?  I've asked a similar question on CMS-PIPELINES
> but always been misunderstood.  The answers told me of stages
> to connect to the other end of the DDNAME.
>
>
> > Seymour J Metz wrote on 07/03/2018 10:32 AM:
> >> When you reinvent the wheel, please make them round. A procedural
> replacement for JCL has all sorts of issues, regardless of syntax. Instead,
> why not
> >>  1. Enhance Dynalloc to have a parallel allocation function.
> >>  2. Enhance IRXJCL to allow a script in a sequential dataset.
> >>  3. Enhance REXX to support parallel allocation.
> >> The installation could then provide custom procedures for invoking
> IRXJCL
>
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: REXX as JCL replacement

[Hobart Spitz]

How about something like this?

Use REXX syntax and a JCL host command with JCL-like semantics:

/* REXX */

arg String /* From SUBMIT or start task command. */

"jcl job myjob: (acct),'john smith',class=t,msgclass=h,notify="userid()
"jcl exec pgm=myprog,parm="date("s")
"jcl sysprint: dd sysout=*"

"jcl sysin dd *"

"jcl data" String

...


The JCL host command could create the exact same control blocks as the
existing JCL statements today, but not begin execution.  When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup.  All exit/interfaces would be
preserved so that third-party software would still work unchanged.


OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote:
>
> >Oh my gosh, you would have to maintain JCL forever for that and a dozen
> other reasons.
> >
> >BUT! Conceivably ... conceivably ... you might stabilize it and do
> everything new in Rexx going forward.
> >
> If the replacement had a superset of JCL function, providing a
> JCL-to-replacement
> translation utility would allow discarding direct support for JCL.
>
> >-Original Message-
> >From: John Melcher, Jr
> >Sent: Monday, July 2, 2018 10:46 AM
> >
> >Once upon a time a LONG time ago this was a GUIDE  requirement.  It was
> >voted down due to the amount of automated systems that generated JCL.
> >You'd have to keep JCL, probably forever, because of those systems.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Hobart Spitz]

)Why don't we just skip the JCL, and write our jobs in REXX?  The two

Here, here!!   Actually, there is one thing that is critical to retiring
JCL.  It's a host command that allows a REXX program to list and wait for
all it's datasets and their enqueues to be available. This is not trivial,
so that's why no installation has taken it on.  I don't know why IBM keeps
shoe-horning new features with big astonishment factors into JCL.  z/OS is
the only major platform with a separate batch-only language.

Anyone want to write sn RFE?

On 21 Jun 2018 9:48 pm, "Andrew Rowley" 
wrote:

On 22/06/2018 11:21 AM, Steve Smith wrote:
> Why don't we just skip the JCL, and write our jobs in REXX?  The two
> main things JCL does, EXEC and DD, are just as easy in REXX, (call,
> alloc) with a ton more flexibility.  EXPORT, SET, IF, and symbols are
> lipstick for a pig.

I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.

In a previous job I tried to write scripts on a unix system to try to
fix tasks that had a tendency to open one file and then wait for
another, where multiple tasks were deadlocking. This is so simple with
JCL because you don't get one allocation until you get them all.

The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is much better than one long command line) or hard code them.


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

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

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

Re: Issue WTO message using MVS SEND command

[Hobart Spitz]

I'm not sure which message(s) you are looking for, and I'm not familiar
with PIPElines in NetView.

That said, this should get you closer.  In PIPElines environment with which
I am familiar, this would be my first recommendation:

"pipe (listerr) SAFE * | STEM MSG. | cons"

"... | cons" writes the stream data to the console.  Unlike *NIX piping,
the default is not to write to the console.
LISTERR allows PIPE to display error messages.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Sun, Jun 24, 2018 at 8:40 AM, saurabh khandelwal <
sourabhkhandelwal...@gmail.com> wrote:

> Hello All,
>
> I still have same issue when i use pipe command in rexx and I don't get
> message on console. But when I don't use pipe command on console, then I
> get message on console.
>
> Details are below.
>
> 1) Doesnt work. It means that we don't get messages on console.
>
>
> Netview automation table **
> ***
>
> IF MSGID = 'SVTM052I' THEN
>
> EXEC(CMD('FDIREXX')) NETLOG(Y) SYSLOG(Y);
>
>
>
>
>
> BROWSENETVIEW.CNMCLST(FDIREXX) - 01.17   Line 
>
> * Top of Data **
>
> /*  REXX */
>
> trace i
>
> 'PIPE SAFE * | STEM MSG.'
>
> TODataset = Word( Msg.3,3 )
>
> WTO.CONSNAME ='CNDVMSTR'
>
> WTO.DESC = '01000100'/* WHITE */
>
> WTO.DESC = '00100010'/* RED   */
>
> WTO.MCSFLAG  = ''
>
> WTO.TEXT = 'FDI' TODataset
>
> WTO
>
> mvs "send 'FDI DATAST NAME IS "TODataset"',user=(TS06,OP117),LOGON"
>
> exit
>
>
>
>
>
> Netview Log
>
>
> 2) Solution works .It means that we get messages on console.
>
>
> Netview automation table **
> ***
>
> IF MSGID = 'IEF403I' & TEXT = .'OP117LST'.  & TEXT = MTXT THEN
>
>  EXEC(CMD('FDIREXX1 'MTXT)) NETLOG(Y) SYSLOG(Y);
>
>
>
> /*  REXX */
>
> trace i
>
> parse arg mtxt . mtxt
>
> WTO.CONSNAME = '   '
>
> WTO.DESC = '01000100'/* WHITE */
>
> WTO.DESC = '00100010'/* RED   */
>
> WTO.MCSFLAG  = ''
>
> WTO.TEXT =  'CONSOLE TEST MSG IS' mtxt
>
> WTO
>
> exit
>
>
>
>
>
>  Netview log
>
>
>
> - CNM493I DSITBL01 : #250 : FDIREXX1 IEF403I AB54LST -
>
> E IEF403I AB54LST - STARTED - TIME=07.19.45
>
> C  3 *-* parse arg mtxt . mtxt
>
> C>>>   "IEF403I"
>
> C>.>   "AB54LST"
>
> C>>>   "- STARTED - TIME=07.19.45"
>
> C  4 *-* /* say 'AB54LST Job STARTED at' mtxt */
>
> C  5 *-* /* mvs "send 'AB54LST JOB "mtxt"',user=(AB54)
>
> C  6 *-* /*  mvs "send 'CONSOLE OUTPUT DISPLAY "mtxt"',C
>
> C  7 *-* WTO.CONSNAME = 'CNDVMSTR'
>
> C>L>   "CNDVMSTR"
>
> C  8 *-* WTO.DESC = '01000100'/* WHITE */
>
> C>L>   "01000100"
>
> C  9 *-* WTO.DESC = '00100010'/* RED   */
>
> C>L>   "00100010"
>
> C 10 *-* WTO.MCSFLAG  = ''
>
> C>L>   ""
>
> C 11 *-* WTO.TEXT =  'CONSOLE TEST MSG IS' mtxt
>
> C>L>   "CONSOLE TEST MSG IS"
>
> C>V>   "- STARTED - TIME=07.19.45"
>
> C>O>   "CONSOLE TEST MSG IS - STARTED - TIME=07.19.4
>
> C 12 *-* WTO
>
> C>L>   "WTO"
>
> C 13 *-* exit
>
> > CONSOLE TEST MSG IS - STARTED - TIME=07.19.45
>
>
> On Fri, Jun 22, 2018 at 9:15 PM, saurabh khandelwal <
> sourabhkhandelwal...@gmail.com> wrote:
>
> > Thanks for reply.
> >
> > I looked at netview command manual and found  "WTO.TEXT" can be used for
> > this purpose. But I am not sure, how do I incorporate this into this
> case.
> >
> > Netview table code.
> >
> >  IF MSGID = 'SVTM052I' THEN
> >  EXEC(CMD('FIBREXX')) NETLOG(Y) SYSLOG(Y);
> >
> >
> >
> > In our rexx we retrieve the full messge via:
> >
> > /* REXX   */
> >
> > 'PIPE SAFE * | STEM MSG.'
> >
> > TODataset = Word( Msg.3,3 )
> > mvs "send 'FIB DATASET NAME IS "TODataset"',CON=CNDVMSTR"
> >
> > in this rexx, where do I need to add WTO.TEXT to display  TODataset as
> > WTO message on operator console.
> >
> > Can anybody suggest to implement this change.
> >
> >
> >
> > On Fri, Jun 22, 2018 at 5:15 PM, Lucas Rosalen 
> > wrote:
> >
> >> Right tool for the right job.
> >>
> >> Read about WTO (REXX) command in Netview commands manual.
> >>
> >> 
> >> ---
> >> *Lucas Rosalen*
> >> rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
> >> http://br.linkedin.com/in/lrosalen
> >>
> >>
> >> 2018-06-22 6:31 GMT+02:00 saurabh khandelwal <
> venkatkulkarn...@gmail.com
> >> >:
> >>
> >> > Hello Group,
> >> >
> >> >
> >> >  /*  REXX */
> >> >
> >> > 'PIPE SAFE * | STEM MSG.'
> >> >
> >> >
> >> >
> >> > TODataset = Word( Msg.3,3 )
> >> >
> >> > mvs 

Re: Two new RFE's to consider supporting

[Hobart Spitz]

Mouse selection exists.  Configure your mouse to send CUR SEL, which
emulates a light-pen press.  The panel needs to make the field
light-pen/CUR SEL compatible.

We did this in the early 80s, writing an in-house emulator, before
emulators were available.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Fri, Jun 22, 2018 at 5:41 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> I've been utilizing this new "point and shoot" feature in SDSF for about a
> week now.  I like it, but its not perfect, for reasons others have
> mentioned.
>
> In this particular case it seems to me what would be ideal is if the
> feature did not require the cursor to be placed within the JOBNAME column.
> Rather, it seems to me that:
> - If the cursor is anywhere in a particular row,
> - and the NP column for that row is "empty",
> - then "pressing enter" would have the same action as if the NP column had
> '?' entered in to it.
>
> Can't think of anything that would break, but who knows.  I believe it
> would eliminate any need to turn on the ISPF "Tab to point-and-shoot
> fields" option.  Basically, if not using a mouse, you could simply
> "newline" to the NP column on the desired line (without having to worry
> about "tabable" column headers) and press enter.
>
> I have no idea if this would address the actual reason the RFE was opened.
>
> Frank
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jesse 1 Robinson 
> Sent: Friday, June 22, 2018 11:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Two new RFE's to consider supporting
>
> I voted for the PAS RFE as a user, not considering what I know--or don't
> know--about the underlying technology. A particular ISV product some time
> ago changed a screen to create exactly what Lionel is complaining about. A
> column title on a PDS member list was suddenly tabbable, 'capturing' the
> cursor on its way to the first member entry. I complained and got the
> answer that some customers wanted this behavior so they could (re)sort the
> list based on that column. My objection was that 99% of the time a(ny) user
> wants to select a member entry, not sort the list. ISV gave me some kind of
> fix.
>
> I recently started a thread here on the new default behavior of SDSF in
> z/OS 2.3. PAS, if it's useful at all, should be controllable by the user. I
> question the value of PAS if only because it interrupts the 'finger flow'
> of an application. You have to keep a wary eye peeled on the screen all the
> time to know where you're at. That might be fine for a first-time or
> occasional user, but it compromises productivity for the experienced user.
> Which most of us are.
>
> .
> .
> 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 Seymour J Metz
> Sent: Friday, June 22, 2018 9:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Two new RFE's to consider supporting
>
> Given that ISPF already supports point and shoot and that IBM has no
> control over 3rd party 3270 simulators and TN3270 clients, you'll need a
> strong business case. The only solution I know of within the existing 3270
> protocol is a zero-width field.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Dyck, Lionel B. (RavenTek) 
> Sent: Thursday, June 21, 2018 3:08 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Two new RFE's to consider supporting
>
> Please consider supporting these RFE's that I just submitted:
>
> ISPF Point and Shoot Protected Fields
>
> https://secure-web.cisco.com/1eSaRV5UJ3V1J9lFuWduNMNEXKwsjE
> r0nnYLCdtANa5wcGIytP_p89VwxV76dUYujSzZGvsssoum5dfWf
> 031TCGUtebzzpwdlkSgZJnaqbpOkVLJas5jtys5H1gU8JRFNOD2vMXd3U8ab
> HHyUJFosa64XBfNSgGc5MvffGa_1ZfKyWEpmQAA3kv0sNVrx-whBQbW89l_3pWtg15_
> 7MBLqVtWvke6na3t-Tk6vOswu28yUE4IUe2koNEA8oyONAN
> QER39qJALUqHMLIzs58oysAkIsJcmb1ccODLmdnzKY2gXS9eVRancgDDeqgV
> BCArpyN5npMA64aVH_B47XdVoSdSV7DtHk5UyIdPlCkMjOI6
> 9Dv8kpj0u74ruw1jKi-4U9/https%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2Frfe%
> 2Fexecute%3Fuse_case%3DviewRfe%26CR_ID%3D121576
>
> And
>
> Improve ISPF 3.17 by allowing CD on the command line
>
> https://secure-web.cisco.com/1xtqTd4IbEpSIeq1S0zeI1IMPcAcWs
> FuqmZWHpViLukOiAtsG1u7lb2OGbEuJwHffWY-3ICATc1LstgliNG5YJwm_ehvRmlvFVRjp1_
> ELkgd2iFLph4vBOuNp9wHVtL3RKyceFMRN7yre-njqs_Cp5ejI7zvJhlJ9KQNaY5Uf-
> 3lQTeIfIugyV8IIgCZR8TlawkDi4qZiF7y_zgKvvN0SxF_
> 

Re: [EXTERNAL] AW: ISPF programming

[Hobart Spitz]

I'm *really* rusty, but would .AUTOSEL help?  IIRC, it would give you
control back in additional situations.

Another thought:. It may help to check .RESP for a scroll key, save that
value, and set .RESP to ENTER .

Both are a bit cludgy, but something along those lines may help.

On Tue, 19 Jun 2018, 11:18 am Mike Schwab,  wrote:

> Can you control how far it scrolls?
> First scroll you limit the  CC or DD to the first / last line.
> Subsequent scrolls from the CC or DD would hide (XX..XX) the other
> lines and retain the CC or DD line on the screen?
> A scroll toward the CC or DD would show (F9 or L9) the number of
> screen lines away from the CC or DD.
> On Tue, Jun 19, 2018 at 9:29 AM Dyck, Lionel B. (RavenTek)
>  wrote:
> >
> > There is no way that I know of to capture the scrolling unless you make
> the scrolling a passthru and then your application would have to process
> it. That is doable - again just more code.
> >
> >
> --
> > Lionel B. Dyck (Contractor)  <
> > Mainframe Systems Programmer – RavenTek Solution Partners
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Immo
> > Sent: Tuesday, June 19, 2018 9:26 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: AW: [EXTERNAL] AW: ISPF programming
> >
> > Hi Lionel,
> >
> > thanks for your reply. That's exactly what I'm doing. My problem is the
> disappearance of the short message 'block command incomplete' during
> scrolling. If sufficient table rows are already put into the table, my
> program won't receive control from ISPF during scrolling. So I cannot
> redisplay the message. Do you have any idea about this?
> >
> > Greetings,
> > Immo
> >
> > -Ursprüngliche Nachricht-
> > Von: IBM Mainframe Discussion List  Im
> Auftrag von Dyck, Lionel B. (RavenTek)
> > Gesendet: Dienstag, 19. Juni 2018 16:17
> > An: IBM-MAIN@LISTSERV.UA.EDU
> > Betreff: Re: [EXTERNAL] AW: ISPF programming
> >
> > For your processing when you have a block command entered, that is a
> block command that your application must process. You must first determine
> the 1st row with the block command and then save that row as you scroll
> until you get to the 2nd occurrence of the block command. After the user
> enters 'DD' (for example) you can display a message if you don't find a 2nd
> 'DD'. It's just code - perhaps not easy - but map it out and you'll get it.
> >
> >
> --
> > Lionel B. Dyck (Contractor)  <
> > Mainframe Systems Programmer – RavenTek Solution Partners
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Immo
> > Sent: Tuesday, June 19, 2018 9:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] AW: ISPF programming
> >
> > Hi Elardus,
> > thanks for you fast response.
> >
> > >Are you referring to 'ISPF Tables' or your own table?
> > I'm processing a table I've defined in a panel definition using a
> ')Model' section. The table includes a 2 byte command input field in every
> line that is mapped to a ZVAR. Does that answer your question?
> >
> > >In what language? What ISPF utilities and macros are you using?
> > I'm using 370/390 assembler calling 'ISPLINK' in order to request ISPF
> functionality.
> >
> > Groete / Greetings,
> > Immo
> >
> > -Ursprüngliche Nachricht-
> > Von: IBM Mainframe Discussion List  Im
> Auftrag von Elardus Engelbrecht
> > Gesendet: Dienstag, 19. Juni 2018 15:41
> > An: IBM-MAIN@LISTSERV.UA.EDU
> > Betreff: Re: ISPF programming
> >
> > Immo wrote:
> >
> > >while programming a ISPF test program I would like to implement the use
> of block commands such as 'CC..CC' or 'DD..DD' in the ISPF editor. In order
> to do so I may need to display a message like 'block command incomplete' on
> various panel displays until the user either cancels the request or
> completes the incomplete block command.
> >
> > Did you considered using an Edit Macro? Something like this?
> >
> > ISREDIT MACRO
> >   ISREDIT blah blah
> > ISREDIT END
> >
> > or the 'Dialog Services' in ISPF?
> >
> >
> > >The problem I'm facing right now is the fact that ISPF won't return
> control to my application program when the user scrolls through parts of
> the table display where no new lines need to be provided by my application
> program.
> >
> > Are you referring to 'ISPF Tables' or your own table?
> >
> >
> > >Does anybody know how to handle this or can I specify something e. g.
> in the panel definition in order to receive control in my application
> program when the user presses a scroll key without making any change to an
> input field of my panel?
> >
> > In what language? What ISPF utilities and macros are you using?
> >
> > Groete / Greetings
> > Elardus Engelbrehct
> >
> > --
> > For 

Re: PIPElines vs. *nix

[Hobart Spitz]

Gil, I know you mean well.

Your first two points are addressed by one answer:  The goal in the test is
to compare the efficiency of record-oriented piping versus
character-by-character piping.

In the first case, bypassing the *nix piping mechanism defeats the goal of
the test.

In the second case, cat can't finish until wc starts reading the last 4k
(or so) characters at the very end of the data.  With 170 M of data, that
means that the timing would be off by very much less than 0.01%, which
greatly exceeds normal variation.  Further, the timings were reported to me
in more detail than I believe time reports.  Therefore, it was probably not
the time output that gave 75 secs.  I just choose to use the only total
time that was reported to me.

Finally, I got confused and assumed that the original PIPElines case was
abbreviated or there was a typo.  I incorrectly added the $ cms and
quotes.  That is entirely on me.  It should have just read:

PIPE < /home/../m170file.data | count bytes | cons


I've heard of PIPElines with 10K-15K (mostly generated) stages.  Depending
on the topology, such a thing would be impossibly slow with
character-by-character piping.  And that's assuming you could even do
deterministic multi-stream piping the way PIPElines does.

Think of the difference between *nix piping and PIPElines piping this way:
Your have a dinner party with a dozen guests.

Under *nix piping, you pass each and every string bean, corn kernel, and
pea to the plate of the person next to you, one-at-a-time, and only one
vegetable can move at a time.  If you even finished such a dinner, you
would never get anyone to show up at another.  And we haven't even
considered the cache-flooding implications.

Under PIPElines piping, whole plates of vegetables get passed around in the
familiar way.  The serving utensil the "cache loader".  Vegetables that you
don't want just stay in the serving bowl (slow memory or disk).

Bon appetit.  :-)

I hope this helps.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jun 13, 2018 at 10:07 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2018-06-13, at 07:18:40, Hobart Spitz wrote:
>
> > Cross posted to CMSTSO Pipelines and IBM-MAIN
> >
> > Someone shared with me a performance comparison between Pipelines vs.
> > native *nix commands, both on OPENVM.
> >
> > Under the OPENVM shell, this command ran 75 secs. with a 170M file in
> BFS:
> >
> > $ time cat m170file.data | wc -b
> >
> The "cat" is superfluous.  Why not just:
> > $ time   wc -b  m170file.data
>
> In fact, you were timing "cat", not "wc".
>
> > This command, also under OPENVM shell with the same file, ran 9 secs.:
> >
> > $ cms 'PIPE < /home/../m170file.data | count bytes | cons'
> >
> Won't Pipelines respect a path relative to current working directory?
> If not, shame on Pipelines.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: REXX calling bpxwunix when SIGNAL NOVALUE active

[Hobart Spitz]

Bruce;

I'm not sure whether you are asking for help, reporting a problem in a
sample, or offering a solution.

Since you haven't said which line failed, I'm just be guessing.

I think you need to quote StdErr. .  That should allow you to turn NOVALUE
back on.  I prefer to use it most of the time also.

My typical NOVALUE handler looks like this:





*novalue:say condition() condition("c") condition("d") "in line"
sigl"."parse source Sourcesay Source /* in case we are a few levels down in
external modules */exit -889*


I'd also recommend against TRACE OFF.  A typo can turn a REXX instruction
into a host command, and those problem can be hard to find.  (The proper
way to write TRACE is to omit the quotes; they imply VALUE, which takes a
few extra machine instructions.

Seymour, your suggestion is good.  If anything is wrong with REXX, it's
that it's such an easy language to write, people just jump in without
really understanding it.


OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jun 13, 2018 at 2:18 PM, Seymour J Metz  wrote:

> IMHO examples of REXX calls in any documentation should include both
> quoted stem names and variable containing the stem name, with appropriate
> comments. The descriptions should make it clear that normal REXX expression
> syntax applies, and the manuals should not make incorrect statements in the
> name of simplicity.
>
> FWIW, similar considerations apply to descriptions of the JCL for various
> programs; all too many manuals make incorrect statements in an effort to
> avoid either an accurate description or a reference to the JCL Reference
> manual.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Peter Hunkeler 
> Sent: Wednesday, June 13, 2018 9:00 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: AW: REXX calling bpxwunix when SIGNAL NOVALUE active
>
> >call bpxwunix cmd,"unsorted_data.","sorted_data.",stderr.
>
>
> The FM manual describes the parameters to be "the name of a compound
> variable". If you don't quote, REXX will try to dereference the variables,
> does not find them, and raises NOVALUE if activated. If not, those which
> were initialized (unsorted_data & sorted_data) are replace by a blank.
>
>
> I think the examples in the doc should be updated to quote any and all of
> the parameters which denote a stem variable.
> --
> Peter Hunkeler
>
> --
> 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

PIPElines vs. *nix

[Hobart Spitz]

Cross posted to CMSTSO Pipelines and IBM-MAIN

Someone shared with me a performance comparison between Pipelines vs.
native *nix commands, both on OPENVM.

Under the OPENVM shell, this command ran 75 secs. with a 170M file in BFS:

$ time cat m170file.data | wc -b


This command, also under OPENVM shell with the same file, ran 9 secs.:

$ cms 'PIPE < /home/../m170file.data | count bytes | cons'

Unfortunately, the person who sent this to me wasn't in a position to spent
any more time or resources on this, so I invite any one inclined to run a
similar comparison and post the results.

You may need something like this to avoid an abend depending on your system:

$ cms 'pipe filedesc 0 | count bytes | cons' < m170.data


Under OPENMVS, e.g., try something like:

$ tso 'PIPE < /home/../m170file.data | count bytes | cons

(Caution, I have not used OPENMVS/USS, so the syntax could be wrong.)

MVSers who don't have PIPElines, and VMers who want to, can try comparing
*nix equivalents to REXX using LINEIN() if you have it, or EXECIO * if you
don't.  This will tell us if Pipelines' design is a bigger contributor to
efficiency, or if it is the superiority of record-orientation vs.
character-orientation.

I recommend using RITA to get stage level statistics.  I suspect that
scanning for CR/LF is more expensive than counting bytes in PIPElines,
while the cost might be similar in *nix.

Some variations you may want to try:

   - Count lines and/or words.
   - Try different mainframe *nix version.
   - Add more filters.
   - Add filters that drop and/or add records.
   - Add some filters that change records.
   - Use file(s) already in the CMS/MVS file systems.  The 

Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

Lionel:

You are so right.  That's why it needs to be in the base.

(There are sites that still have it.)

Ok, people!!!  Go out there and rattle some cages!!!  Your boss, your data
center manager, you sales rep., your SHARE rep., your neighbor's dog, and
anyone else you can think of.  (Skip your manager and/or the dog if they
bite.  :-)  )

LET'S GET PIPELINES IN THE Z/OS BASE!!!

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 11:01 AM, Dyck, Lionel B. (TRA) <lionel.d...@va.gov>
wrote:

> Ask your friendly IBM rep, or search the IBM site, and you won't find it.
> It may be there but it isn't obvious and unless it is integrated it won't
> be exploited by ISVs (or IBM).
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hobart Spitz
> Sent: Friday, May 11, 2018 9:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
>
> It's already integrated.  It's just not in the z/OS base.  And you have to
> pay extra.
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Fri, May 11, 2018 at 10:54 AM, Dyck, Lionel B. (TRA) <
> lionel.d...@va.gov>
> wrote:
>
> > PIPES - it would be very nice if IBM were to just integrate PIPES into
> > TSO/REXX and then we can move on and make z/OS an even better platform
> for
> > the future.
> >
> > 
> --
> > Lionel B. Dyck (Contractor)  <
> > Mainframe Systems Programmer – RavenTek Solution Partners
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Hobart Spitz
> > Sent: Friday, May 11, 2018 9:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
> >
> > "pipe listpds" dsn "| stem members."
> >
> > OREXXMan
> > JCL is the buggy whip of 21st century computing.
> > We want Pipelines in the z/OS base.
> >
> > On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo <cvitu...@hughes.net>
> > wrote:
> >
> > > outrap with LISTD works well
> > > soemthing like this works well
> > >
> > >
> > >
> > > X = Listdsi(DSN 'DIRECTORY NORECALL')
> > > If X=16 Then Do
> > > If SYSREASON = 9 Then Do
> > > Say '** Data set has been migrated .. Abort'
> > > Exit
> > > End
> > > If SYSREASON = 5 Then Do
> > > Say '** Data set not cataloged .. Abort'
> > > Exit
> > > End
> > > Else Do
> > > Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> > > Exit
> > > End
> > > End
> > >
> > >
> > > or even LM services ?
> > > a clist example
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> > > ISPEXEC CONTROL ERRORS RETURN
> > > CONTROL END(ENDO)
> > > ISPEXEC LMINIT DATASET('') +
> > > DATAID(PDS) ENQ(SHR) ORG(ORG)
> > > ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> > > SET  =
> > > GETMBR: +
> > > ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> > > SET  = 
> > > IF  = 0 THEN DO
> > > SET =()
> > > SET =(1:,)
> > > SET =
> > > ISPEXEC VPUT (MEMPGM)...
> > > and so on
> > >
> > >
> > >
> > > Carmen Vitullo
> > >
> > > - Original Message -
> > >
> > > From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Sent: Friday, May 11, 2018 7:56:24 AM
> > > Subject: Re: [TSO-REXX] Sdsf rexx
> > >
> > > OUTTRAP with LISTD dsname M ?
> > >
> > > I'm pretty sure others will have better suggestions.
> > >
> > > Mike Wawiorko
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of Barkow, Eileen
> > > Sent: 11 May 2018 13:42
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: [TSO-REXX] Sdsf rexx
> > >
> > >
> > >

Re: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

It's already integrated.  It's just not in the z/OS base.  And you have to
pay extra.

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 10:54 AM, Dyck, Lionel B. (TRA) <lionel.d...@va.gov>
wrote:

> PIPES - it would be very nice if IBM were to just integrate PIPES into
> TSO/REXX and then we can move on and make z/OS an even better platform for
> the future.
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hobart Spitz
> Sent: Friday, May 11, 2018 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: [TSO-REXX] Sdsf rexx
>
> "pipe listpds" dsn "| stem members."
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo <cvitu...@hughes.net>
> wrote:
>
> > outrap with LISTD works well
> > soemthing like this works well
> >
> >
> >
> > X = Listdsi(DSN 'DIRECTORY NORECALL')
> > If X=16 Then Do
> > If SYSREASON = 9 Then Do
> > Say '** Data set has been migrated .. Abort'
> > Exit
> > End
> > If SYSREASON = 5 Then Do
> > Say '** Data set not cataloged .. Abort'
> > Exit
> > End
> > Else Do
> > Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> > Exit
> > End
> > End
> >
> >
> > or even LM services ?
> > a clist example
> >
> >
> >
> >
> >
> >
> >
> > CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> > ISPEXEC CONTROL ERRORS RETURN
> > CONTROL END(ENDO)
> > ISPEXEC LMINIT DATASET('') +
> > DATAID(PDS) ENQ(SHR) ORG(ORG)
> > ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> > SET  =
> > GETMBR: +
> > ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> > SET  = 
> > IF  = 0 THEN DO
> > SET =()
> > SET =(1:,)
> > SET =
> > ISPEXEC VPUT (MEMPGM)...
> > and so on
> >
> >
> >
> > Carmen Vitullo
> >
> > - Original Message -
> >
> > From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Sent: Friday, May 11, 2018 7:56:24 AM
> > Subject: Re: [TSO-REXX] Sdsf rexx
> >
> > OUTTRAP with LISTD dsname M ?
> >
> > I'm pretty sure others will have better suggestions.
> >
> > Mike Wawiorko
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Barkow, Eileen
> > Sent: 11 May 2018 13:42
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [TSO-REXX] Sdsf rexx
> >
> >
> > ...
> > Is there any way to get the member names in a PDSE with REXX?
> > I need to extract the member names in a PDSE and plug them into a job
> > stream.
> >
> > ...
> >
> > This e-mail and any attachments are confidential and intended solely for
> > the addressee and may also be privileged or exempt from disclosure under
> > applicable law. If you are not the addressee, or have received this
> e-mail
> > in error, please notify the sender immediately, delete it from your
> system
> > and do not copy, disclose or otherwise act upon any part of this e-mail
> or
> > its attachments.
> > Internet communications are not guaranteed to be secure or virus-free.
> The
> > Barclays Group does not accept responsibility for any loss arising from
> > unauthorised access to, or interference with, any Internet communications
> > by any third party, or from the transmission of any viruses. Replies to
> > this e-mail may be monitored by the Barclays Group for operational or
> > business reasons.
> > Any opinion or other information in this e-mail or its attachments that
> > does not relate to the business of the Barclays Group is personal to the
> > sender and is not given or endorsed by the Barclays Group.
> > Barclays Services Limited provides support and administrative services
> > across Barclays group. Barclays Services Limited is an appointed
> > representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale
> > Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc
> are
> > authorised by the Prudential Regulation Authority and regulated by the
> > Financial Con

Re: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

"pipe listpds" dsn "| stem members."

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 9:00 AM, Carmen Vitullo  wrote:

> outrap with LISTD works well
> soemthing like this works well
>
>
>
> X = Listdsi(DSN 'DIRECTORY NORECALL')
> If X=16 Then Do
> If SYSREASON = 9 Then Do
> Say '** Data set has been migrated .. Abort'
> Exit
> End
> If SYSREASON = 5 Then Do
> Say '** Data set not cataloged .. Abort'
> Exit
> End
> Else Do
> Say '** Servere error in LISTDSI...Rc=16 - SYSREASON=' SYSREASON
> Exit
> End
> End
>
>
> or even LM services ?
> a clist example
>
>
>
>
>
>
>
> CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
> ISPEXEC CONTROL ERRORS RETURN
> CONTROL END(ENDO)
> ISPEXEC LMINIT DATASET('') +
> DATAID(PDS) ENQ(SHR) ORG(ORG)
> ISPEXEC LMOPEN DATAID() OPTION(INPUT)
> SET  =
> GETMBR: +
> ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMPGM)
> SET  = 
> IF  = 0 THEN DO
> SET =()
> SET =(1:,)
> SET =
> ISPEXEC VPUT (MEMPGM)...
> and so on
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Mike Wawiorko" <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, May 11, 2018 7:56:24 AM
> Subject: Re: [TSO-REXX] Sdsf rexx
>
> OUTTRAP with LISTD dsname M ?
>
> I'm pretty sure others will have better suggestions.
>
> Mike Wawiorko
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barkow, Eileen
> Sent: 11 May 2018 13:42
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [TSO-REXX] Sdsf rexx
>
>
> ...
> Is there any way to get the member names in a PDSE with REXX?
> I need to extract the member names in a PDSE and plug them into a job
> stream.
>
> ...
>
> This e-mail and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this e-mail
> in error, please notify the sender immediately, delete it from your system
> and do not copy, disclose or otherwise act upon any part of this e-mail or
> its attachments.
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays Group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any Internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this e-mail may be monitored by the Barclays Group for operational or
> business reasons.
> Any opinion or other information in this e-mail or its attachments that
> does not relate to the business of the Barclays Group is personal to the
> sender and is not given or endorsed by the Barclays Group.
> Barclays Services Limited provides support and administrative services
> across Barclays group. Barclays Services Limited is an appointed
> representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale
> Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are
> authorised by the Prudential Regulation Authority and regulated by the
> Financial Conduct Authority and the Prudential Regulation Authority.
> Clydesdale Financial Services Limited is authorised and regulated by the
> Financial Conduct Authority.
>
> --
> 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

[Hobart Spitz]

I think the real downside is cost of going to a new "platform", even tho
it's still within z/OS.  That means training,
development/conversionj/implementation, testing, deployment, new operations
procedures and training, maintenance, etc.

Add in the general problem of rewriting any software in its entirety.:

   - You can miss important/heavily-used features.
   - You can waste resources on new features that are not really needed or
   cost-effective.
   - You can introduce new bugs.
   - If you change the UI, the users will hate you, your guts, and every
   member of your family, because they will have to spend time learning
   something entirely new when they already knew the old system well.

Don't do it!!!  (Unless you really. really, really have to.)

Second to that are the deficient string and file models:

   - There are separate techniques for processing text, on one hand, and
   binary data on the other.  (z/OS, z/VM have no such requirement.)
   - Using the wrong technique can break data structures badly, as can
   inadvertent/erroneous embedding of binary data in text strings/files.
   (z/OS, z/VM have not such problem.)
   - One of *nix's most powerful features, piping, is crippled because most
   filters are text oriented and cannot process binary data.  Dispatching is
   mostly at the discretion of the operating system.  (Dispatching generally
   deterministic, ands streams can be split and rejoined, because record
   movement is generally defined.)
   - When processing text strings or files, having to scan for the string
   terminator or CR/LF, results in performance-killing working-set/cache
   flooding.  (Pipelines processes records not characters, and unneeded
   pages/cache-lines never have to be staged in.)

The *nix string and file models were great for slow PDP-11s and the like,
but make no sense on modern hardware.

Fixing the 44 character limit?  Do-able:  New control blocks, VTOC records,
catalog entries, JCL parameters, etc.  Much less painful than going to USS.

Just my buck three eighty.  (Pat R., are you out there?)

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Fri, May 11, 2018 at 10:06 AM, Charles Mills  wrote:

> Oh for gosh sakes! Every operating system is different. There is no
> eleventh commandment "filenames shall be 44 uppercase characters" that UNIX
> violated. Tell him a foolish consistency is the hobgoblin of little minds.
> Or that the inability to learn new things is a sign of old age.
>
> Or point out that z/OS is case-dependent. Don't think so? Try referencing
> 'sys1.maclib'.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Friday, May 11, 2018 6:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the
> Devil?
>
> OK, I bet I got your attention on that {grin}.
>
> But, seriously, I am wondering what the "person in the trenches" thinks
> about the increasing use of UNIX files and commands becoming more prevalent
> on z/OS. I am basically asking because my manager absolutely despises UNIX
> files. And hates the current maintenance processes from IBM and CA which
> force him to use it. One of his reasons is the case sensitivity of the UNIX
> file names. Of course, like most people in the world, his mind has been
> corrupted by the case insensitivity of Windows. As well as the very
> prevalent use of space characters in Windows file and directory names. This
> case sensitivity of names may be another reason why new people, likewise
> corrupted by Windows, will take an instant dislike for z/OS. OTOH, Linux
> might find it minimally interesting. And maybe even quite interesting, if
> IBM would adopt and maintain a port of the GNU infrastructure software.
>
> What I think, and I am likely stupid on this, is that the Apple HFS+
> approach might work. Just like, at present, when you create a zFS
> filesystem, the default for filenames on an HFS+ filesystem are, like
> Windows, case _in_sensitive. However, when an HFS+ filesystem is
> initialized, it can be set as "case sensitive". This is done on a
> filesystem-by-filesystem basis. What might be nice is to enhance(?) zFS so
> that it can be made case _in_sensitive (reverse default of HFS+). This
> might be very helpful for "naive" z/OS UNIX users. Put the ${HOME}
> directory (usually /u) under automount and set the parameters so that when
> automount creates & initializes a ${HOME} directory, it is
> case-insensitive. And, of course, they should be a way to "flip the switch"
> back an forth between case sensitivity and case insensitivity. Of course,
> the "make insensitive" conversion will need to check & abort if there two
> names in the same directory which are equivalent when case is ignored. I
> would think this would be simple; check for possible problems and if none,
> just flip the switch 

Re: [TSO-REXX] Sdsf rexx

[Hobart Spitz]

For those who may not be aware, SIGNAL is *not* a GOTO.

I counted 18 SIGNALs, and only 1 CALL.  Many of the SIGNALs here seem to
have been better done with DO...END.

In the words of TRL, SIGNAL terminates "all active pending DO loops, DO
groups, IF constructs, SELECT construct, and INTERPRET instructions" such
that "they cannot be reactivated".

With apologies to Eileen and/or the original coder:  Not being aware of
that fact has apparently let the coder down into a "black hole".  I hope my
post can encourage anyone who thinks this is the way to write REXX, to do
better, and that anyone who copies sees this code not use it as an model
for anything.

This is not an issue of style, pedantics, or personal preference.  Using
SIGNAL this way is even more of a barrier to maintainable, readable code
than a GOTO.  For more information, see the appropriate resources.

It should not even be necessary to say it, but I vote for SIGNAL-less
coding (except for SIGNAL ON/OFF, and where actually necessary.)

OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Tue, May 8, 2018 at 4:18 PM, Barkow, Eileen 
wrote:

> This is a SDSF/REXX clist that extracts sysout datasets with names S*
> on the ST queue and archives them to datatsets.
> It can be adapted to extract datasets with other criteria.
>
> /* REXX */
> TRACE e
> /*ISFTRACE="ON" */
> /*ISFTRMASK="ALL" */
> PROFILE NOPREFIX
> rc=isfcalls('ON')
> PARSE ARG p1 p2 p3
> IF p1 ="" THEN DO
> ISFPREFIX = 'CICS*'
> END
> ELSE
> DO
> ISFPREFIX = p1
> END
> IF p2 ="" THEN DO
> HLQ   = 'XCICSR.'
> END
> ELSE
> DO
> HLQ   = p2||'.'
> END
> IF p3 ="" THEN DO
> ISFPRTVOLSER = 'W1STG1'
> END
> ELSE
> DO
> ISFPRTVOLSER = 'W1STG1'
> END
> ISFOWNER  = '*'
> ISFFILTER = 'QUEUE PRINT'
> CICSJOBN = ISFPREFIX
> ASTPO = POS('*',CICSJOBN)
> if ASTPO ^= 0 then
> do
> ASTPO = ASTPO - 1
> CICSJOBN = SUBSTR(CICSJOBN,1,ASTPO)
> end
> /* Access the ST panel. A TOKEN variable is */
> /* created for each row which is subsequently */
> /* needed to perform actions */
> Address SDSF "ISFEXEC ST"
> lrc=rc
> call msgrtn
> /* Find a job starting with CICSjobn and list data sets */
> /* rexx */
> numrows=isfrows
> if isfrows<=0 then exit
> six = 1
> setix:
> if six > numrows then signal endit
> do ix=six to numrows /* Loop for all rows returned */
> if pos(CICSJOBN,JNAME.ix) = 1 then /* If this is desired row */
> do
> /* Issue the ? action character for the job */
> /* identified by the token variable. Note */
> /* the token must be enclosed in single quotes */
> /* Use the prefix option to ensure unique */
> /* variables are created, beginning with JDS_ */
> Address SDSF "ISFACT ST TOKEN('"TOKEN.ix"') PARM(NP ?)",
> "("prefix JDS_
> if JDS_DDNAME.0 = 0 then exit
> lrc=rc
> if lrc<>0 then
> exit 20
> startjx = 2
> jf = 0
> IF JDS_DDNAME.0 =1 then signal SETJL1
> /***if 2 jesmsglgs use 2nd  */
> do jf = 2 to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jf,1,4) = 'JESM' then signal GETJLINF
> end
> SETJL1:
> startjx = 1
> GETJLINF:
> do jx=startjx to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jx,1,4) = 'JESM' then signal GOTJESM
> end
> signal nextjob
> lrc=rc
> call msgrtn
> if lrc<>0 then do
> exit 20
> GOTJESM:
> sjx= jx  /*save position of current ddname entry */
> Address SDSF "ISFACT ST TOKEN('"JDS_TOKEN.jx"') PARM(NP SA)"
> lc = rc
> k = isfddname.0
> /***READ 3RD   RECORD TO GET STARTED TASK NUMBER  */
>  "EXECIO 1  DISKR " isfddname.k 3 " (STEM STCREC. "
>  lrc = rc
>  If lrc ^= 0 THEN SIGNAL NOSTC
>  PARSE VAR STCREC.1  S1 STRNUM S3
>  STRNUM = STRIP(STRNUM)
>  STCNUM = SUBSTR(STRNUM,1,8)
> /***READ 4TH   RECORD TO GET JOBNAME  */
>  "EXECIO 1  DISKR " isfddname.k 4 " (STEM STCREC. "
>  PARSE VAR STCREC.1  X1 X2 X3 JN XX
>  JN = STRIP(JN)
>  "EXECIO 0  DISKR " isfddname.k  " (finis"
>  sjx = sjx+1
>  signal setjx
> setjx:
> IF sjx >  JDS_DDNAME.0 then signal nextjob
> do jx=sjx to JDS_DDNAME.0 /* loop for all rows returned */
> IF SUBSTR(JDS_DDNAME.jx,1,4) = 'S000' then signal GOTSTAT
> end
> signal NOSTAT
> NOSTC:
> EXIT
> NOSTAT:
> six =six+1
> signal setix
> EXIT
> GOTSTAT:
> Address SDSF "ISFACT ST TOKEN('"JDS_TOKEN.jx"') PARM(NP SA)",
> "("prefix SDS_
> lc = rc
> k = isfddname.0
> STATIN = isfddname.k
> STATDS = isfdsname.k
> /***READ FIRST RECORD TO GET INFO TO WRITE OUTPUT DATAST  */
>  "EXECIO *  DISKR " isfddname.k " (STEM REC. "
>  lrc = rc
>  If lrc ^= 0 THEN SIGNAL noapp
>  PARSE VAR REC.1  A  A2 A3 A4 A5 JN A7 JD A9 JT A6
>  IF SUBSTR(A,1,4) = '1App' THEN SIGNAL GOTAPP
> noapp:
>  EXIT
> GOTAPP:
>  JDATE= ".D"||SUBSTR(JD,1,2)||SUBSTR(JD,4,2)||SUBSTR(JD,9,2)
>  JTIME= ".T"||SUBSTR(JT,1,2)||SUBSTR(JT,4,2)||SUBSTR(JT,7,2)
>  STPNUM = "."||STCNUM
>  "FREE FILE(STATOUT)"
>  /*OUTDS = "XCICS."||JN||JDATE||STPNUM||JTIME */
>  OUTDS =  HLQ||JN||JDATE||STPNUM||JTIME
> /*if SYSDSN(OUTDS) ^= 'OK' */
> /* THEN SIGNAL 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Hobart Spitz]

Somewhere, maybe in a different branch of this topic, there was a
discussion about the pros and cons of replacing Assembler with Java.  I
apologize for posting here if it's the wrong place, but I can't seem to
find the original discussion, and I have a question that seems relevant and
important, IMHO.

That's said, I can answer the question, for C/C++, as follows.  (I pose the
question for Java, below.)

*With the *nix/C record and string models, there are these issues:*

   1. Errant/unexpected/unintended pieces of binary data in a text
   file/string can break something.
   2. Separate functions/methods/techniques must be used to manipulate text
   files/strings versus binary files/string. You *must* know what you are
   dealing with up front, and/or somehow code logic for both. (I'm not sure
   the latter is possible in the general case.)
   3. Even with *nix/C oriented machine instructions, the need to inspect
   all characters up to a target point results in performance killing cache
   flooding.
   4. C++ does garbage collection resulting in "pauses" in forward
   progress, and working set, caching, and CPU spikes, among other things.

Let's call these attributes fragility, productivity, and efficiency,
respectively, for the convenience convenience.  C has issue with these
characteristics.

As most of the readers here know, mainframe style records and strings do
not suffer from these limitation.  When the length of a string/record is
known external to the data contents, you can manipulate any platform-native
data in z/OS, z/VM without it breaking due to something in the data, you
write the same code regardless of what you are dealing with, and, less
obviously, any activity that skips a cache can avoid a cache line promotion
saving processor resources.

So, my "burning" question for Java is, which, if any, of these above issues
(data fragility, coding productivity, efficiency, and garbage collections)
does Java share with C/C++.

If Java suffers from all or most of the issues, then I would say replacing
Assembler with Java is pretty much out of the question.  On the other hand,
if Java suffers few or none of the above issues, it might be viable to
replace Assembler with Java (ignoring other issues, like cost, testing,
compatibility, data porting, etc.)

To sum up:  Does Java use a similar record/string model to that of C/C++,
and does it do garbage collection similarly.

Thanks in advance for satisfying my curiosity.











OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Sat, Apr 21, 2018 at 12:29 PM, Barry Merrill  wrote:

> In 1975 there was a BOF, Bird's of a Feather Session on Year 2000 Concerns
> at the SPRING SHARE meeting, as I recall.  BOF's were spontaneous evening
> meetings posted/scheduled usually that day.
>
> Barry
>
>
> Herbert W. “Barry” Merrill, PhD
> President-Programmer
> Merrill Consultants
> MXG Software
> 10717 Cromwell Drive
> Dallas, TX 75229
> www.mxg.com
> ba...@mxg.com
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, April 20, 2018 5:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> Hardware (nextgov.com)
>
> On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
> >
> >I agree with both you and Gil.  But, how many programmers in the 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones were,
> but what about the other 80%?
> >
> >and, Y2K came off without a hitch...(FSVO - "hitch")
>
>
> >-Original Message-
> >From: IBM Mainframe Discussion List Porowski, Kenneth
> >Sent: Friday, April 20, 2018 1:20 PM
> >
> >That was due to lack of foresight by the programmer not due to the age of
> the system.
> >
> True in the sense that it affected one-year-old computers as much as older
> computers running th same software.
>
> I'm disappointed that this thread has so much focused on Y2K which I meant
> only as an extreme example.  Things change.  Y2K was only more precisely
> forseeable.
>
> Increasing complexity of the tax code requires new logic.  Inflation and
> rate escalation may have made some data fields inadequate in size.
> E-filing requires network interfaces and code to support them and causes
> the one-day spike in workload.  I gather from these fora that COBOL is not
> comfortably suited to TCP/IP.  IBM bet that SNA/VTAM could crush TCP/IP and
> customers were the losers.  IBM bet that EBCDIC could crush ASCII and
> customers were the losers.  And customers bet that COBOL skills would
> remain in the forefront of availability.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 

Re: Many arguments to a Rexx function call

[Hobart Spitz]

Jantje wrote:

>Commas at the beginning or at the end makes no difference... :

As far as the language syntax goes, this is a true statement.  As far as
maintainability goes, that is another story.  When I continue a statement,
I prefer to break between arguments, as there is typically less of language
semantic connection between arguments than within argument.

Assuming we're not talking about quoted commas, which are entirely
different animals, I respectfully disagree for these reasons:

   1. Two commas at the end of a line are clearly the end of an argument
   within a continued statement.  A single comma at the end of a line is a
   simple continuation.
   2. Putting the argument delimiting comma at the beginning of a line
   means that you have to remember to look at the beginning of the next line.
   That's easy to forget/miss if you are skimming.
   3. If you rearrange a statement, you can replace a line without a
   leading comma with one that has such, and vice versa, with avoidable and/or
   disastrous results.
   4. To the best of my knowledge, most experienced REXX programmer's put
   an argument delimiting comma at the end of the line (followed by the
   continuation comma).  The more code you write (in a language) the more you
   recognize which subtle things are more error prone and which are less so,
   in that language.

Just my 2 cents.


OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Mon, Apr 9, 2018 at 9:37 AM, Phil Smith III  wrote:

> Jantje wrote:
>
> >Commas at the beginning or at the end makes no difference... :
>
>
>
> Right, nobody thought it would. That was a style point.
>
>
>
> If your function call is still failing as you indicate:
>
>
>
> >87 +++
> >RS=ALERTSN(SEV,TYPENAME,ELEMENT,DESC,STATUS,STSDESC,,
> SUBSRC,SOURCE,LOCATION
> ,SYSTYPE,PLTFTYPE,IMPACT,HOST,,MONENV,RESOURC
>
> >E,EXTRINFO,ACTIVE,CLOSING,FTPERR,,APPLTYPE,APPLNAME,UNIQUE)
>
> >IRX0040I Error running ALERTSNB, line 87: Incorrect call to routine
>
>
>
> Then you're apparently calling it wrong. I see double commas in the error
> output: that suggests you have doubled commas in the wrong place, because
> if
> they're seen as continuation, ALERTSN won't see them at all.
>
>
>
> Run it with TRACE I and see what it's getting.
>
>
> --
> 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: Passing data from step-to-step in single job using memory??

[Hobart Spitz]

Pipe stepa ! stepb

(No pipe char on my phone)

On 4 Dec 2017 10:20 am, "Kirk Wolf"  wrote:

> Right.  Its often a good idea to set up alternate temp filesystems - either
> TFS or ZFS.
> The $TMPDIR environment variable can be set to point so that most commands
> will use this rather than /tmp.
> Use skulker, mount with "FSFULL" and use auto-ops to assist with
> management.
>
> Here is some documentation on our website for other best practices for
> managing temp filesystems on z/OS:
> https://dovetail.com/docs/pt-quick-inst/pto-inst-tmp.html
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> --
> 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.

[Hobart Spitz]

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 

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

[Hobart Spitz]

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
>
> > On 17 Nov 2017, at 19:40, Hobart Spitz <orexx...@gmail.com> wrote:
> >
> > 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 <
> jesse1.robin...@sce.com>
> > wrote:
> >
> >> 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
> >> robin...@sce.com
> >>
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of Farley, Peter x23353
> >> Sent: Friday, November 17, 2017 11:07 AM
> >> To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of Jesse 1 Robinson
> >> Sent: Friday, November 17, 2017 1:26 PM
> >> To: IBM-MAIN@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
> >> robin...@sce.com
> >>
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of Nims,Alva John (Al)
> >> Sent: Friday, November 17, 2017 7:09 AM
> >> To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >
> >
> > --
> > OREXXMan
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
OREXXMan

--
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.

[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 
wrote:

> 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
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Friday, November 17, 2017 11:07 AM
> To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Friday, November 17, 2017 1:26 PM
> To: IBM-MAIN@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
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nims,Alva John (Al)
> Sent: Friday, November 17, 2017 7:09 AM
> To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
OREXXMan

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