EXECIO * DISKR SYSPRINT

Bob Bridges

unread,

May 21, 2021, 3:26:27 PM5/21/21

to

I have a commercial utility that was designed to run in batch, but it runs
fast and I plan to run it often so I'm writing a REXX to invoke it in the
foreground. After the program has run, I have to grab SYSPRINT and display
its contents in ISPF View.

I have an external REXX routine I've been using for decades that reads a DD
or DS and puts its contents in the queue, so I use it to grab SYSPRINT:

call execiost 'SYSPRINT'

But whether it's because SYSPRINT is different, or for some other reason,
EXECIOST pauses at this point looking for more input from the terminal. I
have to type '/*' manually to get it to recognize the end of file, at which
point it returns to my program and finishes correctly.

So now I'm thinking about ways to run this without having to type '/*', and
so far the only thing that occurs to me is to create a DS containing '/*'
and concatenate it to SYSPRINT before trying to read it. But that's silly;
surely that's going around my elbow to get to my thumb (so to speak).
Someone tell me the more obvious way to do this, please, because it's
escaping me.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* The results are astounding. I've seen the before and after photographs,
and let me tell you, in just a few weeks the women go from having tired,
sagging, wrinkly skin to having a new haircut and expert makeup. -W Bruce
Cameron, 2010 */

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

Bob Bridges

unread,

May 21, 2021, 3:26:47 PM5/21/21

to

Never mind. It isn't while reading SYSPRINT that it's looking for more
records, it's while running the program. I've put '/*' at the end of the
input DD (//INCLUDE) and it's still waiting; I now suspect the program is
trying to read from SYSIN. I'll keep playing with it.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* A ship in harbour is safe. But that's not what a ship is for. */

-----Original Message-----
From: Bob Bridges <robhb...@gmail.com>
Sent: Friday, May 21, 2021 14:49

I have a commercial utility that was designed to run in batch, but it runs
fast and I plan to run it often so I'm writing a REXX to invoke it in the
foreground. After the program has run, I have to grab SYSPRINT and display
its contents in ISPF View.

I have an external REXX routine I've been using for decades that reads a DD
or DS and puts its contents in the queue, so I use it to grab SYSPRINT:

call execiost 'SYSPRINT'

But whether it's because SYSPRINT is different, or for some other reason,
EXECIOST pauses at this point looking for more input from the terminal. I
have to type '/*' manually to get it to recognize the end of file, at which
point it returns to my program and finishes correctly.

So now I'm thinking about ways to run this without having to type '/*', and
so far the only thing that occurs to me is to create a DS containing '/*'
and concatenate it to SYSPRINT before trying to read it. But that's silly;
surely that's going around my elbow to get to my thumb (so to speak).
Someone tell me the more obvious way to do this, please, because it's
escaping me.

Itschak Mugzach

unread,

May 21, 2021, 3:40:36 PM5/21/21

to

Push end to the stack

בתאריך יום ו׳, 21 במאי 2021 ב-22:27 מאת Bob Bridges <robhb...@gmail.com>:

ITschak Mugzach

unread,

May 21, 2021, 3:41:26 PM5/21/21

to

If this the problem. Use queue “end”.

בתאריך יום ו׳, 21 במאי 2021 ב-22:27 מאת Bob Bridges <robhb...@gmail.com>:

--
ITschak Mugzach

*|** IronSphere Platform* *|* *Information Security Continuous Monitoring

for z/OS, x/Linux & IBM I **| z/VM coming soon *

Seymour J Metz

unread,

May 21, 2021, 3:42:03 PM5/21/21

to

A normal logon proc allocates SYSPRINT to TERM, and the access method treats /* as an end of file. How about showing the relevant JCL?

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

________________________________________
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Bob Bridges <robhb...@GMAIL.COM>
Sent: Friday, May 21, 2021 2:48 PM
To: TSO-...@VM.MARIST.EDU
Subject: [TSO-REXX] EXECIO * DISKR SYSPRINT

Jeremy Nicoll

unread,

May 21, 2021, 3:42:40 PM5/21/21

to

On Fri, 21 May 2021, at 19:48, Bob Bridges wrote:

> I have an external REXX routine I've been using for decades that reads a DD
> or DS and puts its contents in the queue, so I use it to grab SYSPRINT:

Why don't you view/browse the contents of sysprint directly? With code like

address ispexec ; "control errors return" ; "control display refresh"
"lminit dataid(did) ddname(sysprint) enq(shr)"
"browse dataid("did")"
"lmfree dataid("did")"

--
Jeremy Nicoll - my opinions are my own.

Paul Gilmartin

unread,

May 21, 2021, 4:00:58 PM5/21/21

to

On 2021-05-21, at 13:41:23, Seymour J Metz wrote:
>
> A normal logon proc allocates SYSPRINT to TERM, and the access method treats /* as an end of file. How about showing the relevant JCL?
>

Please. Also show a fragment of Rexx.

I suspect you're reading with PARSE PULL. AFAIK, there's no
way to indicate end-of-input to PULL. None of "end", "/*", nor ""
suffices. The program using PULL just loops endlessly.

Can you not just read SYSPRINT directly with EXECIO, omitting EXECIOST?

> _______________________________________
> From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Bob Bridges

> Sent: Friday, May 21, 2021 2:48 PM
> To: TSO-...@VM.MARIST.EDU
> Subject: [TSO-REXX] EXECIO * DISKR SYSPRINT
>
> I have a commercial utility that was designed to run in batch, but it runs
> fast and I plan to run it often so I'm writing a REXX to invoke it in the
> foreground. After the program has run, I have to grab SYSPRINT and display
> its contents in ISPF View.
>
> I have an external REXX routine I've been using for decades that reads a DD
> or DS and puts its contents in the queue, so I use it to grab SYSPRINT:
>
> call execiost 'SYSPRINT'

> ...

-- gil

Paul Gilmartin

unread,

May 21, 2021, 4:05:06 PM5/21/21

to

On 2021-05-21, at 13:40:00, Itschak Mugzach wrote:
>
> Push end to the stack
>

ITYM QUEUE. Does that work? What if a programmer's data contains
a line "end", common in programming languages such as C and Rexx.

-- gil

Willy Jensen

unread,

May 21, 2021, 4:34:55 PM5/21/21

to

After the program has terminated, try to FREE SYSPRINT. Perhaps the program
don't close SYSPRINT properly? Or run the program, do TSO ISRDDN and try to
browse SYSPRINT.

-----Oprindelig meddelelse-----
Fra: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> På vegne af Bob
Bridges
Sendt: 21. maj 2021 20:49
Til: TSO-...@VM.MARIST.EDU
Emne: [TSO-REXX] EXECIO * DISKR SYSPRINT

--
Denne mail er kontrolleret for vira af AVG.
http://www.avg.com

Bob Bridges

unread,

May 21, 2021, 4:35:58 PM5/21/21

to

I'm not sure what you're thinking, Itzchak. Why would I want the program to see a record saying "end"?

I tried it anyway, just to see what would happen. It read "end" and copied it to the beginning of the SYSPRINT output, but I still had to type '/*' manually when the REXX ran the program (whose name, by the way, is AT6#RPT).

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Programmer: We've all heard that the Inuits have 22 different words for snow...the English-speaking sailor has about the same number for "rope" and the carpenter considerably more for "piece of wood"; all three of them have special distinctions for the things that are important in their everyday lives. (And the programmer for "element of storage", come to think of it.)
Screenwriter: Actually, screenwriters have 92 words for "gratuitously sexy."
-From an email conversation, summer 1998 */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of ITschak Mugzach
Sent: Friday, May 21, 2021 15:41

If this the problem. Use queue “end”.

--- בתאריך יום ו׳, 21 במאי 2021 ב-22:27 מאת Bob Bridges <robhb...@gmail.com>:

> Never mind. It isn't while reading SYSPRINT that it's looking for
> more records, it's while running the program. I've put '/*' at the
> end of the input DD (//INCLUDE) and it's still waiting; I now suspect
> the program is trying to read from SYSIN. I'll keep playing with it.
>

ITschak Mugzach

unread,

May 21, 2021, 4:40:27 PM5/21/21

to

Bob, when the program ends, does the Rexx get control, or if hit enter and
the cursor moves to a new line?
Whether is is end or /*, in the case the program still waits for the input
end of file , you can use the queue command to feed the input before
calling the program.

בתאריך יום ו׳, 21 במאי 2021 ב-23:36 מאת Bob Bridges <robhb...@gmail.com>:

--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *

Paul Gilmartin

unread,

May 21, 2021, 4:44:03 PM5/21/21

to

On 2021-05-21, at 14:35:46, Bob Bridges wrote:
>
> I'm not sure what you're thinking, Itzchak. Why would I want the program to see a record saying "end"?
>
> I tried it anyway, just to see what would happen. It read "end" and copied it to the beginning of the SYSPRINT output, but I still had to type '/*' manually when the REXX ran the program (whose name, by the way, is AT6#RPT).
>

Can you show your code, JCL + Rexx, so people trying to help you
needn't guess?

-- gil

Bob Bridges

unread,

May 21, 2021, 5:26:32 PM5/21/21

to

After the below email I sent a followup explaining that I'd misunderstood
the problem: It isn't while reading SYSPRINT that the hold-up occurs, but
while running the program. Between these two statements:

address LINKMVS 'AT6#RPT PARM'
call execiost 'SYSPRINT'

...is where execution stops and I have to type '/*' to continue - after
calling AT6#RPT and before it starts EXECIOST. (EXECIOST is a routine I
wrote decades ago to read the contents of a DD or a DS onto the stack.) So
AT6#RPT is trying to read some input, and REXX is trying to supply it from
the terminal.

I tried adding '/*' to the end of the only DD I thought it was reading, but
it doesn't change anything (except that it sees '/*' in the input and
reports on it in the output). And I tried pushing or queueing '/*' before
calling AT6#RPT, and all it did was copy it to the output — but I still had
to type '/*' when running my REXX.

So I'm now guessing AT6#RPT is trying to read some other DD, too, probably
//SYSIN. Maybe I need to put '/*' into SYSIN before calling AT6#RPT.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* It said "Insert disk #3", but only two will fit. */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Seymour
J Metz
Sent: Friday, May 21, 2021 15:41

A normal logon proc allocates SYSPRINT to TERM, and the access method treats
/* as an end of file. How about showing the relevant JCL?

-----Oprindelig meddelelse-----
Fra: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> På vegne af Bob
Bridges
Sendt: 21. maj 2021 20:49

I have a commercial utility that was designed to run in batch, but it runs
fast and I plan to run it often so I'm writing a REXX to invoke it in the
foreground. After the program has run, I have to grab SYSPRINT and display
its contents in ISPF View.

I have an external REXX routine I've been using for decades that reads a DD
or DS and puts its contents in the queue, so I use it to grab SYSPRINT:

call execiost 'SYSPRINT'

But whether it's because SYSPRINT is different, or for some other reason,
EXECIOST pauses at this point looking for more input from the terminal. I
have to type '/*' manually to get it to recognize the end of file, at which
point it returns to my program and finishes correctly.

So now I'm thinking about ways to run this without having to type '/*', and
so far the only thing that occurs to me is to create a DS containing '/*'
and concatenate it to SYSPRINT before trying to read it. But that's silly;
surely that's going around my elbow to get to my thumb (so to speak).
Someone tell me the more obvious way to do this, please, because it's
escaping me.

Bob Bridges

unread,

May 21, 2021, 5:33:44 PM5/21/21

to

Yes, that's what I'm doing. That is:

call execiost 'SYSPRINT'

...copies the contents of a DD into the stack, and:

call viewq

displays the contents of the stack in ISPF VIEW.

Oh, I see; not quite as direct as your method. But easier, because I have
EXECIOST and VIEWQ already prepared - I've been using them for decades - so
the job gets done in two short statements instead of six longer ones.

At any rate, that's a side issue; as I said in a followup post, it turns out
SYSPRINT isn't the problem after all; the program itself is looking for some
sort of EOF marker before it consents to return control to my REXX. I don't
know what file it's trying to read, but I suspect //SYSIN.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* If you read the New Testament with an Old-Covenant heart, it will be just
Law to you. Likewise, if you read the Old Testament with a New-Covenant
heart, you will see Christ in all of it. -Rick Joyner, "The Apostolic
Ministry" */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Jeremy
Nicoll
Sent: Friday, May 21, 2021 15:42

Why don't you view/browse the contents of sysprint directly? With code like

address ispexec ; "control errors return" ; "control display refresh"
"lminit dataid(did) ddname(sysprint) enq(shr)"
"browse dataid("did")"
"lmfree dataid("did")"

--- On Fri, 21 May 2021, at 19:48, Bob Bridges wrote:
> I have an external REXX routine I've been using for decades that reads
> a DD or DS and puts its contents in the queue, so I use it to grab
SYSPRINT:

Bob Bridges

unread,

May 21, 2021, 5:43:40 PM5/21/21

to

The problem seems to be that the program doesn't end; it keeps looking for input from the stack (ie from the terminal). When I hit <Enter>, or type in something else and then hit <Enter>, the cursor moves to the next line. Only when I type '/*' and hit <Enter> does the program return control to my REXX, which then displays the contents of //SYSPRINT.

As I said below, I tried adding a record "end" or "/*" to the stack before calling the program. The program still required me to type '/*' manually before it would return control to my REXX. The extra 'end' or '/*' appeared in the output, so apparently the program saw it, but did not regard it as a valid EOF marker.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Do you know what constitutes a "hate crime"? Put your thinking caps on. What tools do we need to determine whether a crime was motivated by hate or prejudice? Answer: We need thought police. -from "See, I Told You So" by Rush Limbaugh */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of ITschak Mugzach
Sent: Friday, May 21, 2021 16:40

Bob, when the program ends, does the Rexx get control, or if hit enter and the cursor moves to a new line?
Whether is is end or /*, in the case the program still waits for the input end of file , you can use the queue command to feed the input before calling the program.

--- בתאריך יום ו׳, 21 במאי 2021 ב-23:36 מאת Bob Bridges <robhb...@gmail.com>:

> I'm not sure what you're thinking, Itzchak. Why would I want the
> program to see a record saying "end"?
>
> I tried it anyway, just to see what would happen. It read "end" and
> copied it to the beginning of the SYSPRINT output, but I still had to
> type '/*' manually when the REXX ran the program (whose name, by the
> way, is AT6#RPT).
>

> -----Original Message-----
> From: ITschak Mugzach
> Sent: Friday, May 21, 2021 15:41
>
> If this the problem. Use queue “end”.
>

> --- בתאריך יום ו׳, 21 במאי 2021 ב-22:27 מאת Bob Bridges:

Seymour J Metz

unread,

May 21, 2021, 5:54:45 PM5/21/21

to

I doubt that anybody will be able to help unless you post the relevant allocation and code.

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

________________________________________

From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Bob Bridges <robhb...@GMAIL.COM>
Sent: Friday, May 21, 2021 5:26 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] SV: [TSO-REXX] EXECIO * DISKR SYSPRINT

Paul Gilmartin

unread,

May 21, 2021, 5:55:33 PM5/21/21

to

On 2021-05-21, at 15:33:33, Bob Bridges wrote:
>
> Oh, I see; not quite as direct as your method. But easier, because I have
> EXECIOST and VIEWQ already prepared - I've been using them for decades - so
> the job gets done in two short statements instead of six longer ones.
>

Six well-documeented long statements that might work if you tried them
might be preferable to two short statements that demonstrably don't work.

(What is the effect of specifying "enq(shr)" on an already allocated DDNAME?)

> -----Original Message-----
> From: Jeremy Nicoll
> Sent: Friday, May 21, 2021 15:42
>
> Why don't you view/browse the contents of sysprint directly? With code like
>
> address ispexec ; "control errors return" ; "control display refresh"
> "lminit dataid(did) ddname(sysprint) enq(shr)"
> "browse dataid("did")"
> "lmfree dataid("did")"

-- gil

Paul Gilmartin

unread,

May 21, 2021, 6:01:21 PM5/21/21

to

On 2021-05-21, at 15:54:35, Seymour J Metz wrote:
>
> I doubt that anybody will be able to help unless you post the relevant allocation and code.
>

Programmer: It doesn't work.
Adviser : Show me your code.
Programmer: It's confidential.
Adviser : Then replicate the problem in a small example.
...

-- gil

Seymour J Metz

unread,

May 21, 2021, 6:12:48 PM5/21/21

to

do while queued() > 0 is typical for reading from the stack.

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

________________________________________

From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Paul Gilmartin <PaulGB...@AIM.COM>
Sent: Friday, May 21, 2021 4:00 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT

Bob Bridges

unread,

May 21, 2021, 6:18:10 PM5/21/21

to

<Sigh> You're probably right. I was trying to limit the column inches to
just the pertinent parts, and not confuse the issue. Here's the main part
of the program:

/* Run CA-Cleanup. */
'FREE DDN(INCLUDE DBASE)'
'ALLOC DDN(INCLUDE) DSORG(PS) RECFM(F B) LRECL(80) NEW'
"ALLOC DDN(DBASE) DSN('SYS2.SS.CLN.DB') SHR"
'ALLOC DDN(SYSPRINT) DSORG(PS) RECFM(F B) LRECL(132) NEW'
queue 'CLASS(PROFILE) NAME($DCMBR2 )'
call execiost 'INCLUDE','W'
parm='UNREF=060'

address LINKMVS 'AT6#RPT PARM'
call execiost 'SYSPRINT'

'FREE DDN(INCLUDE DBASE SYSPRINT)'
call viewq

EXEICIOST is an external subroutine that reads the contents of a DD or DS to
the stack, or (with the 'W' argument) writes from the stack to a DD or DS.
VIEWQ simply displays the stack in ISPF View.

When I include a TRACE statement, I see that it works normally up to calling
AT6#RPT, then stops. When I type '/*' at the terminal, it continues with
"call execiost 'SYSPRINT' " and finishes normally.

To repeat what I said before, I tried adding '/*' to the end of the
//INCLUDE DD, and to the stack before calling AT6#RPT, and neither change
the REXX's behaviour.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* It's so simple to be wise. Just think of something stupid to say and
then don't say it. -Sam Levenson */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Seymour
J Metz
Sent: Friday, May 21, 2021 17:55

I doubt that anybody will be able to help unless you post the relevant
allocation and code.

________________________________________
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Bob
Bridges <robhb...@GMAIL.COM>
Sent: Friday, May 21, 2021 5:26 PM

After the below email I sent a followup explaining that I'd misunderstood
the problem: It isn't while reading SYSPRINT that the hold-up occurs, but
while running the program. Between these two statements:

address LINKMVS 'AT6#RPT PARM'
call execiost 'SYSPRINT'

...is where execution stops and I have to type '/*' to continue - after
calling AT6#RPT and before it starts EXECIOST. (EXECIOST is a routine I
wrote decades ago to read the contents of a DD or a DS onto the stack.) So
AT6#RPT is trying to read some input, and REXX is trying to supply it from
the terminal.

I tried adding '/*' to the end of the only DD I thought it was reading, but
it doesn't change anything (except that it sees '/*' in the input and
reports on it in the output). And I tried pushing or queueing '/*' before
calling AT6#RPT, and all it did was copy it to the output — but I still had
to type '/*' when running my REXX.

So I'm now guessing AT6#RPT is trying to read some other DD, too, probably
//SYSIN. Maybe I need to put '/*' into SYSIN before calling AT6#RPT.

Farley, Peter x23353

unread,

May 21, 2021, 6:28:48 PM5/21/21

to

It sounds to me like your program in TSO is reading from FI(SYSIN) DA(*) (or any other DD name from DA(*)), that is, you are reading from the terminal or from stacked terminal entries.

If you are in fact intending to read directly from the terminal, entering "/*" is the only way to signal EOF.

If you are stacking input to be read from the terminal, stack a "/*" last so it signals EOF.

Or as Seymour said, use "while queued() > 0" for the read loop (assuming the read loop is in Rexx).

HTH

Peter

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bob Bridges
Sent: Friday, May 21, 2021 5:43 PM
To: TSO-...@VM.MARIST.EDU

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.

Paul Gilmartin

unread,

May 21, 2021, 6:38:00 PM5/21/21

to

On 2021-05-21, at 16:17:58, Bob Bridges wrote:
>
> <Sigh> You're probably right. I was trying to limit the column inches to
> just the pertinent parts, and not confuse the issue. Here's the main part
> of the program:
>
> /* Run CA-Cleanup. */
> 'FREE DDN(INCLUDE DBASE)'
> 'ALLOC DDN(INCLUDE) DSORG(PS) RECFM(F B) LRECL(80) NEW'
> "ALLOC DDN(DBASE) DSN('SYS2.SS.CLN.DB') SHR"
> 'ALLOC DDN(SYSPRINT) DSORG(PS) RECFM(F B) LRECL(132) NEW'
> queue 'CLASS(PROFILE) NAME($DCMBR2 )'
> call execiost 'INCLUDE','W'
> parm='UNREF=060'
> address LINKMVS 'AT6#RPT PARM'
> call execiost 'SYSPRINT'
> 'FREE DDN(INCLUDE DBASE SYSPRINT)'
> call viewq
>
> EXEICIOST is an external subroutine that reads the contents of a DD or DS to
> the stack, or (with the 'W' argument) writes from the stack to a DD or DS.
> VIEWQ simply displays the stack in ISPF View.
>

Add some markers:
...
trace R
say 'Mark 10' queued()
address LINKMVS 'AT6#RPT PARM'
say 'Mark 20' queued()
call execiost 'SYSPRINT'
say 'Mark 30' queued()
'FREE DDN(INCLUDE DBASE SYSPRINT)'

Show the trace output. (Yes, I trust no one.)
AT6#RPT seems to be a Broadcom utility. Do you have its documentation?
Is it possible that AT6#RPT has an interactive mode in which it tries
to read options from the terminal?

-- gil

Frank Clarke

unread,

May 21, 2021, 6:57:57 PM5/21/21

to

Not an answer to your problem, but if you add "REUSE" (or "REU") to (all) your allocates, you can skip the FREEs and avoid an extra pass thru SVC99.

Bernd Oppolzer

unread,

May 21, 2021, 7:55:11 PM5/21/21

to

Maybe the issue is that there is no ALLOC for SYSIN and so
the program AT6#RPT calls for terminal input?

Maybe if you have an allocation for an empty SYSIN file,
all is OK ?

Just a wild guess

Kind regards

Bernd

Paul Gilmartin

unread,

May 21, 2021, 8:13:39 PM5/21/21

to

On 2021-05-21, at 17:54:46, Bernd Oppolzer wrote:
>
> Maybe the issue is that there is no ALLOC for SYSIN and so
> the program AT6#RPT calls for terminal input?
>
> Maybe if you have an allocation for an empty SYSIN file,
> all is OK ?
>

The examples at
https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-cleanup/12-1/using-ca-cleanup-for-top-secret/verify-ca-cleanup-for-top-secret.html

... show no use of SYSIN. Control input comes from INCLUDE DD. But

there is no example of using AT6#RPT under TSO. It's possible that
Broadcom never anticipated running AT6#RPT under TSO while not supplying
control input from the terminal.

I'll suggest an abbreviated test, using only IBM supported facilities.
(Untested):

/* Run CA-Cleanup. */
'FREE DDN(INCLUDE DBASE)'

trace R
X = BPXWDYN( 'ALLOC DDN(INCLUDE) DSORG(PS) RECFM(F,B) LRECL(80) NEW' )
X = BPXWDYN( "ALLOC DDN(DBASE) DSN('SYS2.SS.CLN.DB') SHR"
X = BPXWDYN( 'ALLOC DDN(SYSPRINT) SYSOUT(*) RECFM(F,B) LRECL(132) NEW'
X.1 = 'CLASS(PROFILE) NAME($DCMBR2 )'
address MVS 'EXECIO 1 DISKW INCLUDE (STEM X.'

parm='UNREF=060'
address LINKMVS 'AT6#RPT PARM'

Run the above under //STEP PGM=IRXJCL, then under TSO.
Browse SYSPRINT with SDSF. If the results differ, go to
Broadcom Support. WAD is likely.

-- gil

Seymour J Metz

unread,

May 21, 2021, 8:26:36 PM5/21/21

to

A /* is only EOF for input stream and terminal, not for stack.

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

________________________________________

From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Farley, Peter x23353 <Peter....@BROADRIDGE.COM>
Sent: Friday, May 21, 2021 6:28 PM
To: TSO-...@VM.MARIST.EDU

Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT

Robin

unread,

May 22, 2021, 8:27:37 AM5/22/21

to

If you are really looking for brevity why not just use TSO ISRDDN DD
SYSPRINT as already suggested

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Bob Bridges
Sent: May 21, 2021 5:34 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT

Irwin Poché

unread,

May 24, 2021, 12:23:54 PM5/24/21

to

Can TSO-Rexx use USS pipes ?

Can you point me to an example ?

-Irwin

> On May 24, 2021, at 11:09 AM, Hobart Spitz <orex...@gmail.com> wrote:
>
> On Mon, May 24, 2021 at 5:58 AM Seymour J Metz <sme...@gmu.edu> wrote:
>
>> Assuming that you only need it as a temporary intermediary and that you
>> have adequate paging space; if you're short, you may have bigger problems
>> to worry about.
>
> Thanks Seymour for clarifying for the beginners.
>
>>
>>
>> ObLongStandingComplaints Why can't the access methods handle memory mapped
>> I/O instead of that VIO kludge?
>>
> Pipes is a vastly better solution, by orders of magnitude: Every
> non-modifying filter works off the same copy of the record, parts of which
> are already cache-loaded. Computing without Pipes is like trying to boil
> the ocean.

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

>> From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of
>> Hobart Spitz [orex...@GMAIL.COM]
>> Sent: Sunday, May 23, 2021 7:45 PM

>> To: TSO-...@VM.MARIST.EDU
>> Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT
>>

>> When I need to do something like this, I alloc SYSPRINT to VIO. You can't
>> read from DA(*) or SYSOUT(x) and get what was written when it was OPENed
>> OUTPUT.

>>
>>> On Friday, May 21, 2021, Seymour J Metz <sme...@gmu.edu> wrote:
>>>
>>> A /* is only EOF for input stream and terminal, not for stack.
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>>
>>> ________________________________________
>>> From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of
>>> Farley, Peter x23353 <Peter....@BROADRIDGE.COM>

>>> Sent: Friday, May 21, 2021 6:28 PM

>>> To: TSO-...@VM.MARIST.EDU
>>> Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT
>>>

>>> It sounds to me like your program in TSO is reading from FI(SYSIN) DA(*)
>>> (or any other DD name from DA(*)), that is, you are reading from the
>>> terminal or from stacked terminal entries.
>>>
>>> If you are in fact intending to read directly from the terminal, entering
>>> "/*" is the only way to signal EOF.
>>>
>>> If you are stacking input to be read from the terminal, stack a "/*" last
>>> so it signals EOF.
>>>
>>> Or as Seymour said, use "while queued() > 0" for the read loop (assuming
>>> the read loop is in Rexx).
>>>
>>> HTH
>>>
>>> Peter
>>>

>>> -----Original Message-----
>>> From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bob
>>> Bridges
>>> Sent: Friday, May 21, 2021 5:43 PM
>>> To: TSO-...@VM.MARIST.EDU

>>> Subject: Re: EXECIO * DISKR SYSPRINT
>>>
>>> The problem seems to be that the program doesn't end; it keeps looking
>> for
>>> input from the stack (ie from the terminal). When I hit <Enter>, or type
>>> in something else and then hit <Enter>, the cursor moves to the next
>> line.
>>> Only when I type '/*' and hit <Enter> does the program return control to
>> my
>>> REXX, which then displays the contents of //SYSPRINT.
>>>
>>> As I said below, I tried adding a record "end" or "/*" to the stack
>> before
>>> calling the program. The program still required me to type '/*' manually
>>> before it would return control to my REXX. The extra 'end' or '/*'
>>> appeared in the output, so apparently the program saw it, but did not
>>> regard it as a valid EOF marker.
>>>

>>> ---
>>> Bob Bridges, robhb...@gmail.com, cell 336 382-7313
>>>

>>> /* Do you know what constitutes a "hate crime"? Put your thinking caps
>>> on. What tools do we need to determine whether a crime was motivated by
>>> hate or prejudice? Answer: We need thought police. -from "See, I Told
>> You

>>> So" by Rush Limbaugh */

>>>
>>> -----Original Message-----
>>> From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of

>>>>> I have an external REXX routine I've been using for decades that
>>>>> reads a DD or DS and puts its contents in the queue, so I use it to
>>>>> grab SYSPRINT:
>>>>>

>>>>> call execiost 'SYSPRINT'
>>>>>
>>>>> But whether it's because SYSPRINT is different, or for some other
>>>>> reason, EXECIOST pauses at this point looking for more input from
>>>>> the terminal. I have to type '/*' manually to get it to recognize
>>>>> the end of file, at which point it returns to my program and finishes
>>> correctly.
>>>>>
>>>>> So now I'm thinking about ways to run this without having to type
>>>>> '/*', and so far the only thing that occurs to me is to create a DS
>>>>> containing '/*' and concatenate it to SYSPRINT before trying to read
>>>>> it. But that's silly; surely that's going around my elbow to get to
>>>>> my thumb (so to speak). Someone tell me the more obvious way to do
>>>>> this, please, because it's escaping me.
>>> --
>>>
>>> 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 TSO-REXX subscribe / signoff / archive access instructions,
>>> send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
>>>
>>> ----------------------------------------------------------------------
>>> For TSO-REXX subscribe / signoff / archive access instructions,
>>> send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
>>>
>>
>>

>> --
>> OREXXMan
>> Would you rather pass data in move mode (*nix piping) or locate mode
>> (Pipes) or via disk (JCL)?
>> IBM has been looking for an HLL for program products; REXX is that
>> language.

Hobart Spitz

unread,

May 24, 2021, 12:45:00 PM5/24/21

to

I'm talking about CMS/TSO Pipes, and yes, REXX and CMS/TSO Pipes work very
well together.

I don't know the status of CMS/TSO Pipes in USS. I imagine it's the same
as any TSO command. CMS/TSO Pipes can read USS byte streams as well as all
z/OS PS, PO, and possibly VSAM datasets. In REXX, it's something like:
* "pipe <bfs my.txt | locate 'REXX' | browse" *
(I don't know USS that well, so pardon any errors in the first (<bfs)
stage.)

USS pipes, a different animal, is/are text byte oriented and every
character must go thru the CPU at each and every stage. The CPU usage is
worse, *roughly *exponentially, with the number stages. You rarely see USS
or *nix commands with more than a dozen filters. CMS/TSO Pipes pass/es
data with pointers. The CPU usage of CMS/TSO pipes is sub-linear with the
number stages; the more stages the better the performance (in general).
Watson is rumored to have some 15,000 stages, mostly generated.

It's like the difference between an abacus and a supercomputer.

It's time to surround Armonk with torches and pitchforks demanding the TSO
Pipes be added to the z.OS base. (Hyperbole in case it wasn't clear.) It
is long, long, overdue for customers, users and shareholders.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?
IBM has been looking for an HLL for program products; REXX is that language.

Paul Gilmartin

unread,

May 24, 2021, 12:51:04 PM5/24/21

to

On 2021-05-24, at 10:23:43, Irwin Poché wrote:
>
> Can TSO-Rexx use USS pipes ?
>

Maybe. It's hard to find; needs license.

> Can you point me to an example ?
>

He did, much earlier.

I forgot thee "finis" on theEEXECIO.

Consider taking this thread to IBM-MAIN and adding
"Broadcom" to the Subject: It might catch the eye
of a Broadcom employee.

>>>> -----Original Message-----
>>>> From: T Bob Bridges
>>>> Sent: Friday, May 21, 2021 5:43 PM
>>>>

>>>> The problem seems to be that the program doesn't end; it keeps looking
>>> for
>>>> input from the stack (ie from the terminal). When I hit <Enter>, or type
>>>> in something else and then hit <Enter>, the cursor moves to the next
>>> line.
>>>> Only when I type '/*' and hit <Enter> does the program return control to
>>> my
>>>> REXX, which then displays the contents of //SYSPRINT.
>>>>
>>>> As I said below, I tried adding a record "end" or "/*" to the stack
>>> before
>>>> calling the program. The program still required me to type '/*' manually
>>>> before it would return control to my REXX. The extra 'end' or '/*'
>>>> appeared in the output, so apparently the program saw it, but did not
>>>> regard it as a valid EOF marker.

-- gil

Paul Gilmartin

unread,

May 24, 2021, 1:36:38 PM5/24/21

to

On 2021-05-24, at 10:23:43, Irwin Poché wrote:
>

> Can TSO-Rexx use USS pipes ?
>

Maybe. It's hard to find; needs license.

> Can you point me to an example ?
>

He did, much earlier.

I forgot thee "finis" on theEEXECIO.

Consider taking this thread to IBM-MAIN and adding
"Broadcom" to the Subject: It might catch the eye
of a Broadcom employee.

>>>> -----Original Message-----

>>>> From: T Bob Bridges
>>>> Sent: Friday, May 21, 2021 5:43 PM
>>>>

>>>> The problem seems to be that the program doesn't end; it keeps looking
>>> for
>>>> input from the stack (ie from the terminal). When I hit <Enter>, or type
>>>> in something else and then hit <Enter>, the cursor moves to the next
>>> line.
>>>> Only when I type '/*' and hit <Enter> does the program return control to
>>> my
>>>> REXX, which then displays the contents of //SYSPRINT.
>>>>
>>>> As I said below, I tried adding a record "end" or "/*" to the stack
>>> before
>>>> calling the program. The program still required me to type '/*' manually
>>>> before it would return control to my REXX. The extra 'end' or '/*'
>>>> appeared in the output, so apparently the program saw it, but did not
>>>> regard it as a valid EOF marker.

-- gil

Paul Gilmartin

unread,

May 24, 2021, 1:36:50 PM5/24/21

to

On 2021-05-24, at 10:44:41, Hobart Spit wrote:
>
> I'm talking about CMS/TSO Pipes, and yes, REXX and CMS/TSO Pipes work very
> well together.
>
> I don't know the status of CMS/TSO Pipes in USS. I imagine it's the same
> as any TSO command. CMS/TSO Pipes can read USS byte streams as well as all
> z/OS PS, PO, and possibly VSAM datasets. In REXX, it's something like:
> * "pipe <bfs my.txt | locate 'REXX' | browse" *
> (I don't know USS that well, so pardon any errors in the first (<bfs)
> stage.)
>
> USS pipes, a different animal, is/are text byte oriented and every
> character must go thru the CPU at each and every stage. The CPU usage is

> worse, *roughly *exponentially, with the number stages. ...
>
WTTF!?

Is there a general OMVS (USS?) filter? I'm imagining (cofrrecr my syntax):

PIPE TSO TIME | OMVS iconv -f IBM-1047 -t IBM-500 | CONSOLE

Or eveen:

PIPE TSO TIME | OMVS iconv -f IBM-1047 -t IBM-500 | ISREDIT VIEW

-- gil

Gary Green

unread,

May 24, 2021, 1:39:29 PM5/24/21

to

Thanks for responding with that suggestion. I had thought the same thing,
but was only 80% certain, so I kept my mouth shut..

-----------------------------------------
Never use a 2x4,
when a 2x6 will do just as well.

Irwin Poché

unread,

May 24, 2021, 2:54:00 PM5/24/21

to

Its non-existence explains why I was unaware. That also explains +++ RC(-3) +++ issuing “pipe”

-Irwin

> On May 24, 2021, at 12:36 PM, Paul Gilmartin <PaulGB...@aim.com> wrote:

Paul Gilmartin

unread,

May 24, 2021, 3:11:40 PM5/24/21

to

> On 2021-05-24, at 12:53:40, Irwin Poché wrote:
>
> Its non-existence explains why I was unaware. That also explains +++ RC(-3) +++ issuing “pipe”
>
> -Irwin
>
>> On May 24, 2021, at 12:36 PM, Paul Gilmartin <PaulGB...@aim.com> wrote:
>>
>> On 2021-05-24, at 10:23:43, Irwin Poché wrote:
>>>
>>> Can TSO-Rexx use USS pipes ?
>>>
>> Maybe. It's hard to find; needs license.
>>

I misunderrstood. See BPXWUNIX.

Hamilton, Robert

unread,

May 24, 2021, 3:39:21 PM5/24/21

to

In USS "pipe" is a SYSCALL that creates the pipe....then you just use regular *nix pipe stages. I regularly use pipes in OMVS REXX routines.

I have one to read an export from a Word document to extract the pieces I need to construct a web page:

address SYSCALL;

"pipe ESPPipe.";
address SH "egrep -n" DQuote ||,
WhatSearchToken || UnixOr ||,
JOBsToken || UnixOr ||,
GoalToken || UnixOr ||,
GoalToken3 || UnixOr ||,
PageBreakToken1 || UnixOr ||,
PageBreakToken2 || UnixOr ||,
Pre_IPLToken || UnixOr ||,
Post_Token2 || UnixOr ||,
AppendixToken || UnixOr ||,
TipsToken || DQuote HTMLDocFile,
UnixRedirOut || "/dev/fd"ESPPipe.2;
"close" ESPPipe.2;
address MVS "EXECIO * DISKR" ESPPipe.1 "(STEM HTMLLine.";

Ok, that's a little messy...i use UnixOr instead of inserting a "|" between || to try to be less confusing. This EXEC runs in OMVS, not TSO. Still, this is how I gather some lines from a very large file into a REXX array so I can process them.

Oh well, it's an example.

R;

Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Irwin Poché
Sent: Monday, May 24, 2021 2:54 PM
To: TSO-...@VM.MARIST.EDU
Subject: [EXT] Re: EXECIO * DISKR SYSPRINT

[Actual Sender is owner-t...@vm.marist.edu]

Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.

Bob Bridges

unread,

May 25, 2021, 7:02:34 PM5/25/21

to

The problem isn't (as I saw eventually) getting at the contents of SYSPRINT;
it's that when my REXX calls AT6#RPT, that program doesn't return control to
my REXX until I type "/*". After that I can see SYSPRINT just fine.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Opportunity is missed by most people because it is dressed in overalls
and looks like work. -Thomas Edison */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Jeremy
Nicoll
Sent: Friday, May 21, 2021 15:42

Why don't you view/browse the contents of sysprint directly? With code like

address ispexec ; "control errors return" ; "control display refresh"
"lminit dataid(did) ddname(sysprint) enq(shr)"
"browse dataid("did")"
"lmfree dataid("did")"

--- On Fri, 21 May 2021, at 19:48, Bob Bridges wrote:

> I have an external REXX routine I've been using for decades that reads
> a DD or DS and puts its contents in the queue, so I use it to grab
SYSPRINT:

Bob Bridges

unread,

May 25, 2021, 7:07:51 PM5/25/21

to

That's what I suspect. When I run AT6#RPT in batch, it does fine without SYSIN. But in TSO (or maybe it's in ISPF), SYSIN is always allocated to TERMFILE; I'm guessing AT6#RPT is trying to read from //SYSIN. So I'm thinking I have to find some way of getting it to see the end of SYSIN, or to see that SYSIN isn't present.

I already tried pushing '/*' onto SYSIN before calling the program, so the solution will have to lie elsewhere.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Lazarus Long */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Farley, Peter x23353
Sent: Friday, May 21, 2021 18:29

It sounds to me like your program in TSO is reading from FI(SYSIN) DA(*) (or any other DD name from DA(*)), that is, you are reading from the terminal or from stacked terminal entries.

If you are in fact intending to read directly from the terminal, entering "/*" is the only way to signal EOF.

If you are stacking input to be read from the terminal, stack a "/*" last so it signals EOF.

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bob Bridges
Sent: Friday, May 21, 2021 5:43 PM

The problem seems to be that the program doesn't end; it keeps looking for input from the stack (ie from the terminal). When I hit <Enter>, or type in something else and then hit <Enter>, the cursor moves to the next line. Only when I type '/*' and hit <Enter> does the program return control to my REXX, which then displays the contents of //SYSPRINT.

As I said below, I tried adding a record "end" or "/*" to the stack before calling the program. The program still required me to type '/*' manually before it would return control to my REXX. The extra 'end' or '/*' appeared in the output, so apparently the program saw it, but did not regard it as a valid EOF marker.

Bob Bridges

unread,

May 25, 2021, 7:08:54 PM5/25/21

to

I think //SYSIN is allocated already; maybe if I FREE it? Still some experimenting to do.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Why did the string bass player get angry at the timpanist? A: Because the timpanist turned a peg and wouldn't tell him which one. -from a collection of musician jokes */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bernd Oppolzer
Sent: Friday, May 21, 2021 19:55

Maybe the issue is that there is no ALLOC for SYSIN and so the program AT6#RPT calls for terminal input?

Maybe if you have an allocation for an empty SYSIN file, all is OK ?

Bob Bridges

unread,

May 25, 2021, 7:41:06 PM5/25/21

to

Shmuel, I'm not sure how far that's relevant. It looks like AT6#RPT is
doing the reading, so it's AT6#RPT that must decide what it will accept as
an EOF marker. And judging by the behavior when I run the REXX, it's
apparently reading from the stack - that is, judging by the fact that it
keeps moving the cursor down one line whenever I hit <Enter>.

...Unless it isn't AT6#RPT that's doing the reading, but something else. I
don't know what it would be, though.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Wink at small faults; remember thou hast great ones. -Poor Richard */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Seymour
J Metz
Sent: Friday, May 21, 2021 20:26

A /* is only EOF for input stream and terminal, not for stack.

________________________________________
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Farley,
Peter x23353 <Peter....@BROADRIDGE.COM>
Sent: Friday, May 21, 2021 6:28 PM

It sounds to me like your program in TSO is reading from FI(SYSIN) DA(*) (or
any other DD name from DA(*)), that is, you are reading from the terminal or
from stacked terminal entries.

If you are in fact intending to read directly from the terminal, entering
"/*" is the only way to signal EOF.

If you are stacking input to be read from the terminal, stack a "/*" last so
it signals EOF.

Or as Seymour said, use "while queued() > 0" for the read loop (assuming the
read loop is in Rexx).

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bob
Bridges
Sent: Friday, May 21, 2021 5:43 PM

The problem seems to be that the program doesn't end; it keeps looking for
input from the stack (ie from the terminal). When I hit <Enter>, or type in
something else and then hit <Enter>, the cursor moves to the next line.
Only when I type '/*' and hit <Enter> does the program return control to my
REXX, which then displays the contents of //SYSPRINT.

As I said below, I tried adding a record "end" or "/*" to the stack before
calling the program. The program still required me to type '/*' manually
before it would return control to my REXX. The extra 'end' or '/*' appeared
in the output, so apparently the program saw it, but did not regard it as a
valid EOF marker.

Seymour J Metz

unread,

May 25, 2021, 7:41:43 PM5/25/21

to

You can't push a line unto a dataset, only onto a stack. Further, a /* on the stack has no special significance. What happens if you allocate SYSIN as DUMMY? A Unix special file?

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

________________________________________

From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Bob Bridges [robhb...@GMAIL.COM]
Sent: Tuesday, May 25, 2021 7:07 PM
To: TSO-...@VM.MARIST.EDU

Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT

Jeremy Nicoll

unread,

May 26, 2021, 5:19:19 AM5/26/21

to

On Wed, 26 May 2021, at 00:02, Bob Bridges wrote:
> The problem isn't (as I saw eventually) getting at the contents of SYSPRINT;
> it's that when my REXX calls AT6#RPT, that program doesn't return control to
> my REXX until I type "/*". After that I can see SYSPRINT just fine.

Yes, I've read the messages here and understood that.

The reason I posted my example code though is that there's no need for your
code to waste time and effort reading sysprint then doing [anything at all] with
the contents before invoking browse/view. Browse/view can access the contents
of sysprint directly. It saves time and complication.

> -----Original Message-----
> From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Jeremy
> Nicoll
> Sent: Friday, May 21, 2021 15:42
>
> Why don't you view/browse the contents of sysprint directly? With code like
>
> address ispexec ; "control errors return" ; "control display refresh"
> "lminit dataid(did) ddname(sysprint) enq(shr)"
> "browse dataid("did")"
> "lmfree dataid("did")"

--

Jeremy Nicoll - my opinions are my own.

Paul Gilmartin

unread,

May 26, 2021, 8:32:26 AM5/26/21

to

On 2021-05-24, at 10:44:41, Hobart Spitz wrote:
>
> ...

> USS pipes, a different animal, is/are text byte oriented and every
> character must go thru the CPU at each and every stage. The CPU usage is

> worse, *roughly *exponentially, with the number stages. ...
>
???
On Intel Linux I ran a 1000-stage pie in 0.47 seconds. Seems
about linear. How could z/OS developers do so much worse!?

-- gil

Robin

unread,

May 26, 2021, 8:48:38 AM5/26/21

to

Let's analyse what you say here and hopefully that analysis will outline
where the problem is.

Clearly the objective of your routine is to display the data that program
AT6#RPT generated to ddname SYSPRINT.

As per other posts, your REXX code does not "call" AT6#RPT. It invokes the
program via ADDRESS LINKMVS. Why is LINKMVS required?

You say that AT6#RPT does not return control to your REXX program. Are you
sure that it is AT6#RPT that has control? What epiphany inspires you to
enter /* as opposed to any other string of characters? What are the
instructions for using AT6#RPT?

You say once your REXX program gets control, the results you want are
available. This suggests to me that abuse of the stack is source of the
problem. I suggest complete removal of the routines that stack the results
of AT6#RPT will eliminate the deviant behavior. (You should be able to use
TSO ISRDDN to verify the contents of SYSPRINT).

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Bob Bridges
Sent: May 25, 2021 7:02 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT

Paul Gilmartin

unread,

May 26, 2021, 9:06:03 AM5/26/21

to

On 2021-05-26, at 06:48:27, Robin wrote:
> ...T.

> As per other posts, your REXX code does not "call" AT6#RPT. It invokes the
> program via ADDRESS LINKMVS. Why is LINKMVS required?
>

It's not required but it's a sthe simplest interface.
Keep the TMP out of the process.

> You say that AT6#RPT does not return control to your REXX program. Are you
> sure that it is AT6#RPT that has control? What epiphany inspires you to
> enter /* as opposed to any other string of characters? What are the
> instructions for using AT6#RPT?
>

He said he did a trace; he didn't supply the output.

For prroblem reeporrting, use standard facilities;
eliminzte EXECIOST.

-- gil

Seymour J Metz

unread,

May 26, 2021, 9:58:24 AM5/26/21

to

> As per other posts, your REXX code does not "call" AT6#RPT. It invokes the
> program via ADDRESS LINKMVS. Why is LINKMVS required?

CALL AT6#RPT. would generate the wrong plist and ADDRESS LINKMVS AT6#RPT generates the correct PLIST. Isn't that a good enough reason?

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

________________________________________

From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Robin [robin....@GMAIL.COM]
Sent: Wednesday, May 26, 2021 8:48 AM

Paul Gilmartin

unread,

May 26, 2021, 11:24:15 AM5/26/21

to

> On 2021-05-26, at 07:58:13, Seymour J Metz wrote:
>
>> As per other posts, your REXX code does not "call" AT6#RPT. It invokes the
>> program via ADDRESS LINKMVS. Why is LINKMVS required?
>
> CALL AT6#RPT. would generate the wrong plist
>

No: https://www.ibm.com/docs/en/zos/2.2.0?topic=command-call-operands
...
parameter_string
specifies up to 100 characters of information that you want to pass to the program as a parameter string. The character string can contain DBCS characters that you delimit with shift-out (X'0E') and shift-in (X'0F') characters.
The program to be executed receives parameters according to the standard linkage conventions. These are the same conventions that will apply if the program was executed by batch job control language (JCL) and a parameter string was passed by the EXEC statement with the PARM keyword.

('CALL', not CALL)

> ...and ADDRESS LINKMVS AT6#RPT generates the correct PLIST. Isn't that a good enough reason?
>
The same.

-- gil

Bob Bridges

unread,

May 26, 2021, 12:13:47 PM5/26/21

to

Ah, pertinent questions! I hope my answers will be up to that standard :).
See below.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* Faith is not leaning on a shovel and praying for a hole. -Steve Andrews
(pastor), 2010-03 */

-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Robin
Sent: Wednesday, May 26, 2021 08:48

Rob1> Let's analyse what you say here and hopefully that analysis will

outline where the problem is.

Clearly the objective of your routine is to display the data that program
AT6#RPT generated to ddname SYSPRINT.

As per other posts, your REXX code does not "call" AT6#RPT. It invokes the
program via ADDRESS LINKMVS. Why is LINKMVS required?

Bri2> I'm almost totally ignorant of the significance of the various
options: 'AT6#RPT', "call AT6#RPT", LINK, ATTACH, LINKMVS, ATTACHMVS and
whatever else there is. By "almost totally ignorant" I mean that I know
there are differences, and I see by experimentation that in a particular
circumstance some work and some don't -- or more often that one does and the
rest don't -- but I have no idea what each one means and why it works. I
suspect that if I had learned assembler on the mainframe, the descriptions
in the manual would convey something to me. As it is, I flounder around
until I get the results I want. That's how I arrived in this case at the
following invocation:

parm='UNREF=060'
address LINKMVS 'AT6#RPT PARM'

Rob1> You say that AT6#RPT does not return control to your REXX program. Are

you sure that it is AT6#RPT that has control?

Bri2> I ~assumed~ it was AT6#RPT, at first. After some thought, I realized
it's an assumption. What I know, from REXX TRACE statements, is that REXX
execution has not yet proceeded to the next statement after AT6#RPT. So it
still seems a likely assumption to me, but not certain.

Rob1> What epiphany inspires you to enter /* as opposed to any other string
of characters?

Bri2> I tried all the more obvious things first. The cursor sat there
without comment, and when I entered a string and hit <Enter> the cursor
moved down a line and continued waiting. This behavior is what I see when a
REXX program is trying to read from the stack and the stack is empty (so it
looks for input from the terminal). So I tried a number of entries: <Enter>
by itself, then END and EXIT and so forth. When I thought the problem had
to do with my EXECIO subroutine, that was as far as I got. When I realized
that my REXX wasn't even starting to read SYSPRINT, that it might still be
executing AT6#RPT, I considered that AT6#RPT is a batch program and tried
'//'. It wasn't until next day that it occurred to me to try '/*', and I
vaguely remember that being triggered by something someone said in this
forum. That's the first (and so far the only) string that allows the REXX
to continue.

Rob1> What are the instructions for using AT6#RPT?

Bri2> The instructions are badly written -- badly even for a non-IBM
company, bad enough that I've written to the owner of the documentation at
the publisher, who apparently looked and agreed with me for he said they're
considering a complete rewrite. (I find these folks very responsive in the
matter of their customer help.) But in any case the instructions are only
for batch; they describe DD statements and control parms, but apparently no
one there has thought about foreground execution.

Rob1> You say once your REXX program gets control, the results you want are

available. This suggests to me that abuse of the stack is source of the
problem. I suggest complete removal of the routines that stack the results
of AT6#RPT will eliminate the deviant behavior.

Bri2> I'm not following you. Once my REXX program gets control, everything
works correctly; therefore it might be abuse of the stack? I don't see how
one leads to the other, but I guess you're saying AT6#RPT itself might be
abusing the stack (since you're not saying my REXX is doing so)? If so, it
wouldn't be under my control.

--- On Fri, 21 May 2021, at 19:48, Bob Bridges wrote:
> I have an external REXX routine I've been using for decades that reads
> a DD or DS and puts its contents in the queue, so I use it to grab

> SYSPRINT...

Seymour J Metz

unread,

May 26, 2021, 12:43:34 PM5/26/21

to

> No: https://www.ibm.com/docs/en/zos/2.2.0?topic=command-call-operands

That's the TSO command, not the REXX CALL statement. What I wrote was correct.

Is there some reason that you would prefer ADDRESS TSO CALL "'foo(AT6#RPT)' 'parm'"?

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

________________________________________

From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> on behalf of Paul Gilmartin <PaulGB...@AIM.COM>
Sent: Wednesday, May 26, 2021 11:23 AM

To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] EXECIO * DISKR SYSPRINT

Paul Gilmartin

unread,

May 26, 2021, 1:07:14 PM5/26/21

to

On 2021-05-26, at 10:43:24, Seymour J Metz wrote:
>
>> No: https://www.ibm.com/docs/en/zos/2.2.0?topic=command-call-operands
>
> That's the TSO command, not the REXX CALL statement. What I wrote was correct.
>

I assummed that when Robin wrote "call" AT6#RPT he knew what he was doing.
You assumed he did not. (Deliberately, so you could then dispute it?)

> Is there some reason that you would prefer ADDRESS TSO CALL "'foo(AT6#RPT)' 'parm'"?
>

Or, even, ADDRESS TSO CALL "'*(AT6#RPT)' 'parm'"?

I prefer LINKMVS to eliminate any vagaries of "CALL" and
dependency on TSO.

Robin

unread,

May 26, 2021, 7:07:40 PM5/26/21

to

Isolate where the unusual behavior happens.

Do me a favor and eliminate EXCIOST and VIEWQ. Also eliminate all queue
commands (I can't think that AT6#RPT reads from the stack. So the rexx exec
would look like:

/* Run CA-Cleanup. */
'FREE DDN(INCLUDE DBASE)'
'ALLOC DDN(INCLUDE) DSORG(PS) RECFM(F B) LRECL(80) NEW'
"ALLOC DDN(DBASE) DSN('SYS2.SS.CLN.DB') SHR"
'ALLOC DDN(SYSPRINT) DSORG(PS) RECFM(F B) LRECL(132) NEW'

parm='UNREF=060'
address LINKMVS 'AT6#RPT PARM'

'FREE DDN(INCLUDE DBASE )' /* Note that SYSPRINT was removed */

When that exec runs check if the unusual behavior occurs. After the exec
finishes, issue
TSO ISRDDN DDNAME SYSPRINT from the ISPF command prompt.

Paul Gilmartin

unread,

May 26, 2021, 7:40:37 PM5/26/21

to

On 2021-05-26, at 17:07:25, Robin wrote:
>
> Isolate where the unusual behavior happens.
>
> Do me a favor and eliminate EXCIOST and VIEWQ. Also eliminate all queue

> commands (I can't think that AT6#RPT reads from the stack. ...
>
I'll repeat my earrlierr suggeston. Simplify:
The examples at
https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-cleanup/12-1/using-ca-cleanup-for-top-secret/verify-ca-cleanup-for-top-secret.html

... show no use of SYSIN. Control input comes from INCLUDE DD. But

there is no example of using AT6#RPT under TSO. It's possible that
Broadcom never anticipated running AT6#RPT under TSO while not supplying
control input from the terminal.

I'll suggest an abbreviated test, using only IBM supported facilities.
(Untested):
/* Run CA-Cleanup. */
trace R
X = BPXWDYN( 'ALLOC DDN(INCLUDE) DSORG(PS) RECFM(F,B) LRECL(80) NEW REUSE' ) )
X = BPXWDYN( "ALLOC DDN(DBASE) DSN('SYS2.SS.CLN.DB SHR REUSE' )
X = BPXWDYN( 'ALLOC DDN(SYSPRINT) SYSOUT(*) RECFM(F,B) LRECL(132) REUSE' )
L.1 = 'CLASS(PROFILE) NAME($DCMBR2 )'
address MVS 'EXECIO 1 DISKW INCLUDE (STEM L. FINIS'

parm='UNREF=060'
address LINKMVS 'AT6#RPT PARM'

Run the above under //STEP PGM=IRXJCL, then under TSO.
Browse SYSPRINT with SDSF. If the results differ, go to
Broadcom Support. WAD is likely.

-- gil